Re: Snapshot synchronization, again...

Excerpts from Joachim Wieland's message of dom ene 30 14:36:12 -0300 2011:

> On Thu, Jan 20, 2011 at 1:37 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:

> >> > Is it valid to scribble directly on snapshots like this?
> >> I figured that previously executed code still has references pointing
> >> to the snapshots and so we cannot just push a new snapshot on top but
> >> really need to change the memory where they are pointing to.
> > Okay.  Had no special reason to believe otherwise, just didn't know.
>
> This is one part where I'd like someone more experienced than me look into it.

Yeah, I don't like this bit very much. I'm inclined to have the import
routine fill CurrentSnapshot directly (and perhaps ActiveSnapshot too,
not sure about this part yet) instead; I think we need a safety net so
that the new serializable isolation code doesn't get upset if we change
the base snapshot from under it, but I haven't looked at that yet.

Trying to import a snap into a transaction that has committed children
should also fail; otherwise, objects touched during those subxacts would
be in a spooky zone. Also, I want to have Importing into a
read-committed transaction fail with an error instead of the current
warning -- just like LOCK TABLE fails if you're not inside a
transaction.

I'm also inclined to have PREPARE TRANSACTION fail if it has an exported
snapshot, instead of just invalidating it. This lets us get rid of the
extra locking added during that operation.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support