Re: Failed to delete old ReorderBuffer spilled files
От | atorikoshi |
---|---|
Тема | Re: Failed to delete old ReorderBuffer spilled files |
Дата | |
Msg-id | e6d10adb-c705-02c5-0663-dfc6d79c80d9@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Failed to delete old ReorderBuffer spilled files (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: Failed to delete old ReorderBuffer spilled files
|
Список | pgsql-hackers |
On 2017/11/24 10:57, Craig Ringer wrote: > On 24 November 2017 at 09:20, atorikoshi <torikoshi_atsushi_z2@lab.ntt.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. -- Atsushi Torikoshi NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Вложения
В списке pgsql-hackers по дате отправления: