Re: [streaming replication] 9.1.3 streaming replication bug ?

> Yes, increase wal_keep_segments. Even if you set wal_keep_segments to 64, the amount of disk space for WAL files is only 1GB, so there is no need to worry so much, I think. No?

But when a transaction larger than 1GB...

If synchronous_standby_names = '*', when commit the master wait the standby to commit,
but why the master delete the WAL before sent to standby? And the standby can not commit forever if WAL was deleted.

in http://www.postgresql.org/docs/9.1/static/warm-standby.html
25.2.6. Synchronous Replication says:
When requesting synchronous replication, each commit of a write transaction will wait until confirmation is received that the commit has been written to the transaction log on disk of both the primary and standby server.

25.2.6.1. Basic Configuration says:
This configuration will cause each commit to wait for confirmation that the standby has written the commit record to durable storage, even if that takes a very long time.
.........
After a commit record has been written to disk on the primary, the WAL record is then sent to the standby. The standby sends reply messages each time a new batch of WAL data is written to disk, unless wal_receiver_status_interval is set to zero on the standby.

25.2.6.3. Planning for High Availability says:
Commits made when synchronous_commit is set to on will wait until the sync standby responds. The response may never occur if the last, or only, standby should crash.

So in sync streaming replication, if master delete WAL before sent to the only standby, all transaction will fail forever,
"the master tries to avoid a PANIC error rather than termination of replication." but in sync replication, termination of replication is THE bigger PANIC error.

Another question:
Does master send WAL to standby before the transaction commit ?

-----邮件原件-----
发件人: Fujii Masao [mailto:masao(dot)fujii(at)gmail(dot)com]
发送时间: 2012年4月11日 10:09
收件人: 乔志强
抄送: pgsql-general(at)postgresql(dot)org
主题: Re: [GENERAL] [streaming replication] 9.1.3 streaming replication bug ?

On Wed, Apr 11, 2012 at 10:06 AM, 乔志强 <qiaozhiqiang(at)leadcoretech(dot)com> wrote:
> synchronous_commit is not set, default is "on" ?
> #synchronous_commit = on                # synchronization level; on,
> off, or local

Yes.

>>Otherwise the master might be filled up with lots of unsent WAL files and which might cause PANIC error in the master, when there is no standby.
>>IOW, the master tries to avoid a PANIC error rather than termination of replication.
>
> Can we have a config option for keep unsent WAL file for replication ?

No. We discussed about such feature before, but it had failed to be committed.
I think it's useful, so I hope it'll be usable in the future release.

> How can I do when I need a backup standby server and
>    wal_keep_segments = 3 for save master disk usage(master will delete
> wal before send to standby now when heavy load, Need modify some
> config?)

Yes, increase wal_keep_segments. Even if you set wal_keep_segments to 64, the amount of disk space for WAL files is only 1GB, so there is no need to worry so much, I think. No?

> #checkpoint_segments = 3                # in logfile segments, min 1,
> 16MB each

Increase checkpoint_segments. In this setting, I guess checkpoints run too frequently in heavy load, and WAL files are removed too aggressively.

Regards,

--
Fujii Masao