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

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2013-01-02 03:14:08
Subject: Re: pgsql: Unify some tar functionality across different parts
Previous:From: Tom LaneDate: 2013-01-02 00:15:44
Subject: Re: default SSL compression (was: libpq compression)

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