Re: Synchronous Log Shipping Replication

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Markus Wanner <markus(at)bluegap(dot)ch>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Synchronous Log Shipping Replication
Date: 2008-09-09 12:17:25
Message-ID: 1220962645.3913.456.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.com
PostgreSQL Training, Services and Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-09-09 12:21:14 Re: Synchronous Log Shipping Replication
Previous Message Simon Riggs 2008-09-09 12:08:34 Re: Synchronous Log Shipping Replication