| 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: | Whole Thread | Raw Message | 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
| 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 |