Re: PostgreSql: Canceled on conflict out to old pivot

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "Wirch, Eduard" <eduard(dot)w(at)smart-host(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: PostgreSql: Canceled on conflict out to old pivot
Date: 2023-12-01 00:31:38
Message-ID: 20231201003138.7riixfp4mn5vmcck@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-11-30 18:51:35 -0500, Tom Lane wrote:
> On what grounds do you assert that? Operations on shared catalogs
> are visible across databases. Admittedly they can't be written by
> ordinary DML, and I'm not sure that we make any promises about DDL
> writes honoring serializability. But I'm unwilling to add
> "optimizations" that assume that that will never happen.

I'd say the issue is more that it's quite expensive to collect the
information. I tried in the past to make the xmin computation in
GetSnapshotData() be database specific, but it quickly shows in profiles, and
GetSnapshotData() unfortunately is really performance / scalability critical.

If that weren't the case, we could check a shared horizon for shared tables,
and a non-shared horizon otherwise.

In some cases we can compute a "narrower" horizon when it's worth the cost,
but quite often we lack the necessary data, because various backends have
stored the "global" xmin in the procarray.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tommy Pavlicek 2023-12-01 00:44:40 Re: [PATCH] ltree hash functions
Previous Message Andres Freund 2023-12-01 00:14:27 Re: Something seems weird inside tts_virtual_copyslot()