Re: autonomous transactions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: autonomous transactions
Date: 2016-09-02 08:45:55
Message-ID: CA+TgmoYZUbx5oLQ=2ShiGfLsU+W0=cs9vP+Fq_rWDbpRTyqK5A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 31, 2016 at 7:20 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> I would like to propose the attached patch implementing autonomous
> transactions for discussion and review.

I'm pretty skeptical of this approach. Like Greg Stark, Serge Rielau,
and Constantin Pan, I had expected that autonomous transactions should
be implemented inside of a single backend, without relying on workers.
That approach would be much less likely to run afoul of limits on the
number of background workers, and it will probably perform
considerably better too, especially when the autonomous transaction
does only a small amount of work, like inserting a log message
someplace. That is not to say that providing an interface to some
pg_background-like functionality is a bad idea; there's been enough
interest in that from various quarters to suggest that it's actually
quite useful, and I don't even think that it's a bad plan to integrate
that with the PLs in some way. However, I think that it's a different
feature than autonomous transactions. As others have also noted, it
can be used to fire-and-forget a command, or to run a command while
foreground processing continues, both of which would be out of scope
for an autonomous transaction facility per se. So my suggestion is
that you pursue the work but change the name.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2016-09-02 08:50:17 Re: Logical decoding slots can go backwards when used from SQL, docs are wrong
Previous Message Robert Haas 2016-09-02 08:34:24 Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)