From: | Simon Windsor <simon(dot)windsor(at)cornfield(dot)me(dot)uk> |
---|---|
To: | |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Error XX000 After pg11 upgrade |
Date: | 2019-08-16 12:19:15 |
Message-ID: | CADHu9sos3Uycc=QRA1juVjDHb3MKL0KxuViSaOs2p6kcqtD0AQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi
Thanks for all the help, and a couple of offlist suggestions.
We have fixed the problem by copying all of the data (160GB) to a
partitioned table, replacing the trigger with table column defaults for
timestamp and sequence values.
As a result, all is working ok.
Thank you, once again
Simon
On Fri, 16 Aug 2019 at 01:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Windsor <simon(dot)windsor(at)cornfield(dot)me(dot)uk> writes:
> > Since then, large bulk inserts of configuration changes are failing with
> > this Error, but adhoc and small changes are working ok.
>
> Might it be that things work as long as the trigger is only tasked with
> redirecting to the same child table (or limited set of child tables)
> within a particular insertion command?
>
> I'm wondering if this could be related to bug #15913 --- which I just
> fixed today, so maybe I just have it on the brain too much. The
> manifestation doesn't look quite the same, but given the way your
> trigger is written, something about NEW.* changing type from one
> call to the next might have something to do with it.
>
> I also wonder how often you create/delete child tables.
>
> regards, tom lane
>
--
Simon
Simon Windsor
Eml: simon(dot)windsor(at)cornfield(dot)org(dot)uk
Tel: 01454 617689
Mob: 07960 321599
From | Date | Subject | |
---|---|---|---|
Next Message | Luca Ferrari | 2019-08-16 12:23:51 | Re: Question on pgwatch |
Previous Message | stan | 2019-08-16 11:39:39 | A 3 table join question |