Skip site navigation (1) Skip section navigation (2)

Re: Snapshot synchronization, again...

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Joachim Wieland <joe(at)mcknight(dot)de>
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-02-28 17:38:21
Message-ID: AANLkTikQABMFxa_uaeG2mdiWxq-07Yq7yd8GeThQGNcj@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Feb 27, 2011 at 8:33 PM, Joachim Wieland <joe(at)mcknight(dot)de> wrote:
> On Sun, Feb 27, 2011 at 3:04 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> Why exactly, Heikki do you think the hash is more troublesome?
>> It just feels wrong to rely on cryptography just to save some shared memory.
>
> 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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-02-28 17:45:45
Subject: Re: pl/python custom exceptions for SPI
Previous:From: Tom LaneDate: 2011-02-28 17:20:45
Subject: Re: PL/pgSQL return value in after triggers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group