On Tue, 2008-09-09 at 20:12 +0900, Fujii Masao wrote:
> I'd like to introduce new parameter "synchronous_replication" which specifies
> whether backends waits for the response from WAL sender process. By
> combining synchronous_commit and synchronous_replication, users can
> choose various options.
We already discussed that on -hackers. See "Transaction Controlled
Robustness". But yes, something like that.
Please note the design mentions fsyncing after applying WAL. I'm sure
you're aware we don't fsync after *applying* WAL now, and I hope we
never do. You might want to fsync data to WAL files on the standby, but
that is a slightly different thing.
> > After (or during) XLogInsert backends will sleep in a proc queue,
> > similar to LWlocks and protected by a spinlock. When preparing to
> > write/send the WAL process should read the proc at the *tail* of the
> > queue to see what the next LogwrtRqst should be. Then it performs its
> > action and wakes procs up starting with the head of the queue. We would
> > add LSN into PGPROC, so WAL processes can check whether the backend
> > should be woken. The LSN field can be accessed without spinlocks since
> > it is only ever set by the backend itself and only read while a backend
> > is sleeping. So we access spinlock, find tail, drop spinlock then read
> > LSN of the backend that (was) the tail.
>
> You mean only XLogInsert treating "commit record" or every XLogInsert?
Just the commit records, when synchronous_commit = on.
> Anyway, ISTM that the response time get worse :(
No, because it would have had to wait in the queue for the WALWriteLock
while prior writes occur.
If the WALWriter sleeps on a semaphore, it too can be nudged into action
at the appropriate time, so no need for a delay between backend
beginning to wait and WALWriter beginning to act. (Well, IPC delay
between two processes, so some, but that is balanced against efficiency
of Send).
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
