Re: [HACKERS] Walsender timeouts and large transactions - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [HACKERS] Walsender timeouts and large transactions
Date
Msg-id CAMsr+YHNcsTQMUkDcZOyghQWHB278L8idF4wz+g+JpEu=oiDYA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Walsender timeouts and large transactions  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] Walsender timeouts and large transactions  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
On 7 December 2017 at 01:22, Petr Jelinek <petr.jelinek@2ndquadrant.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

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" inchild table must be marked NOT NULL
Next
From: Ashutosh Bapat
Date:
Subject: procedures and plpgsql PERFORM