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]
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!
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
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 =
> 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
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
> 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
> 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
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
>
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
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
>
>
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
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
Hi,
Unfortunately DROP DATABASE does not hold interrupt over its crucial steps. If
you e.g. set a breakpoint on DropDatabaseBuffers() and then do a signal
SIGINT, we'll process that interrupt before the transaction commits.
A later connect to that database ends with:
2023-03-14 10:22:24.443 PDT
16 matches
Mail list logo
