From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Serializable snapshot isolation patch |
Date: | 2010-10-19 19:07:34 |
Message-ID: | 1287515254.19864.27.camel@jdavis-ux.asterdata.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-10-19 19:17:09 | Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP) |
Previous Message | Robert Haas | 2010-10-19 19:03:10 | Re: Creation of temporary tables on read-only standby servers |