Re: Failed to delete old ReorderBuffer spilled files - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Failed to delete old ReorderBuffer spilled files
Date
Msg-id CAMsr+YGHkCA4LB=Q+Qr24+muMqcUEDgKC879Zg_xJXw-bAFxWw@mail.gmail.com
Whole thread Raw
In response to Re: Failed to delete old ReorderBuffer spilled files  (atorikoshi <torikoshi_atsushi_z2@lab.ntt.co.jp>)
List pgsql-hackers
On 24 November 2017 at 12:38, atorikoshi wrote: > > > On 2017/11/24 10:57, Craig Ringer wrote: > > On 24 November 2017 at 09:20, atorikoshi co.jp > >> wrote: > > > >> > >> 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. > > > > > > Thanks. > > > > Re-reading the patch I see > > > > * The final_lsn of which transaction that hasn't produced an abort > > * record is invalid. > > > > which I find very hard to parse. I suggest: > > > > We set final_lsn when we decode the commit or abort record for a > > transaction, > > but transactions implicitly aborted by a crash never write such a > record. > > > > then continue from there with the same text as in the patch. > > > > Otherwise I'm happy. It passes make check, test decoding and the recovery > > TAP tests too. > > > > Thanks for your kind suggestion and running test. > I've added your comment at the beginning. > > Marked ready for committer. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Rafia Sabih
Date:
Subject: Re: [HACKERS] Parallel Append implementation
Next
From: Nikhil Sontakke
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions