Hi,
On 2022-03-30 12:58:26 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-03-30 12:34:34 -0400, Tom Lane wrote:
> >> One refinement that comes to mind as I look at the patch is to distinguish
> >> between "check" and "installcheck". Not sure that's worthwhile, but not
> >> sure it is
On 3/31/22 12:45, Tom Lane wrote:
>
> On looking closer, the combination of --config-auth and --create-role
> *only* fixes the config files for SSPI, it doesn't expect the server
> to be running.
>
> I agree that the documentation of this is nonexistent and the design
> is probably questionable,
On 3/31/22 14:12, Robert Haas wrote:
> On Thu, Mar 31, 2022 at 12:56 PM Robert Haas wrote:
>> I agree. That's exactly what I said in
>> http://postgr.es/m/CA+TgmoasOhqLR=tsymhd4tyx-qnfwtde_u19zphkunpsckh...@mail.gmail.com
>> ...
> OK, so I pushed a commit adding that incantation to the test scri
On Thu, Mar 31, 2022 at 12:56 PM Robert Haas wrote:
> I agree. That's exactly what I said in
> http://postgr.es/m/CA+TgmoasOhqLR=tsymhd4tyx-qnfwtde_u19zphkunpsckh...@mail.gmail.com
> ...
OK, so I pushed a commit adding that incantation to the test script,
and also a comment explaining why it's th
On Thu, Mar 31, 2022 at 12:45 PM Tom Lane wrote:
> I agree that the documentation of this is nonexistent and the design
> is probably questionable, but I'm not volunteering to fix either.
> If you are, step right up. In the meantime, I believe (without
> having tested) that the correct incantatio
Robert Haas writes:
> On Thu, Mar 31, 2022 at 12:25 PM Andrew Dunstan wrote:
>> Yeah, I think the fix is as simple as the attached.
> Well, that does not work because you added an extra parenthesis which
> makes Perl barf. If you fix that, then the test does not pass because,
> as I just explain
On Thu, Mar 31, 2022 at 12:25 PM Andrew Dunstan wrote:
> Yeah, I think the fix is as simple as the attached.
Well, that does not work because you added an extra parenthesis which
makes Perl barf. If you fix that, then the test does not pass because,
as I just explained to Tom, the flag we call --
On 3/31/22 11:32, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Mar 31, 2022 at 10:52 AM Andrew Dunstan wrote:
>>> We should probably fix the test though, so it doesn't require Unix
>>> sockets. It should be possible, although I haven't looked yet to see how.
>> Our mutual colleague Neha Shar
Hi,
On 2022-03-31 11:32:15 -0400, Tom Lane wrote:
> Robert Haas writes:
> * Rewrite pg_hba.conf and pg_ident.conf to use SSPI authentication. Permit
> * the current OS user to authenticate as the bootstrap superuser and as any
> * user named in a --create-role option.
>
> This script is crea
On Thu, Mar 31, 2022 at 11:32 AM Tom Lane wrote:
> I'm not volunteering to fix that, but this comment in pg_regress.c
> is probably adequately illuminating:
>
> * Rewrite pg_hba.conf and pg_ident.conf to use SSPI authentication. Permit
> * the current OS user to authenticate as the bootstrap su
Robert Haas writes:
> On Thu, Mar 31, 2022 at 10:52 AM Andrew Dunstan wrote:
>> We should probably fix the test though, so it doesn't require Unix
>> sockets. It should be possible, although I haven't looked yet to see how.
> Our mutual colleague Neha Sharma pointed out this email message to me:
On 2022-Mar-30, Andres Freund wrote:
> It looks ugly, and it can't be copy-pasted as easily. Seems I'm alone on this,
> so I'll leave it be...
I'm bothered by that quote-in-the-middle occassionally as well (requires
more clicks to paste).
--
Álvaro Herrera 48°01'N 7°57'E — https
On Thu, Mar 31, 2022 at 10:52 AM Andrew Dunstan wrote:
> I have configured fairywren and drongo to use Unix sockets., and they
> have turned green Here are the settings I'm using in the config's
> build_env section:
>
> PG_TEST_USE_UNIX_SOCKETS => 1,
> PG_REGRESS_SO
On 3/30/22 22:07, Tom Lane wrote:
> So ... none of the Windows buildfarm members actually like this
> test script. They're all showing failures along the lines of
>
> not ok 2 - fails if basebackup_to_shell.command is not set: matches
>
> # Failed test 'fails if basebackup_to_shell.command is
On 31.03.22 07:25, Andres Freund wrote:
Looking at 8f3ec75de40 it seems we just assume unix sockets are available, we
don't have a version / feature test (win32.h just defines
HAVE_STRUCT_SOCKADDR_UN).
I think you have to handle that dynamically at run time, a bit like
IPv6: The build environm
Hi,
On 2022-03-31 00:08:00 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I assume SSPI doesn't work over unix sockets? Oh. Maybe it's not even that -
> > we only enable it when not using unix sockets:
>
> Duh. But can it work over unix sockets?
I wonder if we should go the other way and u
Andres Freund writes:
> On 2022-03-30 22:07:48 -0400, Tom Lane wrote:
>> So ... none of the Windows buildfarm members actually like this
>> test script.
> On windows CI sets
> # Avoids port conflicts between concurrent tap test runs
> PG_TEST_USE_UNIX_SOCKETS: 1
Ok ...
> I assume SSPI d
Hi,
On 2022-03-30 22:07:48 -0400, Tom Lane wrote:
> So ... none of the Windows buildfarm members actually like this
> test script. They're all showing failures along the lines of
>
> not ok 2 - fails if basebackup_to_shell.command is not set: matches
>
> # Failed test 'fails if basebackup_to_
So ... none of the Windows buildfarm members actually like this
test script. They're all showing failures along the lines of
not ok 2 - fails if basebackup_to_shell.command is not set: matches
# Failed test 'fails if basebackup_to_shell.command is not set: matches'
# at t/001_basic.pl line 3
Nathan Bossart writes:
> I think we should give this module a .gitignore file. Patch attached.
Indeed, before somebody accidentally commits the cruft that
check-world is leaving around. Pushed.
regards, tom lane
I think we should give this module a .gitignore file. Patch attached.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 7466f18b7cb781f4db4919faf15b1b1d3cd7bc7a Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 30 Mar 2022 15:28:38 -0700
Subject: [PATCH 1/1] add .gitign
On Wed, Mar 30, 2022 at 4:22 PM Tom Lane wrote:
> Robert Haas writes:
> > I'm going to go ahead and commit this test script later on this
> > afternoon unless there are vigorous objections real soon now, and then
> > if somebody wants to improve it, great!
>
> I see you did that, but the CF entry
Robert Haas writes:
> I'm going to go ahead and commit this test script later on this
> afternoon unless there are vigorous objections real soon now, and then
> if somebody wants to improve it, great!
I see you did that, but the CF entry is still open?
regards, tom lane
Andres Freund writes:
> On 2022-03-30 13:16:47 -0400, Robert Haas wrote:
>> On Wed, Mar 30, 2022 at 1:11 PM Andres Freund wrote:
>>> My concern is about the quote in the middle of the path, not about quoting
>>> at all... I.e. the ' should be after /tmp_install, not before.
>> Makes no differen
Hi,
On 2022-03-30 13:16:47 -0400, Robert Haas wrote:
> On Wed, Mar 30, 2022 at 1:11 PM Andres Freund wrote:
> > On March 30, 2022 9:58:26 AM PDT, Tom Lane wrote:
> > >Andres Freund writes:
> > >> Random aside: Am I the only one bothered by a bunch of places in
> > >> Makefile.global.in quoting
On Thu, Mar 31, 2022 at 5:23 AM Andres Freund wrote:
> On 2022-03-26 13:51:35 -0700, Andres Freund wrote:
> > Prototype patch attached.
>
> Because I forgot about cfbot when attaching the patch, cfbot actually ran with
> it under this thread's cf entry. It does look like an improvement to me:
> h
On Wed, Mar 30, 2022 at 1:11 PM Andres Freund wrote:
> On March 30, 2022 9:58:26 AM PDT, Tom Lane wrote:
> >Andres Freund writes:
> >> Random aside: Am I the only one bothered by a bunch of places in
> >> Makefile.global.in quoting like
> >> $(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_buil
Hi,
On March 30, 2022 9:58:26 AM PDT, Tom Lane wrote:
>Andres Freund writes:
>> Random aside: Am I the only one bothered by a bunch of places in
>> Makefile.global.in quoting like
>> $(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install
>> install >'$(abs_top_builddir)'/tmp_
On Wed, Mar 30, 2022 at 12:54 PM Andres Freund wrote:
> There are some commandline utilities (including copy) where backward slashes
> in arguments are necessary, to separate options from paths :/. Those are the
> extent of backslash use in Cluster.pm that I could see quickly.
I just copied this
Andres Freund writes:
> On 2022-03-30 12:34:34 -0400, Tom Lane wrote:
>> One refinement that comes to mind as I look at the patch is to distinguish
>> between "check" and "installcheck". Not sure that's worthwhile, but not
>> sure it isn't, either.
> As it's just about "free" to do so, I see no
Hi,
On 2022-03-30 12:42:50 -0400, Robert Haas wrote:
> On Wed, Mar 30, 2022 at 12:30 PM Andres Freund wrote:
> > # Reconfigure to restrict access and require a detail.
> > $shell_command =
> > $PostgreSQL::Test::Utils::windows_os
> > ? qq{$gzip --fast > "$escaped_backup_path%d
Hi,
On 2022-03-30 12:34:34 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Unless somebody speaks in favor of doing this across branches, I'd just go
> > for
> > HEAD.
>
> +1 for HEAD only, especially if we think we might change it some more
> later. It seems possible this might break someb
On Wed, Mar 30, 2022 at 12:30 PM Andres Freund wrote:
> # Reconfigure to restrict access and require a detail.
> $shell_command =
> $PostgreSQL::Test::Utils::windows_os
> ? qq{$gzip --fast > "$escaped_backup_path%d.%f.gz"}
> : qq{$gzip --fast > "$escaped_backup_path/%d.%f.g
Andres Freund writes:
> Because I forgot about cfbot when attaching the patch, cfbot actually ran with
> it under this thread's cf entry. It does look like an improvement to me:
> https://cirrus-ci.com/task/6397292629458944?logs=test_world#L900
> We certainly can do better, but it's sufficiently
On 2022-03-30 08:53:43 -0400, Robert Haas wrote:
> Here's a new series, adjusted to use 'gzip' instead of 'cat' and 'type'.
Seems to have done the trick:
https://cirrus-ci.com/task/6474955838717952?logs=test_contrib_basebackup_to_shell#L1
# Reconfigure to restrict access and require a detail.
$
Hi,
On 2022-03-26 13:51:35 -0700, Andres Freund wrote:
> Prototype patch attached.
Because I forgot about cfbot when attaching the patch, cfbot actually ran with
it under this thread's cf entry. It does look like an improvement to me:
https://cirrus-ci.com/task/6397292629458944?logs=test_world#L
On Wed, Mar 30, 2022 at 7:01 AM Andrew Dunstan wrote:
> Triple bleah. If we have to do that at least we should probably use
> `gzip --fast`
I'm not sure it's going to make enough difference to get fussed about,
but sure. Here's a new series, adjusted to use 'gzip' instead of 'cat'
and 'type'.
--
On 3/29/22 20:48, Thomas Munro wrote:
> On Wed, Mar 30, 2022 at 11:25 AM Andres Freund wrote:
>> Didn't immediate find a reference to a cat equivalent. Maybe just gzip the
>> file? That can read from stdin across platforms afaict.
> . o O ( gzip | gzip -d )
>
Triple bleah. If we have to do tha
On Wed, Mar 30, 2022 at 11:25 AM Andres Freund wrote:
> Didn't immediate find a reference to a cat equivalent. Maybe just gzip the
> file? That can read from stdin across platforms afaict.
. o O ( gzip | gzip -d )
On 3/29/22 17:19, Robert Haas wrote:
> On Tue, Mar 29, 2022 at 4:36 PM Thomas Munro wrote:
>> It failed:
>>
>> https://cirrus-ci.com/task/5567070686412800
>> https://api.cirrus-ci.com/v1/artifact/task/5567070686412800/log/contrib/basebackup_to_shell/tmp_check/log/001_basic_primary.log
>> https:/
Hi,
On 2022-03-29 17:19:44 -0400, Robert Haas wrote:
> On Tue, Mar 29, 2022 at 4:36 PM Thomas Munro wrote:
> > It failed:
> >
> > https://cirrus-ci.com/task/5567070686412800
> > https://api.cirrus-ci.com/v1/artifact/task/5567070686412800/log/contrib/basebackup_to_shell/tmp_check/log/001_basic_pri
On Tue, Mar 29, 2022 at 4:36 PM Thomas Munro wrote:
> It failed:
>
> https://cirrus-ci.com/task/5567070686412800
> https://api.cirrus-ci.com/v1/artifact/task/5567070686412800/log/contrib/basebackup_to_shell/tmp_check/log/001_basic_primary.log
> https://api.cirrus-ci.com/v1/artifact/task/5567070686
On Wed, Mar 30, 2022 at 8:30 AM Thomas Munro wrote:
> On Wed, Mar 30, 2022 at 3:08 AM Robert Haas wrote:
> > Here's a new version, hopefully rectifying that deficiency. I also add
> > a second patch here, documenting basebackup_to_shell.required_role,
> > because Joe Conway observed elsewhere tha
On Wed, Mar 30, 2022 at 3:08 AM Robert Haas wrote:
> On Fri, Mar 25, 2022 at 5:52 PM Thomas Munro wrote:
> > On Sat, Mar 26, 2022 at 9:55 AM Thomas Munro wrote:
> > This line doesn't look too healthy:
> >
> > pg_basebackup: error: backup failed: ERROR: shell command "type con >
> > "C:cirruscon
On Fri, Mar 25, 2022 at 5:52 PM Thomas Munro wrote:
> On Sat, Mar 26, 2022 at 9:55 AM Thomas Munro wrote:
> > https://api.cirrus-ci.com/v1/artifact/task/5637156969381888/log/contrib/basebackup_to_shell/tmp_check/log/regress_log_001_basic
>
> This line doesn't look too healthy:
>
> pg_basebackup:
On Sun, Mar 27, 2022 at 12:28 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Sat, Mar 26, 2022 at 4:14 PM Justin Pryzby
> wrote:
> >> I see it here (and in cfbot), although I'm not sure how you created a
> new
> >> patch for the active CF, and not for the next CF.
>
> > Anyone who has ever be
Thomas Munro writes:
> On Sat, Mar 26, 2022 at 4:14 PM Justin Pryzby wrote:
>> I see it here (and in cfbot), although I'm not sure how you created a new
>> patch for the active CF, and not for the next CF.
> Anyone who has ever been a CF manager has this power, it seems. I did
> it myself once,
On Sat, Mar 26, 2022 at 4:14 PM Justin Pryzby wrote:
> I see it here (and in cfbot), although I'm not sure how you created a new
> patch for the active CF, and not for the next CF.
Anyone who has ever been a CF manager has this power, it seems. I did
it myself once, by accident, and got told off
> On 26 Mar 2022, at 21:24, Tom Lane wrote:
> +1, but will it help for CI or buildfarm cases?
Isn't it both, but mostly for CI since the buildfarm already prints the path
when dumping the logfile. Below is a random example snippet from the buildfarm
where it's fairly easy to see 001_basic.pl be
Hi,
On 2022-03-26 16:24:32 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Mar 26, 2022 at 3:35 PM Andres Freund wrote:
> >> === tap tests in src/bin/pg_resetwal ===
> >> t/001_basic.pl .. ok
> >> t/002_corrupted.pl .. ok
> >> All tests successful.
>
> > Yeah, this certainly seems l
Robert Haas writes:
> On Sat, Mar 26, 2022 at 3:35 PM Andres Freund wrote:
>> === tap tests in src/bin/pg_resetwal ===
>> t/001_basic.pl .. ok
>> t/002_corrupted.pl .. ok
>> All tests successful.
> Yeah, this certainly seems like an improvement to me.
+1, but will it help for CI or buildfar
> On 26 Mar 2022, at 21:03, Robert Haas wrote:
>
> On Sat, Mar 26, 2022 at 3:35 PM Andres Freund wrote:
>> === tap tests in src/bin/pg_resetwal ===
>> t/001_basic.pl .. ok
>> t/002_corrupted.pl .. ok
>> All tests successful.
>> Files=2, Tests=18, 3 wallclock secs ( 0.01 usr 0.01 sys + 2.3
On Sat, Mar 26, 2022 at 3:35 PM Andres Freund wrote:
> === tap tests in src/bin/pg_resetwal ===
> t/001_basic.pl .. ok
> t/002_corrupted.pl .. ok
> All tests successful.
> Files=2, Tests=18, 3 wallclock secs ( 0.01 usr 0.01 sys + 2.39 cusr 0.31
> csys = 2.72 CPU)
> Result: PASS
> === tap
Hi,
On 2022-03-26 14:40:06 -0400, Robert Haas wrote:
> Well, I think that's unwarranted. Many years ago, people discovered
> that it was annoying if you had to distinguish files solely based on
> name, and so they invented directories and pathnames. That was a good
> call.
Yea. I have no problem
On Fri, Mar 25, 2022 at 4:09 PM Andrew Dunstan wrote:
> Duplication of TAP test names has long been something that's annoyed me.
Well, I think that's unwarranted. Many years ago, people discovered
that it was annoying if you had to distinguish files solely based on
name, and so they invented dire
On Fri, Mar 25, 2022 at 02:27:07PM -0700, Andres Freund wrote:
> On 2022-03-25 13:52:11 -0400, Robert Haas wrote:
> > On Fri, Mar 25, 2022 at 12:36 PM Andres Freund wrote:
> > > Create a CF entry for it, or enable CI on a github repo?
> >
> > I created a CF entry for it. Then I had to try to Googl
On Sat, Mar 26, 2022 at 9:55 AM Thomas Munro wrote:
> https://api.cirrus-ci.com/v1/artifact/task/5637156969381888/log/contrib/basebackup_to_shell/tmp_check/log/regress_log_001_basic
This line doesn't look too healthy:
pg_basebackup: error: backup failed: ERROR: shell command "type con >
"C:cirr
Hi,
On 2022-03-25 13:52:11 -0400, Robert Haas wrote:
> On Fri, Mar 25, 2022 at 12:36 PM Andres Freund wrote:
> > Create a CF entry for it, or enable CI on a github repo?
>
> I created a CF entry for it. Then I had to try to Google around to
> find the URL from the cfbot, because it's not even lin
On Sat, Mar 26, 2022 at 6:52 AM Robert Haas wrote:
> I don't think that the Windows CI is running the TAP tests for
> contrib. At least, I can't find any indication of it in the output. So
> it doesn't really help to assess how portable this test is, unless I'm
> missing something.
Yeah :-( vcre
On 3/25/22 13:52, Robert Haas wrote:
> On Fri, Mar 25, 2022 at 12:36 PM Andres Freund wrote:
>> Create a CF entry for it, or enable CI on a github repo?
> I created a CF entry for it. Then I had to try to Google around to
> find the URL from the cfbot, because it's not even linked from
> commitf
On Fri, Mar 25, 2022 at 12:36 PM Andres Freund wrote:
> Create a CF entry for it, or enable CI on a github repo?
I created a CF entry for it. Then I had to try to Google around to
find the URL from the cfbot, because it's not even linked from
commitfest.postgresql.org for some reason. #blamemagnu
Hi,
On March 25, 2022 9:22:09 AM PDT, Robert Haas wrote:
>On Thu, Mar 17, 2022 at 11:52 AM Robert Haas wrote:
>> On Tue, Mar 15, 2022 at 3:04 PM Andres Freund wrote:
>> > Seems like this ought to have at least some basic test to make sure it
>> > actually works / keeps working?
>>
>> Wouldn't
On Thu, Mar 17, 2022 at 11:52 AM Robert Haas wrote:
> On Tue, Mar 15, 2022 at 3:04 PM Andres Freund wrote:
> > Seems like this ought to have at least some basic test to make sure it
> > actually works / keeps working?
>
> Wouldn't hurt, although it may be a little bit tricky to getting it
> work
63 matches
Mail list logo
