Proposal for 9.1: WAL streaming from WAL buffers
in [PgSql]
|
Prev: [HACKERS] Proposal for 9.1: WAL streaming from WAL buffers
Next: [HACKERS] pg_upgrade output directory
From: Tom Lane on 7 Jul 2010 10:11 Dimitri Fontaine <dfontaine(a)hi-media.com> writes: > Stop me if I'm all wrong already, but I though we said that we should > handle this case by decoupling what we can send to the standby and what > it can apply. What's the point of that? It won't make the standby apply any faster. What it will do is make the protocol more complicated, hence slower (more messages) and more at risk of bugs. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 7 Jul 2010 18:44 On 7/6/10 4:44 PM, Robert Haas wrote: > To recap the previous discussion on this thread, we ended up changing > the behavior of 9.0 so that it only sends WAL which has been written > to the OS *and flushed*, because sending unflushed WAL to the standby > is unsafe. The standby can get ahead of the master while still > believing that the databases are in sync, due to the fact that after > an SR reconnect we rewind to the start of the current WAL segment. > This results in a silently corrupt standby database. What was the final decision on behavior if fsync=off? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 7 Jul 2010 18:55 On Wed, Jul 7, 2010 at 6:44 PM, Josh Berkus <josh(a)agliodbs.com> wrote: > On 7/6/10 4:44 PM, Robert Haas wrote: >> To recap the previous discussion on this thread, we ended up changing >> the behavior of 9.0 so that it only sends WAL which has been written >> to the OS *and flushed*, because sending unflushed WAL to the standby >> is unsafe. �The standby can get ahead of the master while still >> believing that the databases are in sync, due to the fact that after >> an SR reconnect we rewind to the start of the current WAL segment. >> This results in a silently corrupt standby database. > > What was the final decision on behavior if fsync=off? I'm not sure we made any decision, per se, but if you use fsync=off in combination with SR and experience an unexpected crash-and-reboot on the master, you will be sad. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: marcin mank on 7 Jul 2010 23:52 > Having said that, I do think we urgently need some high-level design > discussion on how sync rep is actually going to handle this issue > (perhaps on a new thread). If we can't resolve this issue, sync rep > is going to be really slow; but there are no easy solutions to this > problem in sight, so if we want to have sync rep for 9.1 we'd better > agree on one of the difficult solutions soon so that work can begin. > When standbys reconnect after a crash, they could send the ahead-of-the-master WAL to the master. This is an alternative to choosing the most-ahead standby as the new master, as suggested elsewhere. Greetings Marcin Mańk -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 8 Jul 2010 03:51
On Thu, Jul 8, 2010 at 7:55 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: >> What was the final decision on behavior if fsync=off? > > I'm not sure we made any decision, per se, but if you use fsync=off in > combination with SR and experience an unexpected crash-and-reboot on > the master, you will be sad. True. But, without SR, an unexpected crash-and-reboot in the master would make you sad ;) So I'm not sure whether we really need to take action for the case of SR + fsync=off. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |