Re: 7.4.5 losing committed transactions - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: 7.4.5 losing committed transactions
Date
Msg-id 41549CFF.8060502@Yahoo.com
Whole thread Raw
In response to Re: 7.4.5 losing committed transactions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 7.4.5 losing committed transactions  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: 7.4.5 losing committed transactions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 9/24/2004 5:12 PM, Tom Lane wrote:

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

Is it somehow possible that the commit record was still sitting in the 
shared WAL buffers (unwritten) when the response got sent to the client? 
That would be the only possibility I can see right now, because Pgtcl 
used as in that script sits on top of libpq in blocking mode and that 
pretty much outrules early reporting of COMMAND_OK. Fsync/disk-flush 
issues can't be the case either because it was only a PM restart without 
any OS crash involved, and I don't like the idea of <whatever*nix> 
forgetting a write().


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 7.4.5 losing committed transactions
Next
From: Tom Lane
Date:
Subject: Re: 7.4.5 losing committed transactions