On 5/25/2010 4:16 PM, Tom Lane wrote:
Jan Wieck <janwi...@yahoo.com> writes:
No, I meant how will the *function* know, if a superuser and/or some
background process can purge records at any time?
The data contains timestamps which are supposedly taken in commit order.
You can *not* rely on the commit timestamps to be in exact order.
(Perhaps approximate ordering is good enough for what you want here,
but just be careful to not fall into the trap of assuming that they're
exactly ordered.)
I am well aware of the fact that commit timestamps within the WAL can go
backwards and that the serial numbers of this proposed implementation of
commit order can even be different from what the timestamps AND the WAL
are saying.
As long as the serial number (record position inside of segment) is
determined while the transaction still holds all its locks, this is
going to be good enough for what async replication users today are used
to. Again, it will not magically make it possible to determine a
serializable order of actions, that happened from transactions running
in read committed isolation level, post mortem. I don't even even think
that is possible at all.
And I don't think anyone proposed a solution for that problem anyways.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
