Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] Make pg_basebackup configure and start standby [Review]

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Make pg_basebackup configure and start standby [Review]
Date: 2013-01-02 08:59:19
Message-ID: 50E3F6E7.2080701@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-hackers
2013-01-02 01:24 keltezéssel, Tom Lane írta:
> Boszormenyi Zoltan <zb(at)cybertec(dot)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.

Actually, the unification of pg_malloc and friends wasn't dictated
by this little code, it was just that pg_basebackup doesn't provide
a pg_malloc implementation (only pg_malloc0) that is used by
initdb's escape_quotes() function. Then I noticed how wide these
almost identical functions have spread into client apps already.

I would say this unification patch is completely orthogonal to
the patch in $SUBJECT. I will post it in a different thread if it's
wanted at all. The extra atexit() handler is not needed if a simple
fprintf(stderr, ...) error reporting is enough in all clients.
As far as I saw, all clients do exactly this but some of them hide
this behind #define's.

> I like Magnus' version a lot better than that idea.

OK, I will post the core patch building on his code.

> 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

The question in a different form is: does PostgreSQL support
non-ASCII-safe encodings at all (or on the client side)? Forgive
my ignorance and enlighten me: how many such encodings
exist besides EBCDIC? Is UTF-16 non-ASCII-safe?

Best regards,
Zoltán Böszörményi

-- 
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
      http://www.postgresql.at/



In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2013-01-02 09:06:14
Subject: Re: pgsql: Unify some tar functionality across different parts
Previous:From: Brendan JurdDate: 2013-01-02 07:37:58
Subject: Function to get size of notification queue?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group