From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Keepalive for max_standby_delay |
Date: | 2010-05-17 08:40:50 |
Message-ID: | 1274085650.28911.201.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2010-05-16 at 16:53 +0100, Simon Riggs wrote:
> >
> > Attached patch rearranges the walsender loops slightly to fix the above.
> > XLogSend() now only sends up to MAX_SEND_SIZE bytes (== XLOG_SEG_SIZE /
> > 2) in one round and returns to the main loop after that even if there's
> > unsent WAL, and the main loop no longer sleeps if there's unsent WAL.
> > That way the main loop gets to respond to signals quickly, and we also
> > get to update the shared memory status and PS display more often when
> > there's a lot of catching up to do.
> >
> > Comments
>
> 8MB at a time still seems like a large batch to me.
>
> libpq is going to send it in smaller chunks anyway, so I don't see the
> importance of trying to keep the batch too large. It just introduces
> delay into the sending process. We should be sending chunks that matches
> libpq better.
More to the point the logic will fail if XLOG_BLCKSZ > PQ_BUFFER_SIZE
because it will send partial pages.
Having MAX_SEND_SIZE > PQ_BUFFER_SIZE is pointless, as libpq currently
stands.
--
Simon Riggs www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-05-17 10:11:07 | Re: pg_upgrade and extra_float_digits |
Previous Message | Fujii Masao | 2010-05-17 08:33:44 | Re: recovery getting interrupted is not so unusual as it used to be |