Re: Autonomous transactions 2023, WIP - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Autonomous transactions 2023, WIP
Date
Msg-id CAFj8pRCty3SqJyOBCsgJK9abfQr4SJLt-aWxQFg93NYHWb_UsA@mail.gmail.com
Whole thread Raw
In response to Autonomous transactions 2023, WIP  (Ivan Kush <ivan.kush@tantorlabs.com>)
Responses Re: Autonomous transactions 2023, WIP
List pgsql-hackers
Hi

although I like the idea related to autonomous transactions, I don't think so this way is the best

1. The solution based on background workers looks too fragile - it can be easy to exhaust all background workers, and because this feature is proposed mainly for logging, then it is a little bit dangerous, because it means loss of possibility of logging.

2. although the Oracle syntax is interesting, and I proposed PRAGMA more times,  it doesn't allow this functionality in other PL

I don't propose exactly  firebird syntax https://firebirdsql.org/refdocs/langrefupd25-psql-autonomous-trans.html, but I think this solution is better than ADA's PRAGMAs. I can imagine some special flag for function like

CREATE OR REPLACE FUNCTION ...
AS $$
$$ LANGUAGE plpgsql AUTONOMOUS TRANSACTION;

as another possibility.

3. Heikki wrote about the possibility to support threads in Postgres. One significant part of this project is elimination of global variables. It can be common with autonomous transactions.

Surely, the first topic should be the method of implementation. Maybe I missed it, but there is no agreement of background worker based.

Regards

Pavel


pgsql-hackers by date:

Previous
From: Sutou Kouhei
Date:
Subject: Re: Make COPY format extendable: Extract COPY TO format implementations
Next
From: shveta malik
Date:
Subject: Re: Synchronizing slots from primary to standby