Re: Failed to delete old ReorderBuffer spilled files

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: atorikoshi <torikoshi_atsushi_z2(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, thomas(dot)munro(at)enterprisedb(dot)com, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Failed to delete old ReorderBuffer spilled files
Date: 2018-01-05 15:30:23
Message-ID: 20180105153023.seas4iankjpiwjyf@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

atorikoshi wrote:

> > FYI "make check" in contrib/test_decoding fails a couple of isolation
> > tests, one with an assertion failure for my automatic patch tester[1].
> > Same result on my laptop:
> >
> > test ondisk_startup ... FAILED (test process exited with exit code 1)
> > test concurrent_ddl_dml ... FAILED (test process exited with exit code 1)
> >
> > TRAP: FailedAssertion("!(!dlist_is_empty(head))", File:
> > "../../../../src/include/lib/ilist.h", Line: 458)
>
> Thanks for letting me know.
> I think I only tested running "make check" at top directory, sorry
> for my insufficient test.
>
> The test failure happened at the beginning of replication(creating
> slot), so there are no changes yet and getting the tail of changes
> failed.
>
> Because the bug we are fixing only happens after creating files,
> I've added "txn->serialized" to the if statement condition.

Ahh, so the reason I didn't see these crashes is that Atsushi had
already fixed them. Nice. It would be *very* good to trim the quoted
material when you reply --- don't leave everything, just enough lines
for context. I would have seen this comment if it didn't require me to
scroll pages and pages and pages of useless material.

I have pushed this patch from 9.4 to master. I reformulated the
comments.

This is an "implicitly aborted transaction":

alvherre=# create table implicit (a int);
CREATE TABLE
Duración: 0,959 ms
alvherre=# insert into implicit select 1/i from generate_series(5, -5, -1) i;
ERROR: division by zero

Note there is no explicit ABORT here, so it is implicit.

But that is not what you were trying to say. The term "crashed
transaction" seems to me to convey the meaning better, so I used that.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-01-05 15:36:19 Re: setting estate in ExecInitNode() itself
Previous Message Tom Lane 2018-01-05 15:28:10 Re: Condition variable live lock