BUG #17035: assert after commit

Started by PG Bug reporting formalmost 5 years ago8 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following bug has been logged on the website:

Bug reference: 17035
Logged by: RekGRpth
Email address: rekgrpth@gmail.com
PostgreSQL version: 13.3
Operating system: docker alpine
Description:

after this commit

https://github.com/postgres/postgres/commit/d18ee6f92d9a22b4fae57f515797b2196bf385c7

I got assert

TRAP: FailedAssertion("portal != NULL", File: "pquery.c", Line: 1758)

in my plugin

https://github.com/RekGRpth/pg_task

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: PG Bug reporting form (#1)
Re: BUG #17035: assert after commit

PG Bug reporting form <noreply@postgresql.org> writes:

after this commit
https://github.com/postgres/postgres/commit/d18ee6f92d9a22b4fae57f515797b2196bf385c7
I got assert
TRAP: FailedAssertion("portal != NULL", File: "pquery.c", Line: 1758)
in my plugin
https://github.com/RekGRpth/pg_task

I'm inclined to think that means you were doing something you
should not have been doing. But without any details it's
hard to say.

regards, tom lane

#3RekGRpth
rekgrpth@gmail.com
In reply to: Tom Lane (#2)
Re: BUG #17035: assert after commit

Ok, thanks. I only use SPI_execute_plan and before that commit all works fine
with bst regrds, Rek>pth

ср, 26 мая 2021 г. в 18:52, Tom Lane <tgl@sss.pgh.pa.us>:

Show quoted text

PG Bug reporting form <noreply@postgresql.org> writes:

after this commit
https://github.com/postgres/postgres/commit/d18ee6f92d9a22b4fae57f515797b2196bf385c7
I got assert
TRAP: FailedAssertion("portal != NULL", File: "pquery.c", Line: 1758)
in my plugin
https://github.com/RekGRpth/pg_task

I'm inclined to think that means you were doing something you
should not have been doing. But without any details it's
hard to say.

regards, tom lane

#4Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Tom Lane (#2)
Re: BUG #17035: assert after commit

On 2021-May-26, Tom Lane wrote:

PG Bug reporting form <noreply@postgresql.org> writes:

after this commit
https://github.com/postgres/postgres/commit/d18ee6f92d9a22b4fae57f515797b2196bf385c7
I got assert
TRAP: FailedAssertion("portal != NULL", File: "pquery.c", Line: 1758)
in my plugin
https://github.com/RekGRpth/pg_task

I'm inclined to think that means you were doing something you
should not have been doing. But without any details it's
hard to say.

Hmm, see for example [1]https://github.com/RekGRpth/pg_task/blob/master/work.c#L703 which is doing SPI_prepare_my() [2]https://github.com/RekGRpth/pg_task/blob/master/spi.c and then
SPI_execute_plan_my() ... Does the SPI interface really require that you
create an ActivePortal in the SPI-calling code? This looks a bit
suspicious to me ...

[1]: https://github.com/RekGRpth/pg_task/blob/master/work.c#L703
[2]: https://github.com/RekGRpth/pg_task/blob/master/spi.c

--
�lvaro Herrera Valdivia, Chile

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alvaro Herrera (#4)
Re: BUG #17035: assert after commit

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Hmm, see for example [1] which is doing SPI_prepare_my() [2] and then
SPI_execute_plan_my() ... Does the SPI interface really require that you
create an ActivePortal in the SPI-calling code?

The expectation is that the calling code is already executing inside
some Portal. If it isn't, it's incumbent on the caller to set up
an adequate substitute environment, in particular a transaction
snapshot. The only thing 84f5c2908 changed is that now you get
a guaranteed failure if you neglect to provide that, rather than
failing only in corner cases.

Possibly we should change that Assert to an elog that tries to
make it clear that the blame is on the caller.

regards, tom lane

#6RekGRpth
rekgrpth@gmail.com
In reply to: Tom Lane (#5)
Re: BUG #17035: assert after commit

Ok, I see. But I use SPI_execute_plan in background worker and no
ActivePortal there
with bst regrds, Rek>pth

ср, 26 мая 2021 г. в 22:47, Tom Lane <tgl@sss.pgh.pa.us>:

Show quoted text

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Hmm, see for example [1] which is doing SPI_prepare_my() [2] and then
SPI_execute_plan_my() ... Does the SPI interface really require that you
create an ActivePortal in the SPI-calling code?

The expectation is that the calling code is already executing inside
some Portal. If it isn't, it's incumbent on the caller to set up
an adequate substitute environment, in particular a transaction
snapshot. The only thing 84f5c2908 changed is that now you get
a guaranteed failure if you neglect to provide that, rather than
failing only in corner cases.

Possibly we should change that Assert to an elog that tries to
make it clear that the blame is on the caller.

regards, tom lane

#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: RekGRpth (#6)
Re: BUG #17035: assert after commit

RekGRpth <rekgrpth@gmail.com> writes:

Ok, I see. But I use SPI_execute_plan in background worker and no
ActivePortal there

Well, you need to provide a snapshot. replication/worker.c
might serve as an example.

regards, tom lane

#8RekGRpth
rekgrpth@gmail.com
In reply to: Tom Lane (#7)
Re: BUG #17035: assert after commit

Ok, thanks. I add PushActiveSnapshot(GetTransactionSnapshot()); after
SPI_start_transaction and PopActiveSnapshot(); before SPI_commit and
it works!
with bst regrds, Rek>pth

чт, 27 мая 2021 г. в 08:22, Tom Lane <tgl@sss.pgh.pa.us>:

Show quoted text

RekGRpth <rekgrpth@gmail.com> writes:

Ok, I see. But I use SPI_execute_plan in background worker and no
ActivePortal there

Well, you need to provide a snapshot. replication/worker.c
might serve as an example.

regards, tom lane