Re: Exposing the Xact commit order to the user

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Exposing the Xact commit order to the user
Date: 2010-05-26 02:44:23
Message-ID: 4BFC8B07.6080006@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/25/2010 4:16 PM, Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-05-26 03:03:34 Re: Open Item: pg_controldata - machine readable?
Previous Message Tom Lane 2010-05-26 02:29:07 libpq should not be using SSL_CTX_set_client_cert_cb