Re: Proposal for 9.1: WAL streaming from WAL buffers - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: Proposal for 9.1: WAL streaming from WAL buffers
Date
Msg-id 3A3E45C4-3078-45B2-8AE7-9C4758E8F7F8@phlo.org
Whole thread Raw
In response to Re: Proposal for 9.1: WAL streaming from WAL buffers  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Jun 15, 2010, at 10:45 , Fujii Masao wrote:
> A transaction commit would need to wait for local fsync and replication
> in a serial manner, in synchronous replication. IOW, walsender cannot
> send the commit record until it's fsync'd in XLogWrite().

Hm, but since 9.0 won't do synchronous replication anyway, the right thing to do for 9.0 is still to send only fsync'ed
WAL,no? Without synchronous replication the overhead seems negligible. 

For synchronous replication (and hence for 9.1) I think there are two basic options

a) Stream only fsync'ed WAL, like in the asynchronous case. Depending on policy, additionally wait for one or more
slavesto fsync before reporting success. 

b) Stream non-fsync'ed WAL. on COMMIT, wait for at last one node (not necessarily the master, exact count depends on
policy)to fsync before reporting success. During recovery of the master, recover up to the latest LSN found on any one
ofthe nodes. 

Option (b) requires some additional thought, though. Controlled removal of slave nodes and concurrent crashes of more
thanone node are the most difficult areas to handle gracefully, it seems. 

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Proposal for 9.1: WAL streaming from WAL buffers
Next
From: Florian Pflug
Date:
Subject: Re: [BUGS] Server crash while trying to read expression using pg_get_expr()