| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Cc: | shihao zhong <zhong950419(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Antonin Houska <ah(at)cybertec(dot)at> |
| Subject: | Re: REPACK: warn about skipping foreign partitions |
| Date: | 2026-10-11 15:48:21 |
| Message-ID: | CAHGQGwFBWRoaL9iZb-FFXoupdYPJzQt1F7FHuPwTYWSM32xz0w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Oct 11, 2026 at 2:28 AM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> That was an oversight, it's fixed in v4.
Thanks for updating the patch!
+ if (rel_is_index)
+ inhoids = find_all_inheritors(relid, NoLock, NULL);
It's better to call list_free(inhoids) before replacing it with the index
OID list? The table OID list is no longer needed after the warning loop.
Especially when an index is specified, the patch adds another
find_all_inheritors() call and loop while holding AccessExclusiveLock on
the parent. Is this overhead unnoticeable and acceptable for tables
with many small partitions?
> The 'without locking' part seems good to me. We already have
> AccessExclusiveLock on the parent, and we never actually open the
> foreign partitions. And this is a preexisting repack design (checking
> permissions without locking first, and then checking again after
> locking, just before processing it)
Understood.
So a partition can be dropped concurrently while warnings are being
issued for foreign partitions, and get_rel_name(tableoid) can return NULL
before the warning is emitted. Is that correct? If so, as in
repack_is_permitted_for_relation(), we should check whether
get_rel_name(tableoid) returns NULL and skip the warning if it does?
Regards,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-10-11 15:56:32 | Re: Wrong results from an antijoin |
| Previous Message | Muzzammil Sarwar | 2026-10-11 15:31:00 | [PATCH] Fix leak when a plpgsql exception block catches an error from CALL |