| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "zedaardv(at)drizzle(dot)com" <zedaardv(at)drizzle(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' |
| Date: | 2022-12-16 18:14:31 |
| Message-ID: | 254E87FD-60D6-45B3-AAE5-38B09DBF30C5@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> On 16 Dec 2022, at 17:12, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> The attached removes the change from pg_dump and only prohibits the ALTER TABLE
>> command for attaching the index. Since it will render dumps unable to be
>> restored I also added a check to pg_upgrade to cover the case.
>
> That doesn't seem like a great answer. I understood Peter to be
> favoring both aspects of the previous patch.
Oh, ok, if so then I misunderstood. No worries, v2 is then the one to consider.
--
Daniel Gustafsson https://vmware.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-12-16 18:19:22 | Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' |
| Previous Message | PG Bug reporting form | 2022-12-16 17:52:29 | BUG #17724: All autovacuum workers operate on 1 db at a time |