Re: Do we need to handle orphaned prepared transactions in the server?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Kellerer <shammat(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Do we need to handle orphaned prepared transactions in the server?
Date: 2020-04-16 18:26:53
Message-ID: CA+TgmoY790r7nwg7LgCwXOB4-3niBQpruFykPOm9D0YO0pHW9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 16, 2020 at 2:17 PM Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com> wrote:
> So is the concern performance overhead rather than the need for such a feature?

No, I don't think this would have any significant overhead. My concern
is that I think it's the wrong way to solve the problem. If you need
to check for prepared transactions that got missed, the right way to
do that is to use a monitoring tool that runs an appropriate query
against the server on a regular basis and alerts based on the output.
Such a tool can be used for many things, of which this is just one,
and the queries can be customized to the needs of a particular
environment, whereas this feature is much less flexible in that way
because it is hard-coded into the server.

To put that another way, any problem you can solve with this feature,
you can also solve without this feature. And you can solve it any
released branch, without waiting for a release that would
hypothetically contain this patch, and you can solve it in a more
flexible way than this patch allows, because you can tailor the query
any way you like. The right place for a feature like this in something
like check_postgres.pl, not the server. It looks like they added it in
2009:

https://bucardo.org/pipermail/check_postgres/2009-April/000349.html

--
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 Andres Freund 2020-04-16 18:27:14 Re: xid wraparound danger due to INDEX_CLEANUP false
Previous Message Hamid Akhtar 2020-04-16 18:16:29 Re: Do we need to handle orphaned prepared transactions in the server?