From: | Joachim Wieland <joe(at)mcknight(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Snapshot synchronization, again... |
Date: | 2011-03-01 04:27:44 |
Message-ID: | AANLkTinUjdt3OFcWoSgXmULDfU_Ux-Om6hKR=ms=bbiM@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 28, 2011 at 6:38 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Remember that it's not only about saving shared memory, it's also
>> about making sure that the snapshot reflects a state of the database
>> that has actually existed at some point in the past. Furthermore, we
>> can easily invalidate a snapshot that we have published earlier by
>> deleting its checksum in shared memory as soon as the original
>> transaction commits/aborts. And for these two a checksum seems to be a
>> good fit. Saving memory then comes as a benefit and makes all those
>> happy who don't want to argue about how many slots to reserve in
>> shared memory or don't want to have another GUC for what will probably
>> be a low-usage feature.
>
> But you can do all of this with files too, can't you? Just remove or
> truncate the file when the snapshot is no longer valid.
Sure we can, but it looked like the consensus of the first discussion
was that the through-the-client approach was more flexible. But then
again nobody is actively arguing for that anymore.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-03-01 04:29:46 | Re: Review: Fix snapshot taking inconsistencies |
Previous Message | Greg Stark | 2011-03-01 03:32:23 | Re: [HACKERS] Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum |