GUC option to call run_maintenance() or run_maintenance_proc() #242
Conversation
toliujiayi
force-pushed
the
maintenance_proc
branch
from
4d909e7
to
2a657f5
Compare
|
@keithf4 Hi, I have spent quite some time studying this issue. You mentioned "ERROR: invalid transaction termination" appears when there is actual maintenance work with my solution. I reproduced your findings by creating the sample test table. The actual output is like this: The issue happenes when executing the command COMMIT. In the documentation of CALL function, it says, "If CALL is executed in a transaction block, then the called procedure cannot execute transaction control statements. Transaction control statements are only allowed if CALL is executed in its own transaction." Since COMMIT is a transaction control statement I suspect that the CALL function is executed in a bigger transaction block. Looking through the codes, I found SPI_connect() command is very likely creating a transaction connection because SPI_connect_ext(SPI_OPT_NONATOMIC) can be used to allow transaction control statements. so I tried to close the previous connection and start a new connection with SPI_connect_ext(SPI_OPT_NONATOMIC) before calling SPI_execute if maintenance_proc is being used. However, the same result was still outputted after the change. I then suspected that SPI_execute itself also creates a transaction, although it is not stated in the documentation for SPI_execute. I also tried SPI_prepare and SPI_execute_plan, but with no luck. In short, I had multiple attempts but sadly all failed. Do you have any suggestions for SPI commands that can be used to call a procedure? Thanks, Jack Liu |
|
I'm actually not quite sure off the top of my head. You've actually done more investigation into the issue than I have and know more than me about it currently. Procedures are brand new to PG11, so there may not actually exist a mechanism yet in SPI to allow them to be called with transaction control statements. If hunting through the code doesn't yield anything useful, you could also try asking on the hackers mailing list. Feel free to reference back to this Github PR as an example, but they'll usually want a working example included in emails to the list as well, so it provides full details on anyone reading back through the archives. That would be my next step if I couldn't find the answers in the SPI code. https://www.postgresql.org/list/ |
|
Actually, you'll probably want to try on the general mailing list first before the hackers one. https://www.postgresql.org/list/pgsql-general/ If you don't get an answer there within a week or so, can try hackers then. I thought of hackers first because it may not be a feature that exists yet. |
|
Hi @keithf4, |
|
It looks like this would not have been easily possible with the SPI interface before PG14. This introduced Looking into timescale code, found how they may have done this https://github.com/timescale/timescaledb/blob/main/tsl/src/bgw_policy/job.c#L583 |
|
Version 5.0.0 will now call See commit f4f5517 |
|
Version 5.0.0 has been released. The BGW now calls the procedure instead of the function. I know this PR was quite a long time ago, but if you're still around, thank you for the contribution during GSOC |
No description provided.