Re: PITR Phase 2 - Design Planning - Mailing list pgsql-hackers

From Peter Galbavy
Subject Re: PITR Phase 2 - Design Planning
Date
Msg-id 408F6B12.6030003@knowtion.net
Whole thread Raw
In response to Re: PITR Phase 2 - Design Planning  (Bruno Wolff III <bruno@wolff.to>)
List pgsql-hackers
Bruno Wolff III wrote:
> The context of my suggestion was for recovering up until a transaction which
> messed things up was committed. I did not want the problem transaction to
> be committed. If the problem transaction ran for a long time, there might
> be other transactions that I want to keep, if possible, that committed
> after the problem transaction started and before it ended.

Ah! followed by Eek! Now I see the light. It's very bright and painful.

What I can see is that expressing this accurately and unambiguously is 
going to be _difficult_. How do you know accurately the point just 
before a transaction was completed. There must be a good subset of 
candidates that can be labelled.

Is there anyway to label/name a transaction that can be kept somewhere ? 
Like "begin transaction 'bigtrasacation26';" - is there any allowance in 
the SQL standards for naming trasactions ?

PS I have fixed my system clock - apologies to my earlier reply being a 
month ahead.

rgds,
--
Peter


pgsql-hackers by date:

Previous
From: Jean-Michel POURE
Date:
Subject: Re: [pgsql-advocacy] What can we learn from MySQL?
Next
From: Hannu Krosing
Date:
Subject: Re: Bringing PostgreSQL torwards the standard regarding