Re: PostgreSql: Canceled on conflict out to old pivot

From: "Wirch, Eduard" <eduard(dot)w(at)smart-host(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: PostgreSql: Canceled on conflict out to old pivot
Date: 2023-12-01 08:55:34
Message-ID: CAPX+m-jz=VafjZhz0Qt2m6ZQ8qH2gXPJ0RJrdNaH2_MBAjp+7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks guys for the valuable info. The key take away for me is clear: keep
transactions short under all circumstances.

Cheers,
Eduard

Am Fr., 1. Dez. 2023 um 01:31 Uhr schrieb Andres Freund <andres(at)anarazel(dot)de
>:

> 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2023-12-01 09:00:01 Improving asan/ubsan support
Previous Message Nazir Bilal Yavuz 2023-12-01 08:30:08 Re: Show WAL write and fsync stats in pg_stat_io