From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Evgeny Morozov <postgresql3(at)realityexists(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: DROP DATABASE is interruptible |
Date: | 2023-09-25 18:52:23 |
Message-ID: | 20230925185223.ttgkfl3gi6uqtww5@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-09-25 01:48:31 +0100, Peter Eisentraut wrote:
> I noticed that this patch set introduced this pg_dump test:
>
> On 12.07.23 03:59, Andres Freund wrote:
> > + 'CREATE DATABASE invalid...' => {
> > + create_order => 1,
> > + create_sql => q(CREATE DATABASE invalid; UPDATE pg_database SET datconnlimit = -2 WHERE datname = 'invalid'),
> > + regexp => qr/^CREATE DATABASE invalid/m,
> > + not_like => {
> > + pg_dumpall_dbprivs => 1,
> > + },
> > + },
>
> But the key "not_like" isn't used for anything by that test suite. Maybe
> "unlike" was meant?
It's not clear to me either. Invalid databases shouldn't *ever* be dumped, so
explicitly listing pg_dumpall_dbprivs is odd.
TBH, I find this testsuite the most opaque in postgres...
> But even then it would be useless because the "like" key is empty, so there
> is nothing that "unlike" can subtract from. Was there something expected
> from the mention of "pg_dumpall_dbprivs"?
Not that I can figure out...
> Perhaps it would be better to write out
>
> like => {},
>
> explicitly, with a comment, like some other tests are doing.
Yea, that looks like the right direction.
I'll go and backpatch the adjustment.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-09-25 19:42:26 | Re: Performance degradation on concurrent COPY into a single relation in PG16. |
Previous Message | Robert Haas | 2023-09-25 18:45:07 | Re: Eager page freeze criteria clarification |