Re: pg_waldump and PREPARE

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: pg_waldump and PREPARE
Дата
Msg-id CAHGQGwHvGYsOQiG19qnJ366i632171ge0V66uACCyaCWi3Zu0w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_waldump and PREPARE  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
Ответы Re: pg_waldump and PREPARE  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Fri, Nov 8, 2019 at 1:33 PM Andrey Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
>
>
>
> On 08/11/2019 09:26, Kyotaro Horiguchi wrote:
> > Hello.
> >
> > At Fri, 8 Nov 2019 08:23:41 +0500, Andrey Lepikhov <a.lepikhov@postgrespro.ru> wrote in
> >>> Can I switch the status back to "Needs review"?
> >>> Regards,
> >>>
> >>
> >> One issue is that your patch provides small information. WAL errors
> >> Investigation often requires information on xid, subxacts,
> >> delete-on-abort/commit rels; rarely - invalidation messages etc.

Thanks for the review!

xid is already included in the pg_waldump output for
PREPARE TRANSACTION record. Regarding subxacts, rels and invals,
I agree that they might be useful when diagnosing 2PC-related trouble.
I attached the updated version of the patch that also changes
pg_waldump so that it outputs delete-on-commit rels, delete-on-aborts,
subxacts and invals.

Here is the example of output for PREPARE TRASACTION record, with the pach.

rmgr: Transaction len (rec/tot):    837/   837, tx:        503, lsn:
0/030055C8, prev 0/03005588, desc: PREPARE gid xxx: 2019-11-11
13:00:18.616056 JST; rels(commit): base/12923/16408 base/12923/16407
base/12923/16406 base/12923/16405; rels(abort): base/12923/16412
base/12923/16411 base/12923/16408 base/12923/16407; subxacts: 505;
inval msgs: catcache 50 catcache 49 catcache 50 catcache 49 catcache
50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49
catcache 50 catcache 49 relcache 16386 relcache 16390 relcache 16390
relcache 16386 relcache 16386 relcache 16390 relcache 16390 relcache
16386

> By the way, in the patch xact_desc_prepare seems printing
> parseed.xact_time, which is not actually set by ParsePrepareRecord.

Thanks for the review! You are right.
I fixed this issue in the attached patch.

Regards,

-- 
Fujii Masao

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Remove HeapTuple and Buffer dependency for predicate locking functions
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum