From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
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 00:24:51 |
Message-ID: | 3748.1357086291@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
> 2013-01-01 17:18 keltezssel, 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2013-01-02 03:14:08 | Re: pgsql: Unify some tar functionality across different parts |
Previous Message | Tom Lane | 2013-01-02 00:15:44 | Re: default SSL compression (was: libpq compression) |