Re: Prepared transactions vs novice DBAs, again

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Prepared transactions vs novice DBAs, again
Date: 2009-04-22 18:00:01
Message-ID: 1240423201.2119.93.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2009-04-22 at 13:48 -0400, Tom Lane wrote:

> One line of thought is just to raise the visibility of old prepared
> transactions somehow. I don't think I want to go as far as, say, making
> every session-start issue WARNINGs about every prepared xact that's more
> than a few minutes old. But that might be what it takes to get a DBA's
> attention in the worst case. Do we want to treat old prepared xacts as
> being as dangerous as an impending wraparound?

What about tracking them via autovacuum rounds. E.g; These prepared
transactions were around last round and are still around this round.

WARNING: You have X prepared transactions that are potentially stale

Then perhaps a setting like max_stale_prepared_transaction_age and once
that threshold is met it will autorollback?

> Maybe it'd be helpful
> just to fix the impending-wraparound warnings to include mention of old
> prepared xacts if there are any. But of course, by the time it gets as
> bad as in the recent pgsql-admin case, you've already had enormous
> problems with database bloat.

Yes that would be helpful as well.

>
> Another line of thought is that prepared xacts are inherently a bad
> thing to be using if you have not done careful setup of a lot of
> external infrastructure (in particular, have a transaction monitor
> running somewhere). Therefore, the default out-of-the-box configuration
> of Postgres shouldn't allow PREPARE TRANSACTION at all.

Not sure what I think about this.

> The main
> objection to just setting max_prepared_transactions to zero by default
> is that it would kill our ability to test the feature in the standard
> regression tests.

That kills it for me. Unless we want to change the way we test.

> Anyway, maybe question zero is whether anyone else thinks this is
> important enough to justify extra work in the area.
>

I think that anything that points out lack of or inability for
maintenance to do its thing is probably more important than a lot of the
other stuff we spend time on.

Sincerely,

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-04-22 18:22:57 Re: Prepared transactions vs novice DBAs, again
Previous Message Alvaro Herrera 2009-04-22 17:58:48 Re: trouble with to_char('L')