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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
