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

Re: 7.4.5 losing committed transactions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.4.5 losing committed transactions
Date: 2004-09-26 00:29:41
Message-ID: 23804.1096158581@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I wrote:
> My present theory about the cause is that the backend lost its CPU
> quantum immediately after doing the send() that responded to the last
> INSERT, and was interrupted by SIGQUIT before it could continue.
> If you look at pq_flush() you'll see that it does not reset
> PqSendPointer until it exits.  This means that when quickdie()
> pushes the WARNING into the send buffer, it will be added onto
> what is there --- and then the pq_flush call at the end of ereport
> will transmit that bufferload a second time.

I have applied a patch to prevent this scenario in 7.4 and 8.0 branches.

Next question is whether your original problem was due to this, or
something else.  As far as I can see, this problem occurs *only* when
a SIGQUIT arrives at just the right time, so it seems unlikely to
explain any problems you'd have seen in the field.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-09-26 00:58:37
Subject: Re: Use of zlib
Previous:From: Bruce MomjianDate: 2004-09-25 22:58:01
Subject: Re: 8.0.0beta1: Ownership of implicit sequences after dump/restore

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