Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)
Date
Msg-id 201210152044.14233.andres@2ndquadrant.com
Whole thread Raw
In response to Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)  (Hannu Krosing <hannu@2ndQuadrant.com>)
Responses Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)  (Hannu Krosing <hannu@2ndQuadrant.com>)
List pgsql-hackers
On Monday, October 15, 2012 08:38:07 PM Hannu Krosing wrote:
> On 10/11/2012 01:42 PM, Andres Freund wrote:
> > On Thursday, October 11, 2012 09:15:47 AM Heikki Linnakangas wrote:
> > ...
> > If the only meaningful advantage is reducing the amount of WAL written,
> > I can't help thinking that we should just try to address that in the
> > existing solutions, even if it seems "easy to solve at a first glance,
> > but a solution not using a normal transactional table for its log/queue
> > has to solve a lot of problems", as the document says.
> > Youre welcome to make suggestions, but everything I could think of that
> > didn't fall short of reality ended up basically duplicating the amount
> > of writes & fsyncs, even if not going through the WAL.
> > 
> > You need to be crash safe/restartable (=> writes, fsyncs) and you need to
> > reduce the writes (in memory, => !writes). There is only one
> > authoritative point where you can rely on a commit to have been
> > successfull and thats when the commit record has been written to the
> > WAL. You can't send out the data to be committed before thats written
> > because that could result in spuriously committed transactions on the
> > remote side and you can't easily do it afterwards because you can crash
> > after the commit.
> 
> Just curious here, but do you know how is this part solved in current sync
> wal replication - you can get "spurious" commits on slave side id master
> dies while waiting for confirmation.

Synchronous replication is only synchronous in respect to the COMMIT reply sent 
to the user. First the commit is written to WAL locally, so it persists across 
a crash (c.f. RecordTransactionCommit). Only then we wait for the standby 
(SyncRepWaitForLSN). After that finished the shared memory on the primary gets 
updated (c.f. ProcArrayEndTransaction in CommitTransaction) and soon after that 
the user gets the response to the COMMIT back.

I am not really sure what you were asking for, does the above explanation 
answer this?

Greetings,

Andres
-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)
Next
From: Jeff Janes
Date:
Subject: Re: Deprecating Hash Indexes