Re: PostgreSQL 15.10 update corrective action for ATTACH PARTITION/DETACH PARTITION

From: Paul Foerster <paul(dot)foerster(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: PostgreSQL 15.10 update corrective action for ATTACH PARTITION/DETACH PARTITION
Date: 2024-11-29 06:58:38
Message-ID: 8DE45ACE-D7B0-4261-8003-7404518AC5A0@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Tom, hi Alvaro,

> On 27 Nov 2024, at 19:52, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Okay, so I was able to reproduce this from scratch on HEAD:

great, thanks.

> I doubt that there's anything actually wrong with the catalog state at
> this point (perhaps Alvaro would confirm that). That leads to the
> conclusion that what's wrong is the release notes' query for fingering
> broken constraints, and it needs some additional test to avoid
> complaining about (I suspect) self-reference cases.

In the meantime, I updated the whole company. The one test database actually was the only database that this was returned. I found no other occurrences.

As I understand it, the worst thing that could happen is that one or more rows end up in a detached partition table which should actually be in another partition, right? Since there were no rows, no harm could have been done. Also, since this is a self reference, the wrong table is also the right one.

Again, thanks very much for clarifying this.

Cheers
Paul

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2024-11-29 16:12:41 Re: Find out the version of the server
Previous Message Igor Korot 2024-11-29 01:31:10 Find out the version of the server