On Tue, Mar 12, 2024 at 9:00 PM Alexander Lakhin wrote:
> I see two backends waiting:
> law 2420132 2420108 0 09:05 ?00:00:00 postgres: node: law
> postgres [local] DROP DATABASE waiting
> law 2420135 2420108 0 09:05 ?00:00:00 postgres: node: law
> postgres [local] st
Hi,
13.07.2023 23:52, Andres Freund wrote:
Backpatching indeed was no fun. Not having BackgroundPsql.pm was the worst
part. But also a lot of other conflicts in tests... Took me 5-6 hours or
so.
But I now finally pushed the fixes. Hope the buildfarm agrees with it...
Thanks for the review!
I
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;
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 = 'inv
> On 13 Jul 2023, at 22:52, Andres Freund wrote:
> On 2023-07-12 11:54:18 +0200, Daniel Gustafsson wrote:
>> Looking more at this I wonder if we in HEAD should make this a bit nicer by
>> extending the --check phase to catch this? I did a quick hack along these
>> lines in the 0003 commit attach
Hi,
On 2023-07-12 11:54:18 +0200, Daniel Gustafsson wrote:
> > On 12 Jul 2023, at 03:59, Andres Freund wrote:
> > On 2023-07-07 14:09:08 +0200, Daniel Gustafsson wrote:
> >>> On 25 Jun 2023, at 19:03, Andres Freund wrote:
> >>> On 2023-06-21 12:02:04 -0700, Andres Freund wrote:
>
> >>> There do
> On 12 Jul 2023, at 03:59, Andres Freund wrote:
> On 2023-07-07 14:09:08 +0200, Daniel Gustafsson wrote:
>>> On 25 Jun 2023, at 19:03, Andres Freund wrote:
>>> On 2023-06-21 12:02:04 -0700, Andres Freund wrote:
>>> There don't need to be explict checks, because pg_upgrade will fail, because
>>>
Hi,
On 2023-07-07 14:09:08 +0200, Daniel Gustafsson wrote:
> > On 25 Jun 2023, at 19:03, Andres Freund wrote:
> > On 2023-06-21 12:02:04 -0700, Andres Freund wrote:
> >> I'm hacking on this bugfix again,
>
> This patch LGTM from reading through and testing (manually and with your
> supplied tests
> On 25 Jun 2023, at 19:03, Andres Freund wrote:
> On 2023-06-21 12:02:04 -0700, Andres Freund wrote:
>> I'm hacking on this bugfix again,
This patch LGTM from reading through and testing (manually and with your
supplied tests in the patch), I think this is a sound approach to deal with
this.
>
Hi,
On 2023-06-21 12:02:04 -0700, Andres Freund wrote:
> I'm hacking on this bugfix again, thanks to Evgeny's reminder on the other
> thread [1].
>
>
> I've been adding checks for partiall-dropped databases to the following places
> so far:
> - vac_truncate_clog(), as autovacuum can't process it
Hi,
On 2023-05-09 15:41:36 +1200, Thomas Munro wrote:
> +# FIXME: It'd be good to test the actual interruption path. But it's not
> +# immediately obvious how.
>
> I wonder if there is some way to incorporate something based on
> SIGSTOP signals into the test, but I don't know how to do it on
> W
Hi,
I'm hacking on this bugfix again, thanks to Evgeny's reminder on the other
thread [1].
I've been adding checks for partiall-dropped databases to the following places
so far:
- vac_truncate_clog(), as autovacuum can't process it anymore. Otherwise a
partially dropped database could easily l
Hi,
On 2023-05-09 15:41:36 +1200, Thomas Munro wrote:
> I tried out the patch you posted over at [1].
Thanks!
> $ psql db2
> psql: error: connection to server on socket "/tmp/.s.PGSQL.5432"
> failed: FATAL: database "db2" is invalid
> DETAIL: Use DROP DATABASE to drop invalid databases
>
> I
On Tue, May 9, 2023 at 3:41 PM Thomas Munro wrote:
> I tried out the patch you posted over at [1].
I forgot to add, +1, I think this is a good approach.
(I'm still a little embarrassed at how long we spent trying to debug
this in the other thread from the supplied clues, when you'd already
point
I tried out the patch you posted over at [1]. For those wanting an
easy way to test it, or test the buggy behaviour in master without
this patch, you can simply kill -STOP the checkpointer, so that DROP
DATABASE hangs in RequestCheckpoint() (or you could SIGSTOP any other
backend so it hangs in th
15 matches
Mail list logo
