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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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