From: | Joachim Wieland <joe(at)mcknight(dot)de> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Snapshot synchronization, again... |
Date: | 2010-12-31 03:15:57 |
Message-ID: | AANLkTimiyDbGFMh2A4WOk=mH9F4nCr9eQ7XS=ko2msAX@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 30, 2010 at 9:40 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
>> Disadvantage of b: It doesn't allow a snapshot to be installed on a
>> different server. It requires a serializable open transaction to hold
>> the snapshot.
>
> Why does it require a serializable transaction? You could simply
> register the snapshot in any transaction. (Of course, the net effect
> would be pretty similar to a serializable transaction).
I am not assuming that the publishing transaction blocks until its
snapshot is being picked up. A read committed transaction would get a
new snapshot for every other query, so the published snapshot is no
longer represented by an actual backend until it is being picked up by
one. Since nobody is holding off xmin/GlobalXmin, eventually vacuum
would remove tuples that the published-but-not-yet-picked-up snapshot
should still be able to see, no?
Joachim
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua Tolley | 2010-12-31 03:26:51 | Re: Sync Rep Design |
Previous Message | Tom Lane | 2010-12-31 02:30:32 | Re: and it's not a bunny rabbit, either |