| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Bruce Momjian <bruce(at)momjian(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Shruthi Gowda <gowdashru(at)gmail(dot)com> |
| Subject: | Re: pg15b2: large objects lost on upgrade |
| Date: | 2022-07-18 20:06:54 |
| Message-ID: | 20220718200654.vuywf5t6q4jh4lgp@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2022-07-18 14:57:40 -0400, Robert Haas wrote:
> As to whether this is a good fix, I think someone could certainly
> argue otherwise. This is all a bit grotty. However, I don't find it
> all that bad. As long as we're moving files from between one PG
> cluster and another using an external tool rather than logic inside
> the server itself, I think we're bound to have some hacks someplace to
> make it all work. To me, extending them to a few more places to avoid
> leaving files behind on disk seems like a good trade-off. Your mileage
> may vary.
How about adding a new binary_upgrade_* helper function for this purpose
instead, instead of tying it into truncate?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2022-07-18 20:09:40 | Re: pg15b2: large objects lost on upgrade |
| Previous Message | Nathan Bossart | 2022-07-18 19:59:09 | Re: Commitfest Update |