Jeff Davis <pgsql@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
