From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dan Ports <drkp(at)csail(dot)mit(dot)edu> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: SSI implementation question |
Date: | 2011-10-19 21:04:52 |
Message-ID: | 19674.1319058292@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dan Ports <drkp(at)csail(dot)mit(dot)edu> writes:
> On Wed, Oct 19, 2011 at 12:56:58PM -0400, Tom Lane wrote:
>> The proposed synchronized-snapshots feature will mean
>> that the allegedly-new snapshot actually was taken some time before,
>> so it seems to me that either this is not necessary or we cannot use
>> a synchronized snapshot in a serializable xact.
> There are definitely potential problems here. If the original snapshot
> doesn't belong to an active serializable transaction, we may have
> discarded the state we need to do SSI, e.g. we might have already
> cleaned up SIREAD locks from concurrent committed transactions.
> I assume the answer here is going to have to be to either refuse to
> start a serializable transaction if that's the case, or make saving a
> snapshot inhibit some of the SSI cleanup.
We can easily mark an exported snapshot with the IsoLevel of the
transaction that made it, and then for example refuse to adopt a
less-than-serializable snapshot into a serializable transaction.
So that aspect can be had if we need it. But we still have a race
condition with the patch as it stands, because there is a window for the
original xact to terminate before GetSerializableTransactionSnapshotInt
runs. It sounds like we have to fix that.
>> In the same vein, why is it necessary to be holding
>> SerializableXactHashLock (exclusively, yet) while acquiring the
>> snapshot? That seems rather bad from a concurrency standpoint, and
>> again it's going to be pretty meaningless if we're just installing a
>> pre-existing snapshot.
> Yes, it's bad. I'm working on a design to address
> SerializableXactHashLock contention, but there needs to be some locking
> here for the reasons I mentioned above. I think the best we can do here
> is to acquire a lock in shared mode when registering a serializable
> transaction and in exclusive mode when committing. (Which is what you'd
> expect, I guess; it's the same story as ProcArrayLock, and for most of
> the same reasons.) Obviously, we'll also want to minimize the amount of
> work we're doing while holding that lock.
I wonder whether it would be prudent to set the synchronized-snapshots
patch aside until you've finished that work (assuming you're actively
working on it). It's evidently going to require some nontrivial changes
in predicate.c, and I don't think the feature should take precedence
over SSI performance improvement.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-10-19 21:13:13 | Re: pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces |
Previous Message | Dan Ports | 2011-10-19 20:53:18 | Re: SSI implementation question |