On 12/03/2014 03:52 PM, Joshua Boyd wrote:
I tried that when I was testing .. if I stopped at the most recent insert/update/delete previous to the drop database (with telling it to include the change) it DIDN'T include the change (I assume because the commit timestamp was slightly after the transaction timestamp) .. and if I told it to stop a little later than that, it removed the files (because it got to the drop database statement and stopped before the commit, but still deleted the files). For some reason it ignored SELECT statements - I assume those are not actually written into the wal files, and that would be why. But .. that's only a guess. I'm not that educated with regard to the inner workings of Postgres.. :) For the meantime, until the patch is released, the method I have wrangled to "get around the issue" is to actually restore twice ... the first time using a timestamp and I record the xid reported in the pg_log that it stopped before commit of.. Then re-restore by using the xid. That works, keeps the most recent insert/update/delete, and DOESN'T delete files.. Kinda a pain, but it works.
Yea, DROP DATABASE is not transactional(or maybe semi-transactional) and lives in a gray area.
Anyway .. thanks for the assistance. :)
-- Adrian Klaver adrian.klaver@xxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
