On Mon, 2010-10-18 at 22:12 -0500, Kevin Grittner wrote:
> Hmmm... When Joe was looking at the patch he exposed an intermittent
> problem with btree indexes which turned out to be related to improper
> handling of the predicate locks during index page clean-up caused by a
> vacuum. Easy to fix once found, but it didn't always happen, even
> with identical runs. (I'm guessing that was due to the randomness in
> picking a page to split when inserting into a group of identical
> keys.) Perhaps a similar bug lurks in the GiST predicate locking.
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).
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.
> > Eventually, we may need to keep statistics about the number of
> > conflicts happening, and start to rate-limit new serializable
> > transactions (effectively reducing parallelism) to ensure that
> > reasonable progress can be made (hopefully faster than serial
> > execution).
>
> Ah, you've exposed just how self-serving my interest in an admission
> control policy mechanism is! ;-)
>
> http://archives.postgresql.org/pgsql-hackers/2009-12/msg02189.php
Cool!
> >> I also *really* hope to add the "SERIALIZABLE READ ONLY
> >> DEFERRABLE" mode so that pg_dump and other read-only transactions
> >> don't push things into a state where the rollback rate spikes:
> >>
> >> http://archives.postgresql.org/pgsql-hackers/2010-09/msg01771.php
> >
> > One potential issue there is starvation. I don't see how you would
> > guarantee that there will ever be a point to grab a safe snapshot,
> > even if all of the other transactions are completing.
>
> After mulling it over in greater detail the previously, I see your
> point. I'll think about it some more, but this particular idea might
> be a dead end.
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?
Regards,Jeff Davis