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

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

In response to

Responses

Browse pgsql-hackers by date

  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)