Re: pg_decode_message vs skip_empty_xacts and xact_wrote_changes

Поиск
Список
Период
Сортировка
От vignesh C
Тема Re: pg_decode_message vs skip_empty_xacts and xact_wrote_changes
Дата
Msg-id CALDaNm1bfwt=hmZD7V17t-giJLw3kndLBxLzSD+oSXNfMmGVsw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_decode_message vs skip_empty_xacts and xact_wrote_changes  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: pg_decode_message vs skip_empty_xacts and xact_wrote_changes  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Список pgsql-hackers
On Mon, 26 Jun 2023 at 15:51, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Jun 26, 2023 at 3:07 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > Hi All,
> > Every pg_decode routine except pg_decode_message  that decodes a
> > transactional change, has following block
> > /* output BEGIN if we haven't yet */
> > if (data->skip_empty_xacts && !txndata->xact_wrote_changes)
> > {
> > pg_output_begin(ctx, data, txn, false);
> > }
> > txndata->xact_wrote_changes = true;
> >
> > But pg_decode_message() doesn't call pg_output_begin(). If a WAL
> > message is the first change in the transaction, it won't have a BEGIN
> > before it. That looks like a bug. Why is pg_decode_message()
> > exception?
> >
>
> I can't see a reason why we shouldn't have a similar check for
> transactional messages. So, agreed this is a bug.

Here is a patch having the fix for the same. I have not added any
tests as the existing tests cover this scenario. The same issue is
present in back branches too.
v1-0001-Call-pg_output_begin-in-pg_decode_message-if-it-i_master.patch
can be applied on master, PG15 and PG14,
v1-0001-Call-pg_output_begin-in-pg_decode_message-if-it-i_PG13.patch
patch can be applied on PG13, PG12 and PG11.
Thoughts?

Regards,
Vignesh

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Changing types of block and chunk sizes in memory contexts
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Row pattern recognition