| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Frost <jeff(at)frostconsultingllc(dot)com> |
| Cc: | pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: update before drop causes OID problems in transaction? |
| Date: | 2006-03-18 06:27:46 |
| Message-ID: | 13574.1142663266@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
Jeff Frost <jeff(at)frostconsultingllc(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Frost | 2006-03-18 06:48:57 | Re: update before drop causes OID problems in transaction? |
| Previous Message | Jeff Frost | 2006-03-18 04:20:33 | Re: update before drop causes OID problems in transaction? |