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-25 00:15:11
Message-ID: 7188.1096071311@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> This means either that the server sent a commit message before it had
>> xlog'd the commit, or that Pgtcl mistakenly reported the command as
>> successful when it was not. Any thoughts?

Oh, fooey.

exec_simple_query calls EndCommand before it calls finish_xact_command,
and of course the latter is where the COMMIT really happens. But
EndCommand puts the 'C' message for the COMMIT into the outbound message
queue.

Under normal circumstances this is no problem because we don't pq_flush
the data to the client until after the commit is done. But suppose
quickdie() is called in between. It will call ereport, which will emit
the WARNING message *and pqflush it*. libpq gets the 'C' message and
therefore reports that the COMMIT is complete. More generally, any sort
of warning message occuring during transaction commit would do the wrong
thing. (Errors chance not to, because those will make libpq replace the
pending COMMAND_OK result with an error result. I'm not sure what the
internal logic in the JDBC driver is, but I guess it acts similarly, or
else we'd have heard about this before from JDBC users.)

Not sure what the cleanest solution is...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory S. Williamson 2004-09-25 00:31:52 Re: tsearch2 poor performance
Previous Message Cott Lang 2004-09-24 23:30:49 implosion follow up, 7.4.5