Re: [HACKERS] Walsender timeouts and large transactions

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Yura Sokolov <funny(dot)falcon(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Walsender timeouts and large transactions
Date: 2017-12-14 06:46:35
Message-ID: CAMsr+YHNcsTQMUkDcZOyghQWHB278L8idF4wz+g+JpEu=oiDYA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7 December 2017 at 01:22, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
wrote:

> On 05/12/17 21:07, Robert Haas wrote:
> >
> > Generally we write if (a && b) { ... } not if (a) { if (b) .. }
> >
>
> It's rather ugly with && because one of the conditions is two line, but
> okay here you go. I am keeping the brackets even if normally don't for
> one-liners because it's completely unreadable without them IMHO.
>
>

Yeah, that's why I passed on that FWIW. Sometimes breaking up a condition
is nice. Personally I intensely dislike the convention of

if (big_condition
&& big_condition)
one_linerdo_something;

as awfully unreadable, but I guess code convention means you live with
things you don't like.

Anyway, I've just hit this bug in the wild for the umpteenth time this
year, and I'd like to know what I can do to help progress it to
commit+backport.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2017-12-14 07:21:59 procedures and plpgsql PERFORM
Previous Message Justin Pryzby 2017-12-14 05:49:02 Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL