| From: | fazool mein <fazoolmein(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: xlog.c: WALInsertLock vs. WALWriteLock |
| Date: | 2010-10-26 18:03:55 |
| Message-ID: | AANLkTimd8RMJGWmOpPFR04w0u2+rFLChd4nbhWzN8CgL@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2010-10-26 18:13:57 | Re: xlog.c: WALInsertLock vs. WALWriteLock |
| Previous Message | Robert Haas | 2010-10-26 17:52:50 | Re: Range Types, discrete and/or continuous |