On 2/4/20 6:20 AM, Doug Roberts wrote:
>> So how did containers_reset_recirc() come to clash with
>> containers_add_update()?
>
> They are clashing because another portion of our system is running and
> updating containers. The reset recirc function was run at the same time
> to see how our system and the database would handle it.
So does your system have the things Tom mentioned below?:
"The known bugs in that area
require either before-row-update triggers on the table, or
child tables (either partitioning or traditional inheritance).
So I wonder what the schema of table "containers" looks like."
>
> The recirc string is formatted like 2000=3,1000=6,5000=0. So the reset
> recirc function with take a UID (1000 for example) and use that to
> remove 1000=x from all of the recirc counts for all of the containers
> that have 1000=x.
>
> We are currently using PG 12.0.
>
> Thanks,
>
> Doug
>
> On Mon, Feb 3, 2020 at 6:21 PM Tom Lane <tgl@sss.pgh.pa.us
> <mailto:tgl@sss.pgh.pa.us>> wrote:
>
> Adrian Klaver <adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>> writes:
> > Please reply to list also.
>
> > On 2/3/20 2:18 PM, Doug Roberts wrote:
> >> Here is what the reset recirc function is doing.
> >> ...
> >> UPDATE containers
> >> ...
>
> > So how did containers_reset_recirc() come to clash with
> > containers_add_update()?
>
> If this is PG 12.0 or 12.1, a likely theory is that this is an
> EvalPlanQual bug (which'd be triggered during concurrent updates
> of the same row in the table, so that squares with the observation
> that locking the table prevents it). The known bugs in that area
> require either before-row-update triggers on the table, or
> child tables (either partitioning or traditional inheritance).
> So I wonder what the schema of table "containers" looks like.
>
> Or you could have hit some new bug ... but there's not enough
> info here to diagnose.
>
> regards, tom lane
>
--
Adrian Klaver
adrian.klaver@aklaver.com