From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Changeset Extraction v7.9.1 |
Date: | 2014-03-10 18:54:06 |
Message-ID: | CA+TgmoaMk78RqMP5=Oh++NWhYac+JK_9ohOoq0XWtQTeonodpg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 7, 2014 at 7:44 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> I've attached a new version of the walsender patch. It's been rebased
> ontop of Heikki's latest commit to walsender.c. I've changed a fair bit
> of stuff:
> * The sleeptime is now computed to sleep until we either need to send a
> keepalive or kill ourselves, as Heikki sugggested.
> * Sleep time computation, sending pings, checking timeouts is now done
> in separate functions.
> * Comment and codestyle improvements.
>
> Although they are shorter and simpler now, I have not managed to unify
> the three loops however. They seem to be too different to unify them
> inside one. I tried a common function with an 'wait_for' bitmask
> argument, but that turned out to be fairly illegible. The checks in
> WalSndWaitForWal() and WalSndLoop() just seem to be too different.
>
> I'd be grateful if you (or somebody else!) could have a quick look at
> body of the loops in WalSndWriteData(), WalSndWaitForWal() and
> WalSndLoop(). Maybe I am just staring at it the wrong way.
I've committed this patch now with a few further tweaks, leaving this
issue unaddressed. It may well be something that needs improvement,
but I don't think it's a big enough issue to justify holding back a
commit.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-03-10 18:59:40 | Re: Patch: show relation and tuple infos of a lock to acquire |
Previous Message | Pavel Stehule | 2014-03-10 18:40:42 | Re: pg_upgrade on high number tables database issues |