From: | Peter Galbavy <peter(dot)galbavy(at)knowtion(dot)net> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PITR Phase 2 - Design Planning |
Date: | 2004-04-28 08:28:02 |
Message-ID: | 408F6B12.6030003@knowtion.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2004-04-28 08:31:57 | Re: Bringing PostgreSQL torwards the standard regarding |
Previous Message | Christopher Kings-Lynne | 2004-04-28 08:18:24 | Re: bitwise and/or aggregate functions? |