Re: [PATCH] Make pg_basebackup configure and start standby [Review] - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Make pg_basebackup configure and start standby [Review]
Date
Msg-id 3748.1357086291@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Make pg_basebackup configure and start standby [Review]  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: [PATCH] Make pg_basebackup configure and start standby [Review]
List pgsql-hackers
Boszormenyi Zoltan <zb@cybertec.at> writes:
> 2013-01-01 17:18 keltez�ssel, Magnus Hagander �rta:
>> That way we can get around the whole need for changing memory allocation across all the 
>> frontends, no? Like the attached.

> Sure it's simpler but then the consistent look of the code is lost.

> What about the other patch to unify pg_malloc and friends?
> Basically all client code boils down to
>      fprintf(stderr, ...)
> in different disguise in their error reporting, so that patch can
> also be simplified but it seems that the atexit() - either explicitly
> or hidden behind InitPostgresFrontend() - cannot be avoided.

Meh.  I find it seriously wrongheaded that something as minor as an
escape_quotes() function should get to dictate both malloc wrappers
and error recovery handling throughout every program that might use it.
I like Magnus' version a lot better than that idea.

A bigger issue that I notice with this code is that it's only correct in
backend-safe encodings, as the comment mentions.  If we're going to be
putting it into frontend programs, how safe is that going to be?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: default SSL compression (was: libpq compression)
Next
From: Hari Babu
Date:
Subject: Re: Review of "pg_basebackup and pg_receivexlog to use non-blocking socket communication", was: Re: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown