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

Re: Serialization errors on single threaded request stream

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Serialization errors on single threaded request stream
Date: 2005-08-26 17:16:05
Message-ID: 10329.1125076565@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> What happens if the timestamp of the commit is an exact match for the
> timestamp of the next transaction start?  What is the resolution of
> the time sampling?

It's not done via timestamps: rather, each transaction takes a census
of the transaction XIDs that are running in other backends when it
starts (there is an array in shared memory that lets it get this
information cheaply).  Reliability of the system clock is not a factor.

Are you sure the server is 8.0.3?  There was a bug in prior releases
that might possibly be related:

2005-05-07 17:22  tgl

	* src/backend/utils/time/: tqual.c (REL7_3_STABLE), tqual.c
	(REL7_4_STABLE), tqual.c (REL7_2_STABLE), tqual.c (REL8_0_STABLE),
	tqual.c: Adjust time qual checking code so that we always check
	TransactionIdIsInProgress before we check commit/abort status. 
	Formerly this was done in some paths but not all, with the result
	that a transaction might be considered committed for some purposes
	before it became committed for others.	Per example found by Jan
	Wieck.

My recollection though is that this only affected applications that were
using SELECT FOR UPDATE.  In any case, it's pretty hard to see how this
would affect an application that is in fact waiting for the backend to
report commit-done before it launches the next transaction; the
race-condition window we were concerned about no longer exists by the
time the backend sends CommandComplete.  So my suspicion remains fixed
on that point.  Do you have any way of sniffing the network traffic of
the middle-tier to confirm that it's doing what it's supposed to?

			regards, tom lane

pgsql-bugs by date

Next:From: Kevin GrittnerDate: 2005-08-26 18:27:55
Subject: Re: Serialization errors on single threaded request
Previous:From: Danilo BarbosaDate: 2005-08-26 17:12:22
Subject: BUG #1850: parameter WITH HOLD (of function DECLARE CURSOR) not acepted inside CREATE FUNCTION.

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