> On 16 Nov 2022, at 02:02, Michael Paquier wrote:
> On Tue, Nov 15, 2022 at 11:09:54AM +0100, Daniel Gustafsson wrote:
>>> On 15 Nov 2022, at 00:58, Michael Paquier wrote:
>>> It looks like there is a second one in install-windows.sgml.
>>
>> Not sure I follow. IPC::Run is already linked to wi
On Tue, Nov 15, 2022 at 11:09:54AM +0100, Daniel Gustafsson wrote:
>> On 15 Nov 2022, at 00:58, Michael Paquier wrote:
>>
>> On Mon, Nov 14, 2022 at 03:27:14PM +0100, Daniel Gustafsson wrote:
>>> Ugh, yes, that's what it should say.
>>
>> A split sounds fine by me. On top of what Tom has mentio
> On 15 Nov 2022, at 00:58, Michael Paquier wrote:
>
> On Mon, Nov 14, 2022 at 03:27:14PM +0100, Daniel Gustafsson wrote:
>> Ugh, yes, that's what it should say.
>
> A split sounds fine by me. On top of what Tom has mentioned, I have
> spotted two small-ish things.
>
> -This module is avai
On Mon, Nov 14, 2022 at 03:27:14PM +0100, Daniel Gustafsson wrote:
> Ugh, yes, that's what it should say.
A split sounds fine by me. On top of what Tom has mentioned, I have
spotted two small-ish things.
-This module is available from CPAN or an operating system package.
+This module is
> On 14 Nov 2022, at 15:23, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> How about this version?
>
> This isn't correct shell syntax is it?
>
> +PG_TEST_NOCLEAN make -C src/bin/pg_dump check
>
> I think you meant
>
> +PG_TEST_NOCLEAN=1 make -C src/bin/pg_dump check
>
> or the like.
Ugh
Daniel Gustafsson writes:
> How about this version?
This isn't correct shell syntax is it?
+PG_TEST_NOCLEAN make -C src/bin/pg_dump check
I think you meant
+PG_TEST_NOCLEAN=1 make -C src/bin/pg_dump check
or the like.
regards, tom lane
> On 3 Nov 2022, at 12:49, Michael Paquier wrote:
>
> On Wed, Nov 02, 2022 at 09:42:12PM +0100, Daniel Gustafsson wrote:
>> I think that's a good idea, not everyone running tests will read the
>> internals
>> documentation (or even know abou it even). How about the attached?
>
> Thanks for the
On Wed, Nov 02, 2022 at 09:42:12PM +0100, Daniel Gustafsson wrote:
> I think that's a good idea, not everyone running tests will read the internals
> documentation (or even know abou it even). How about the attached?
Thanks for the patch. Perhaps this should be mentioned additionally
in install-
> On 16 Sep 2022, at 04:22, Michael Paquier wrote:
> By the way, should we document PG_TEST_TIMEOUT_DEFAULT and
> PG_TEST_NOCLEAN not only in src/test/perl/README but also doc/?. We
> provide something in the docs about PROVE_FLAGS and PROVE_TESTS, for
> example.
I think that's a good idea, no
On Thu, Sep 22, 2022 at 12:47:34AM -0400, Tom Lane wrote:
> Sure. I'd say we have 48 hours to choose whether to put this in v15.
> But not more than that.
I have a window to be able to look at the buildfarm today, tomorrow
being harder, so I have adjusted that now on both HEAD and
REL_15_STABLE f
Michael Paquier writes:
> On Wed, Sep 21, 2022 at 11:43:56PM -0400, Tom Lane wrote:
>> I don't have any opinion on the concrete merits of this change,
>> but I want to note that 15rc1 wraps on Monday, and we don't like
>> people pushing noncritical changes shortly before a wrap. There
>> is not a
On Wed, Sep 21, 2022 at 11:43:56PM -0400, Tom Lane wrote:
> I don't have any opinion on the concrete merits of this change,
> but I want to note that 15rc1 wraps on Monday, and we don't like
> people pushing noncritical changes shortly before a wrap. There
> is not a lot of time for fooling around
Justin Pryzby writes:
> However the patch ends up, +0.75 to backpatch it to v15 rather than
> calling it a new feature in v16.
I don't have any opinion on the concrete merits of this change,
but I want to note that 15rc1 wraps on Monday, and we don't like
people pushing noncritical changes shortl
On Thu, Sep 22, 2022 at 10:25:11AM +0900, Michael Paquier wrote:
> On Wed, Sep 21, 2022 at 07:31:48PM -0500, Justin Pryzby wrote:
> > I think at some point (maybe before releasing 1.3.4) the range was
> > increased to very large(small), negative levels. It's possible to query
> > the library about
On Wed, Sep 21, 2022 at 07:31:48PM -0500, Justin Pryzby wrote:
> I think at some point (maybe before releasing 1.3.4) the range was
> increased to very large(small), negative levels. It's possible to query
> the library about the lowest supported compression level, but then
> there's a complicatio
On Tue, Sep 13, 2022 at 04:13:20PM +0900, Michael Paquier wrote:
> diff --git a/src/common/compression.c b/src/common/compression.c
> index da3c291c0f..ac26287d54 100644
> --- a/src/common/compression.c
> +++ b/src/common/compression.c
> @@ -249,36 +299,49 @@ expect_integer_value(char *keyword, cha
On Wed, Sep 14, 2022 at 10:26:42AM +0200, Daniel Gustafsson wrote:
> Maybe the creation of $tempdir should take PG_TEST_NOCLEAN into account and
> not
> register CLEANUP if set?
Agreed. It sounds like a good idea to me to extend that to temporary
paths, and then check those rmtree() calls where
> On 13 Sep 2022, at 23:38, Tom Lane wrote:
> The $tempdir is some temporary subdirectory of tmp_check that will get nuked
> at
> the end of the TAP test no matter what. So these rmtrees are merely making
> the
> evidence disappear a bit faster; it will anyway.
Maybe the creation of $tempdir
Michael Paquier writes:
> And so, I have spent a couple of hours torturing the patch, applying
> it after a few tweaks and CI runs:
> ...
> The buildfarm is green so I think that we are good. I have closed the
> open item.
+1, thanks for taking care of that.
As far as my original complaint abou
On Tue, Sep 13, 2022 at 05:38:47PM -0400, Tom Lane wrote:
> is something I tried along the way to diagnosing the problem, and
> it turns out to have exactly zero effect. The $tempdir is some
> temporary subdirectory of tmp_check that will get nuked at the end
> of the TAP test no matter what. So
Michael Paquier writes:
> Attached is the patch I am finishing with, consisting of:
> - the removal of PG_COMPRESSION_OPTION_LEVEL.
> - assigning a default compression level when nothing is specified in
> the spec.
> - a couple of complifications in pg_receivewal, pg_basebackup and the
> backend c
On Sun, Sep 04, 2022 at 02:20:52PM +0900, Michael Paquier wrote:
> ffd5365 has missed that wal_compress_level should be set to
> Z_DEFAULT_COMPRESSION if there is nothing set in the compression
> spec for a zlib build. pg_receivewal.c enforces that already.
So, I have looked at this one. And it
On Sat, Sep 03, 2022 at 11:11:29AM -0400, Tom Lane wrote:
> It makes sense that base.tar.gz is compressed a little better with
> --gzip than with level-1 compression, but why is pg_wal.tar.gz not
> compressed at all? It looks like the problem probably boils down to
> which of "-1" and "0" means "d
I've been trying to figure out why my new buildfarm animal mamba
occasionally fails the pg_basebackup tests [1][2]. I've not run
that to ground yet, but one thing I've found that's consistently
reproducible everywhere is that pg_basebackup's --gzip switch
misbehaves.
24 matches
Mail list logo
