Re: Retrieve the snapshot's LSN

From: Florent Guiliani <florent(at)guiliani(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Retrieve the snapshot's LSN
Date: 2015-07-17 08:16:09
Message-ID: CAMN0T-tbj=HoBv3KTADMoE2O9=o+3R_k1cVvbBT5TzK05c6X_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 16, 2015 at 6:40 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I don't think "the snapshot's LSN" has a well-defined meaning in
> general. The obvious meaning would be "the LSN such that all commits
> prior to that LSN are visible and all later commits are invisible",

I like this definition.

> but such an LSN need not exist. Suppose A writes a commit record at
> LSN 0/10000, and then B writes a commit record at 0/10100, and then B
> calls ProcArrayEndTransaction(). At this point, B is visible and A is
> not visible, even though A's commit record precedes that of B.

Maybe that's what Andres referred as "doable with some finicky locking".

There is some race conditions to build a snapshot with an associated
consistent LSN. If I understand your example, A is supposed to call
ProcArrayEndTransaction() anytime soon. Could we wait/lock until it
happens?

--
Florent

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Jurd 2015-07-17 08:23:48 Re: [PATCH] Function to get size of asynchronous notification queue
Previous Message Kyotaro HORIGUCHI 2015-07-17 08:13:09 Re: [HACKERS] Grouping Sets: Fix unrecognized node type bug