On Sun, Jul 2, 2023 at 6:17 PM Michael Paquier wrote:
> Adjusted that as well, on top of an extra comment.
Thanks all!
--Jacob
On Fri, Jun 30, 2023 at 09:42:13AM +0200, Daniel Gustafsson wrote:
> Agreed, I'd prefer all branches to work the same for this.
Thanks, done this way across all the branches, then.
> Reading the patch, only one thing stood out:
>
> -variable PG_TEST_NOCLEAN is set, data directories will be retai
> On 30 Jun 2023, at 09:09, Michael Paquier wrote:
>
> On Thu, Jun 29, 2023 at 09:05:59AM -0700, Jacob Champion wrote:
>> Sounds good -- 0002 can be ignored as needed, then. (Or I can resend a
>> v3 for CI purposes, if you'd like.)
>
> I am assuming that this is 0001 posted here:
> https://www.p
On Thu, Jun 29, 2023 at 09:05:59AM -0700, Jacob Champion wrote:
> Sounds good -- 0002 can be ignored as needed, then. (Or I can resend a
> v3 for CI purposes, if you'd like.)
I am assuming that this is 0001 posted here:
https://www.postgresql.org/message-id/8be3d35a-9608-b1d5-e5e6-7a744ea45...@tim
On Wed, Jun 28, 2023 at 5:41 PM Michael Paquier wrote:
> Agreed. I am not sure that this is worth changing to have
> boolean-like checks. Hence, I would also to keep the patch that
> checks if the environment variable is defined to enforce the behavior,
> without checking for a specific value.
On Wed, Jun 28, 2023 at 10:45:02AM +0200, Peter Eisentraut wrote:
> Right, the usual style is just to check whether an environment variable is
> set to something, not what it is.
>
> Also note that in general not all environment variables are processed by
> Perl, so I would avoid encoding Perl sem
On 27.06.23 17:54, Dagfinn Ilmari Mannsåker wrote:
However, the docs
(https://www.postgresql.org/docs/16/regress-tap.html#REGRESS-TAP-VARS)
say "If the environment variable PG_TEST_NOCLEAN is set", not "is set to
a true value", and the existing test in PostgreSQL::Test::Cluster's END
block is:
On 2023-06-27 Tu 11:54, Dagfinn Ilmari Mannsåker wrote:
Andrew Dunstan writes:
On 2023-06-26 Mo 19:55, Jacob Champion wrote:
Hello,
I was running the test_pg_dump extension suite, and I got annoyed that
I couldn't keep it from deleting its dump artifacts after a successful
run. Here's a pat
On 6/26/23 22:47, Michael Paquier wrote:
> src/test/perl/README and regress.sgml both describe what
> PG_TEST_NOCLEAN does, and it seems to me that these should be updated
> to tell that temporary files are not removed on top of the data
> folders?
I've added a couple of quick lines to the docs in
Andrew Dunstan writes:
> On 2023-06-26 Mo 19:55, Jacob Champion wrote:
>> Hello,
>>
>> I was running the test_pg_dump extension suite, and I got annoyed that
>> I couldn't keep it from deleting its dump artifacts after a successful
>> run. Here's a patch to make use of PG_TEST_NOCLEAN (which curr
On 2023-06-26 Mo 19:55, Jacob Champion wrote:
Hello,
I was running the test_pg_dump extension suite, and I got annoyed that
I couldn't keep it from deleting its dump artifacts after a successful
run. Here's a patch to make use of PG_TEST_NOCLEAN (which currently
covers the test cluster's base d
> On 27 Jun 2023, at 07:47, Michael Paquier wrote:
>
> On Mon, Jun 26, 2023 at 04:55:47PM -0700, Jacob Champion wrote:
>> I was running the test_pg_dump extension suite, and I got annoyed that
>> I couldn't keep it from deleting its dump artifacts after a successful
>> run. Here's a patch to make
On Mon, Jun 26, 2023 at 04:55:47PM -0700, Jacob Champion wrote:
> I was running the test_pg_dump extension suite, and I got annoyed that
> I couldn't keep it from deleting its dump artifacts after a successful
> run. Here's a patch to make use of PG_TEST_NOCLEAN (which currently
> covers the test c
Hello,
I was running the test_pg_dump extension suite, and I got annoyed that
I couldn't keep it from deleting its dump artifacts after a successful
run. Here's a patch to make use of PG_TEST_NOCLEAN (which currently
covers the test cluster's base directory) with the Test::Utils
tempdirs too.
(Lo
14 matches
Mail list logo
