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 <n...@leadboat.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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
