Re: Extension tracking temp table and causing update failure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Phil Sorber <phil(at)omniti(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Extension tracking temp table and causing update failure
Date: 2012-03-07 22:08:25
Message-ID: 20361.1331158105@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Phil Sorber <phil(at)omniti(dot)com> writes:
> On Wed, Mar 7, 2012 at 1:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 1. If you forget to drop the temp table before ending the script,
>> then when the session ends and the temp table is forcibly dropped,
>> the whole extension goes away (following the rule that a forced drop
>> of an extension member makes the whole extension go away). This is
>> mildly annoying, but since not dropping the temp table is a clear bug
>> in an extension script, I think we can live with it.

> This seems a little bit more than mildly annoying to me.

Well, I didn't say it wasn't annoying, but it would only be catastrophic
if applied to a production database; and it's certainly the sort of
thing you'd notice while testing the extension script. Keep in mind
that those scripts run as superuser, so they can already do arbitrary
amounts of damage to your DB if inadequately tested.

If there were a reasonably non-ugly way to deal with the case I'd be
willing to put it in, but I don't see one. I think the best we can do
is document it.

The other case, which only triggers if the script is run in a previously
virgin backend ID, scares me a lot more because it's the kind of corner
case that could easily escape reasonable testing of an extension script.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2012-03-08 00:27:15 Re: BUG #6480: NLS text width problem
Previous Message Merlin Moncure 2012-03-07 20:49:39 Re: [GENERAL] Altering a table with a rowtype column