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
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 |