Re: Review items for EXCEPT TABLE publication

On Thu, Sep 10, 2026 at 5:11 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Dear Vignesh,
>
> > Thanks kuroda-san. I have addressed this in the v2 version patch
> > attached, however I did not change the lock mode and used the existing
> > AccessShareLock mode itself as I felt that should suffice. This
> > approach also addresses Chao's comments from [1].
>
> My intention was similar but can we unify codes for re-validation?
> My idea attached here could be applied atop v2.
>

Fair enough. But why do we want to change the order of heap_freetuple
in the following change?

- heap_freetuple(tup);
+ LockDatabaseObject(PublicationRelationId, pubid, 0,
+ stmt->options ? AccessShareLock : AccessExclusiveLock);

- /*
- * It is possible that by the time we acquire the lock on publication,
- * concurrent DDL has removed it. We can test this by checking the
- * existence of publication. We get the tuple again to avoid the risk
- * of any publication option getting changed.
- */
- tup = SearchSysCacheCopy1(PUBLICATIONOID,
- ObjectIdGetDatum(pubid));
- if (!HeapTupleIsValid(tup))
- ereport(ERROR,
- errcode(ERRCODE_UNDEFINED_OBJECT),
- errmsg("publication \"%s\" does not exist",
- stmt->pubname));
+ heap_freetuple(tup);

--
With Regards,
Amit Kapila.