Re: xlog.c: WALInsertLock vs. WALWriteLock

Поиск
Список
Период
Сортировка
От fazool mein
Тема Re: xlog.c: WALInsertLock vs. WALWriteLock
Дата
Msg-id AANLkTimd8RMJGWmOpPFR04w0u2+rFLChd4nbhWzN8CgL@mail.gmail.com
обсуждение исходный текст
Ответ на Re: xlog.c: WALInsertLock vs. WALWriteLock  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: xlog.c: WALInsertLock vs. WALWriteLock  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: xlog.c: WALInsertLock vs. WALWriteLock  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
<br /><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid
rgb(204,204, 204); padding-left: 1ex;"> Might I suggest adopting the same technique walsender does, ie just read<br />
thedata back from disk?  There's a reason why we gave up trying to have<br /> walsender read directly from the
buffers.<br/><br /></blockquote><br /></div>That is exactly what I do not want to do, i.e. read from disk, as long as
thepiece of WAL is available in the buffers. Can you please describe why walsender reading directly from the buffers
wasgiven up? To avoid a lot of locking? <br /> 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
cando more WAL inserts. Hence, reading from buffers might be better in this case.<br /><br />So, as I understand from
theemails, we need to lock both WALWriteLock and WALInsertLock in exclusive mode for reading from buffers. Agreed?<br
/><br/>Thanks.<br /><br /><br /> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Range Types, discrete and/or continuous
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: xlog.c: WALInsertLock vs. WALWriteLock