Skip site navigation (1) Skip section navigation (2)

Re: SSI predicate locking on heap -- tuple or row?

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: drkp(at)csail(dot)mit(dot)edu, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSI predicate locking on heap -- tuple or row?
Date: 2011-05-30 09:36:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 26.05.2011 06:19, Kevin Grittner wrote:
> 	/*
> 	 * Check whether the writer has become a pivot with an out-conflict
> 	 * committed transaction, while neither reader nor writer is committed. If
> 	 * the reader is a READ ONLY transaction, there is only a serialization
> 	 * failure if an out-conflict transaction causing the pivot committed
> 	 * before the reader acquired its snapshot.  (That is, the reader must not
> 	 * have been concurrent with the out-conflict transaction.)
> 	 */
> 	if (!failure)
> 	{
> 		if (SxactHasSummaryConflictOut(writer))
> 		{
> 			failure = true;
> 			conflict = NULL;
> 		}
> 		else
> 			conflict = (RWConflict)
> 				SHMQueueNext(&writer->outConflicts,
> 							 &writer->outConflicts,
> 							 offsetof(RWConflictData, outLink));
> 		while (conflict)
> 		{
> 			if (SxactIsCommitted(conflict->sxactIn)
> 				&& (!SxactIsCommitted(reader)
> 					|| conflict->sxactIn->commitSeqNo <= reader->commitSeqNo)
> 				&& (!SxactIsCommitted(writer)
> 					|| conflict->sxactIn->commitSeqNo <= writer->commitSeqNo)
> 				&& (!SxactIsReadOnly(reader)
> 					|| conflict->sxactIn->commitSeqNo <= reader->SeqNo.lastCommitBeforeSnapshot))
> 			{
> 				failure = true;
> 				break;
> 			}
> 			conflict = (RWConflict)
> 				SHMQueueNext(&writer->outConflicts,
> 							 &conflict->outLink,
> 							 offsetof(RWConflictData, outLink));
> 		}
> 	}

The comment is not in sync with the code. The code is not checking that 
"neither reader or writer has committed", but something more complicated.

Looking at OnConflict_CheckForSerializationFailure(), it's really hard 
to see how it works, and why the conditions it checks are sufficient. I 
find it helps tremendously to draw the dangerous structures being 
checked, in addition to just explaining them in text. Ascii art is a bit 
clunky, but I think we have to do it here.

I did some of that in the comments, and I think I understand it now. See 
attached patch. Does that look right to you? (note that I swapped the 
second and third check in the function, I think it's more 
straightforward that way). I also added a couple of questions about the 
conditions, marked with XXX comments. Can you answer those, please?

PS. Should we say "Cancelled on identification as pivot, during ...", or 
"Cancelled on identification as a pivot, during ..." ? We seem to use 
both in the error messages.

   Heikki Linnakangas

Attachment: ssi-tuple-not-row-locking-4.patch
Description: text/x-diff (20.4 KB)

In response to

pgsql-hackers by date

Next:From: Gaetano GiuntaDate: 2011-05-30 09:45:26
Subject: adding applications to the stack builder
Previous:From: Tomasz ChmielewskiDate: 2011-05-30 09:18:17
Subject: Re: 'SGT DETAIL: Could not open file "pg_clog/05DC": No such file or directory' - what to do now?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group