From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Frost <jeff@frostconsultingllc.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: update before drop causes OID problems in transaction?
Date: Sat, 18 Mar 2006 01:27:46 -0500
Message-ID: <13574.1142663266@sss.pgh.pa.us> (raw)
In-Reply-To: <Pine.LNX.4.64.0603172012190.11424@discord.dyndns.org>
References: <Pine.LNX.4.64.0603171434230.11424@discord.dyndns.org>
<10754.1142635969@sss.pgh.pa.us>
<Pine.LNX.4.64.0603171454170.11424@discord.dyndns.org>
<Pine.LNX.4.64.0603172012190.11424@discord.dyndns.org>
Jeff Frost <jeff@frostconsultingllc.com> writes:
> I suspect I've answered my own question while preparing the test case. Is it
> the use of pg_get_serial_sequence at the bottom of the transaction? If so,
> why does it only have a problem when there is an update to credit_card_audit
> in the transaction?
No, I think it's that you've got a plpgsql trigger function that
contains queries referring to credit_card_audit. Dropping and
recreating that table invalidates plpgsql's cached plans for those
queries.
We do have in mind to fix this (Neil Conway was poking at it, last
I heard) but it won't happen before 8.2 at the earliest. In the
meantime I'm wondering why you are insistent on dropping and recreating
credit_card_audit, as opposed to something less invasive like TRUNCATE.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, jeff@frostconsultingllc.com
Subject: Re: update before drop causes OID problems in transaction?
In-Reply-To: <13574.1142663266@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox