Re: Autonomous transactions 2023, WIP

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: ivan(dot)kush(at)tantorlabs(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Autonomous transactions 2023, WIP
Date: 2023-12-21 09:35:47
Message-ID: CAFj8pRCty3SqJyOBCsgJK9abfQr4SJLt-aWxQFg93NYHWb_UsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2023-12-21 09:36:06 Re: Synchronizing slots from primary to standby
Previous Message Sutou Kouhei 2023-12-21 09:35:04 Re: Make COPY format extendable: Extract COPY TO format implementations