Re: [PATCH] minor bugfix for pg_basebackup (9.6 ~ )

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Ian Barwick <ian(dot)barwick(at)2ndquadrant(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] minor bugfix for pg_basebackup (9.6 ~ )
Date: 2019-07-23 08:10:23
Message-ID: 20190723081023.GF2059@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 22, 2019 at 12:58:40PM -0400, Alvaro Herrera wrote:
> Maybe it's just me, but it seems weird to try to forestall a problem
> that cannot occur by definition. I would rather remove the escaping,
> and add a one-line comment explaining why we don't do it?

No objections with doing that either, really. Perhaps you would
prefer pushing a patch among those lines by yourself?

One argument that I got in mind to justify the escaping would be if we
add a new feature in pg_basebackup to write a new set of recovery
options on an existing data folder, which does not require an option.
In this case, if the escaping does not exist, starting the server
would fail with a confusing parsing error if a quote is added to the
slot name. But if the escaping is done, then we would get a correct
error that the replication slot value includes an incorrect character.
If such an hypothetical option is added, most likely this would be
noticed anyway, so that's mainly nannyism from my side.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2019-07-23 08:21:29 Re: Berserk Autovacuum (let's save next Mandrill)
Previous Message Michael Paquier 2019-07-23 08:04:32 Re: Race conditions with TAP test for syncrep