On 7/27/19 6:52 AM, Alvaro Herrera wrote:
On 2019-Jul-25, Michael Paquier wrote:
On Wed, Jul 24, 2019 at 11:23:30AM -0400, Alvaro Herrera wrote:
Heh, yesterday I revised the original patch as attached and was about to
push when the bell rang. I like this one because it keeps the comment
to
On Fri, Jul 26, 2019 at 05:52:43PM -0400, Alvaro Herrera wrote:
> Yeah, I had removed those on purpose, but that was probably inconsistent
> with my own reviews of others' patches. I pushed it with them.
Thanks!
--
Michael
signature.asc
Description: PGP signature
On 2019-Jul-25, Michael Paquier wrote:
> On Wed, Jul 24, 2019 at 11:23:30AM -0400, Alvaro Herrera wrote:
> > Heh, yesterday I revised the original patch as attached and was about to
> > push when the bell rang. I like this one because it keeps the comment
> > to one line and it mentions the
On Wed, Jul 24, 2019 at 11:23:30AM -0400, Alvaro Herrera wrote:
> Heh, yesterday I revised the original patch as attached and was about to
> push when the bell rang. I like this one because it keeps the comment
> to one line and it mentions the function name in charge of the
> validation (useful
On 2019-Jul-24, Ian Barwick wrote:
> It'd be better if such a hypothetical option validated the provided
> slot name anwyay, to prevent later surprises.
Hmm, but what would we do if the validation failed?
> Revised patch attached, which as Alvaro suggests removes the escaping
> and adds a
On 7/23/19 5:10 PM, Michael Paquier wrote:
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
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
On 2019-Jul-22, Michael Paquier wrote:
> On Sat, Jul 20, 2019 at 10:04:19AM +0900, Michael Paquier wrote:
> > This restriction is unlikely going to be removed, still I would rather
> > keep the escaped logic in pg_basebackup. This is the usual,
> > recommended coding pattern, and there is a risk
On Sat, Jul 20, 2019 at 10:04:19AM +0900, Michael Paquier wrote:
> This restriction is unlikely going to be removed, still I would rather
> keep the escaped logic in pg_basebackup. This is the usual,
> recommended coding pattern, and there is a risk that folks refer to
> this code block for their
On Fri, Jul 19, 2019 at 10:40:42PM +0900, Ian Barwick wrote:
> Good point, it does actually fail with an error if an impossible slot name
> is provided, so the escaping is superfluous anyway.
FWIW, ReplicationSlotValidateName() gives the reason behind that
restriction:
Slot names may consist out
On 7/19/19 7:45 PM, Sergei Kornilov wrote:
Hi
Oh. Replication slot name currently can contains only a-z0-9_ characters. So
we can not actually write such recovery.conf, pg_basebackup will stop
before. But perform escape_quotes on string and not use result - error anyway.
Good point, it does
Hi
Oh. Replication slot name currently can contains only a-z0-9_ characters. So we
can not actually write such recovery.conf, pg_basebackup will stop before. But
perform escape_quotes on string and not use result - error anyway.
regards, Sergei
Hi
In pg_basebackup's GenerateRecoveryConf() function, the value for
"primary_slot_name" is escaped, but the original, non-escaped value
is written. See attached patch.
This has been present since the code was added in 9.6 (commit 0dc848b0314).
Regards
Ian Barwick
--
Ian Barwick
13 matches
Mail list logo
