> If we support a wrapper we should support it for all pg_ctl usage IMO.
As i understand it - you propose to patch pg_ctl.c & regress.c instead of
PostgresNode.pm & regress.c?
This is a deeper invasion to pg_ctl. There will be a conflict between the
environment variable and the pg_ctl -p parame
> If we support a wrapper we should support it for all pg_ctl usage IMO.
As i understand it - you propose to patch pg_ctl.c & regress.c instead of
PostgresNode.pm & regress.c?
This is a deeper invasion to pg_ctl. There will be a conflict between the
environment variable and the pg_ctl -p parame
This is usable for build installable postgresql.conf.SAMPLE. At the
configure phase, it is possible to include / exclude parameters in the
sample depending on the selected options (--enable - * / - disable- *
etc ..)
On Sat, Mar 28, 2020 at 2:21 PM Peter Eisentraut
wrote:
>
> On 2020-03-28 10:00,
Patch - yes, a good way. but 1) requires invasion to the makefile 2)
makes changes in the file stored on git..
in case postgresql.conf.sample.in is a template, there are no such
problems. and this does not bother those who if someone assumes the
existence of the postgres.conf.sample file
>Even m
ub.com/postgrespro/rum/issues/76). But
under valgrind test execution remaining unacceptably sloow. Patch
above - completely solves the problem.
valgrind_demo.tar.gz
Description: application/gzip
From 85ef5cffe892aed72980898702e31095a13fe6e0 Mon Sep 17 00:00:00 2001
From: "Ivan N. Taranov&quo
On Fri, Feb 21, 2020 at 4:49 AM Craig Ringer wrote:
> I thought I saw a related patch to this that proposed to add a pg_ctl
> argument. Was that you too? I can't find it at the moment.
This very simple two-line patch for src/test/perl/PostgresNode.pm code,
it set `pg_ctl -p ` argument, and one-