Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Oct 19, 2010 at 6:28 PM, Kevin Grittner > <kevin.gritt...@wicourts.gov> wrote: >> One thing that would work, but I really don't think I like it, is >> that a request for a snapshot for such a transaction would not >> only block until it could get a "clean" snapshot (no overlapping >> serializable non-read-only transactions which overlap >> serializable transactions which wrote data and then committed in >> time to be visible to the snapshot being acquired), but it would >> *also* block *other* serializable transactions, if they were >> non-read-only, on an attempt to acquire a snapshot. > > This seems pretty close to guaranteeing serializability by running > transactions one at a time (i.e. I don't think it's likely to be > acceptable from a performance standpoint). It absolutely makes no sense except for long-running read-only transactions, and would only be used when explicitly requested; and like I said, I really don't think I like it even on that basis -- just putting it out there as the only alternative I've found so far to either tolerating possible serialization anomalies in pg_dump output (albeit only when compared to the state the database reached after the dump's snapshot) or waiting indefinitely for a clean snapshot to become available. FWIW from a brainstorming perspective, while waiting for problem transactions to clear so we could get a clean snapshot for the dump I think it would work even better to block the *commit* of serializable transactions which *had done* writes than to block snapshot acquisition for serializable transactions which were not read-only. Still pretty icky, though. I am loathe to compromise the "no new blocking" promise of SSI. [thinks] Actually, maybe we can reduce the probability of needing to retry at each iteration of the non-blocking alternative by checking the conflict information for the problem transactions after they commit. Any transaction which didn't *actually* generate a read-write conflict out to a transaction visible to the dump's candidate snapshot could not cause an anomaly. If none of the problem transactions actually generates a rw-conflict we can use the candidate snapshot. Adding that logic to the non-blocking alternative might actually work pretty well. There might be some workloads where conflicts would be repeatedly generated, but there would be a lot where they wouldn't. If we add a switch to pg_dump to allow users to choose, I think this algorithm works. It never affects a transaction unless it has explicitly requested SERIALIZABLE READ ONLY DEFERRABLE, and the only impact is that startup may be deferred until a snapshot can be acquired which ensures serializable behavior without worrying about SIRead locks. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers