Re: xlog.c: WALInsertLock vs. WALWriteLock - Mailing list pgsql-hackers

From fazool mein
Subject Re: xlog.c: WALInsertLock vs. WALWriteLock
Date
Msg-id AANLkTimd8RMJGWmOpPFR04w0u2+rFLChd4nbhWzN8CgL@mail.gmail.com
Whole thread Raw
In response to Re: xlog.c: WALInsertLock vs. WALWriteLock  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: xlog.c: WALInsertLock vs. WALWriteLock
Re: xlog.c: WALInsertLock vs. WALWriteLock
List pgsql-hackers

Might I suggest adopting the same technique walsender does, ie just read
the data back from disk?  There's a reason why we gave up trying to have
walsender read directly from the buffers.


That is exactly what I do not want to do, i.e. read from disk, as long as the piece of WAL is available in the buffers. Can you please describe why walsender reading directly from the buffers was given up? To avoid a lot of locking?
The locking issue might not be a problem considering synchronous replication. In synchronous replication, the primary will anyways wait for the standby to send a confirmation before it can do more WAL inserts. Hence, reading from buffers might be better in this case.

So, as I understand from the emails, we need to lock both WALWriteLock and WALInsertLock in exclusive mode for reading from buffers. Agreed?

Thanks.


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Range Types, discrete and/or continuous
Next
From: Heikki Linnakangas
Date:
Subject: Re: xlog.c: WALInsertLock vs. WALWriteLock