| From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | "'Victor Blomqvist *EXTERN*'" <vb(at)viblo(dot)se>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Drop or alter column under load give ERROR #42804 structure of query does not match function result type: |
| Date: | 2015-10-12 08:07:54 |
| Message-ID: | A737B7A37273E048B164557ADEF4A58B50FB7C43@ntex2010i.host.magwien.gv.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Victor Blomqvist wrote:
[race condition causes errors due to stale plans immediately after ALTER TABLE DROP]
> Note that these errors most of the time only happens very briefly at the same time as the ALTER is
> run. When I did some experiments today the server in total had around 3k req/s with maybe 0.1% of them
> touching the table being updated, and the error then happens maybe 1-10% of the times I try this
> operation. If I do the operation on a table with more load the error will happen more frequently.
As far as I gleaned from reading the source, plan cache invalidation happens by signals
sent to the other backends, so I can see why there can be small delays.
I wonder if there is any good way to improve this.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Verite | 2015-10-12 09:22:25 | Re: *** QUESTION *** After successful 'BEGIN;' command -- why PGSQL_TRANSACTION_ACTIVE and not PGSQL_TRANSACTION_INTRANS? |
| Previous Message | Steve Petrie, P.Eng. | 2015-10-12 07:33:58 | Re: *** QUESTION *** After successful 'BEGIN; ' command -- why PGSQL_TRANSACTION_ACTIVE and not PGSQL_TRANSACTION_INTRANS? |