Committed.
--
nathan
On Sun, Oct 27, 2024 at 09:36:38PM -0700, Masahiko Sawada wrote:
> Thank you for your suggestion. IMHO I'm not sure we need to have a
> regression test for this bug as it's just an oversight of recently
> committed code.
Agreed. FWIW cfbot seems to catch this already (CTRL+F for "index_drop" in
t
> Thank you for your suggestion. IMHO I'm not sure we need to have a
> regression test for this bug as it's just an oversight of recently
> committed code. My suggestion was just to help Stepan reproduce this
> failure using TAP tests.
>
>
Yes, I have reproduced the issue manually before your chang
On Sun, Oct 27, 2024 at 5:50 PM Michael Paquier wrote:
>
> On Sun, Oct 27, 2024 at 05:19:45PM -0700, Masahiko Sawada wrote:
> > my $psql1 = $node->interactive_psql('postgres');
> > $psql1->query("create temp table test (a int primary key);");
> > sleep(3);
> >
> > $node->stop('immediate');
> > $no
>
> The assertion failure happens in an autovacuum worker. So if you are
> looking for a test that can be integrated in the tree, you could get
> some inspiration from 006_signal_autovacuum.pl and rely on an
> injection point wait with the existing autovacuum-worker-start. My
> 2c, as it looks ea
On Sun, Oct 27, 2024 at 05:19:45PM -0700, Masahiko Sawada wrote:
> my $psql1 = $node->interactive_psql('postgres');
> $psql1->query("create temp table test (a int primary key);");
> sleep(3);
>
> $node->stop('immediate');
> $node->start();
> $node->safe_psql('postgres', 'select 1');
>
> sleep(5);
On Sun, Oct 27, 2024 at 3:33 AM Stepan Neretin wrote:
>
>
>
>>
>> IIUC after an immediate shutdown all pgstat entries are wiped out so
>> the server doesn't have any pgstat entries for databases at this
>> point. And since we don't run autovacuum on databases that have no
>> pg_stat entries, no au
> IIUC after an immediate shutdown all pgstat entries are wiped out so
> the server doesn't have any pgstat entries for databases at this
> point. And since we don't run autovacuum on databases that have no
> pg_stat entries, no autovacuum worker worked on the 'postgres'
> database. Please try exec
On Sat, Oct 26, 2024 at 12:13 PM Stepan Neretin wrote:
>
> > IMHO the best way to handle this is to just unconditionally push a snapshot
> > in this code path instead of making assumptions about what callers will do.
+1
>
> Yes, I agree! I have found the same solution. I attempted to write Perl
> IMHO the best way to handle this is to just unconditionally push a
snapshot
> in this code path instead of making assumptions about what callers will
do.
Yes, I agree! I have found the same solution. I attempted to write Perl
tests to verify the patch fix, but the autovacuum process is not trigg
On Sat, Oct 26, 2024 at 12:43:44AM -0700, Masahiko Sawada wrote:
> I got the following assertion failure from an autovaucum worker:
>
> 2024-10-26 00:32:03.685 PDT [830672] LOG: autovacuum: dropping orphan
> temp table "postgres.pg_temp_0.hoge"
> TRAP: failed Assert("HaveRegisteredOrActiveSnapsho
Hi,
I got the following assertion failure from an autovaucum worker:
2024-10-26 00:32:03.685 PDT [830672] LOG: autovacuum: dropping orphan
temp table "postgres.pg_temp_0.hoge"
TRAP: failed Assert("HaveRegisteredOrActiveSnapshot()"), File:
"index.c", Line: 2345, PID: 830672
Here is the stack tra
12 matches
Mail list logo
