| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | Zhang Mingli <zmlpostgres(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Prevent COPY FREEZE on Foreign tables |
| Date: | 2025-02-06 16:20:02 |
| Message-ID: | Z6ThMuEmTZLgphhE@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 05, 2025 at 01:36:57PM -0600, Sami Imseih wrote:
>> so the only reason I can see
>> for not back-patching it is that it could lead to somewhat widespread
>> breakage for existing scripts, etc. which are arguably kind-of working
>> today.
>
> That is my thought for not backpatching. It's not breaking the COPY
> command, it's just not applying an optimization.
>
> Let's see what others think.
Given we don't have any other reports or opinions, I'm probably just going
to apply the patch to v18. That leaves the door open to back-patch later.
The next minor release is next week, anyway, and this doesn't seem urgent.
I did find one other thread that mentions this behavior [0]. They floated
the idea of blocking COPY FREEZE on foreign tables, but the topic fizzled
out in indecision. *shrug*
[0] https://postgr.es/m/20181219023814.GA6577%40paquier.xyz
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-02-06 16:26:09 | Re: Prevent COPY FREEZE on Foreign tables |
| Previous Message | Melanie Plageman | 2025-02-06 15:42:43 | Re: Trigger more frequent autovacuums of heavy insert tables |