| From: | Ajin Cherian <itsajin(at)gmail(dot)com> |
|---|---|
| To: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
| Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: table-write trigger can bypass ATPrepChangePersistence |
| Date: | 2026-09-18 07:32:06 |
| Message-ID: | CAFPTHDbNRm5XWAsmMEUxX=BEa4bCrg0oeFzHwkTwb_JPrZC2Wg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Sep 18, 2026 at 4:43 PM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
>
> Now for a possible fix. Your patch puts the recheck right after the
> event trigger fires. That is inside the per-table loop in
> ATRewriteTables(). The DEFAULT expression runs later in that same
> loop, during the actual rewrite of that table in ATRewriteTable(). So
> the recheck happens too early for this case.
>
> A better place is after the whole loop finishes. This means every
> table has already been rewritten. All DEFAULT and CHECK functions have
> already run. Only then do we check persistence again, for every table
> in the list.
>
Here's a patch with this change incorporated.
regards,
Ajin Cherian
Fujitsu Australia
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Recheck-table-persistence-after-table_rewrite-tri.patch | application/octet-stream | 13.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hayato Kuroda (Fujitsu) | 2026-09-18 07:41:53 | RE: table-write trigger can bypass ATPrepChangePersistence |
| Previous Message | Nazir Bilal Yavuz | 2026-09-18 07:28:29 | aio: worker: Free SMGR objects when idle |