From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Transaction-controlled robustness for replication |
Date: | 2008-08-12 16:54:41 |
Message-ID: | 1218560081.5343.64.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2008-08-12 at 11:51 -0400, Bruce Momjian wrote:
> I think you need to make it an enumerated type like log_min_messages;
> something like:
>
> wal_transfer_wait
Yeh, that way sounds best and I like name.
> with values of:
>
> nothing: have network traffic send WAL as needed
> netflush: wait for flush of WAL network packets to slave
> process: wait for slave to process WAL traffic and
> optionally fsync
Suggest
async
syncnet
syncdisk
> The 'process' option either waits for fsync on the slave or not
> depending on how the slave is configured, meaning you could use
> synchronous_commit off to not wait for the fsync to disk.
Hmmm, not sure that flicking a switch on the standby should cause a loss
of performance on the master. That will be an accident waiting to
happen. Best to make all things that effect the performance/robustness
of the master be configuration options on the master side.
> I think we can add a table in the documention to show how to set things
> up in postgresql.conf for async master and async slave, and other
> combinations.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-08-12 16:54:54 | Re: Transaction-controlled robustness for replication |
Previous Message | Bruce Momjian | 2008-08-12 16:48:08 | Re: Transaction-controlled robustness for replication |