Jeff Davis <pg...@j-davis.com> wrote: > I briefly looked into this when I woke up this morning, and I > think I'm close. I can reproduce it every time, so I should be > able to fix this as soon as I can find some free time (tomorrow > night, probably). OK, I'll focus on other areas. > I might also be able to help with the 2PC issue, but it will be at > least a week or two before I have the free time to dig into that > one. If I get through the other points you raised, I'll start reading up on 2PC. > I didn't quite mean that it's a dead-end. It still seems tempting > to at least try to get a safe snapshot, especially for a > transaction that you know will be long-running. Maybe a timeout or > something? But what would you do when you hit the timeout? 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. That would at least guarantee that the serializable read only deferrable transaction could get its snapshot as soon as the initial set of problem overlapping transactions completed, but it would be an exception to the "SSI introduces no new blocking" guarantee. :-( I was OK with that for the particular transaction where DEFERRABLE was requested, but to have that block other serializable transactions seems pretty iffy to me. Short of that, I think you would just have to wait for completion of all known problem transactions and then try again. On a server with a heave write load, particularly if the length of the writing transactions was highly variable, you could go through a lot of iterations before getting that clean snapshot. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers