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