Re: BUG #16867: savepoints vs. commit and chain

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Arthur Nascimento <tureba(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16867: savepoints vs. commit and chain
Date: 2021-02-16 04:49:33
Message-ID: 473dba6b-dfb3-b5a8-93c6-af3787893728@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2021/02/16 6:47, Arthur Nascimento wrote:
> On Mon, 15 Feb 2021 at 17:54, PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
>> On a trivial transaction, I might do:
>>
>> =# begin;
>> *=# commit and chain;
>> *=# -- In this point I'm inside a second transaction
>
> I forgot to mention that this case also works as expected:
>
> =# begin;
> *=# savepoint foo;
> *=# release foo;
> *=# commit and chain;
> *=# -- In this point I'm also inside a second transaction
>
> So it's only the unmatched savepoint/release transactions that are an issue.
>
> I also attached the change I did to psql locally.

LGTM.

> But since it didn't
> solve the issue, it's mostly for curiosity's sake.

In the server side, ISTM that CommitTransactionCommand() needs to handle
the COMMIT AND CHAIN in TBLOCK_SUBCOMMIT case, but it forgot to do that.
Patch attached. I'm not sure if this is a bug or an intentional behavior.
Probably we need to look at the past discussion about AND CHAIN feature.

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

Attachment Content-Type Size
savepoint_and_chain.patch text/plain 2.5 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-02-16 06:45:29 BUG #16869: GROUP BY on primary key unnecessarily triggers a full table scan
Previous Message Michael Paquier 2021-02-16 01:00:17 Re: BUG #16866: pg_basebackup Windows Server 2016