Re: oat_post_create expected behavior - Mailing list pgsql-hackers

From Robert Haas
Subject Re: oat_post_create expected behavior
Date
Msg-id CA+TgmoY_oHRT_8poN16jLNFbzhi0aUg_p=FUj_kZO7T9VXH+wQ@mail.gmail.com
Whole thread Raw
In response to oat_post_create expected behavior  (Mary Xu <yxu2162@gmail.com>)
Responses Re: oat_post_create expected behavior
List pgsql-hackers
On Thu, Jun 2, 2022 at 6:37 PM Mary Xu <yxu2162@gmail.com> wrote:
> I was using an object access hook for oat_post_create access while creating an extension and expected that I would be
ableto query for the newly created extension with get_extension_oid(), but it was returning InvalidOid. However, the
sameprocess works for triggers, so I was wondering what the expected behavior is? 
> From the documentation in objectaccess.h, it doesn't mention anything about CommandCounterIncrement() for POST_CREATE
whichimplied to me that it wasn't something I would need to worry about. 
> One option I thought of was this patch where CCI is called before the access hook so that the new tuple is visible in
thehook. Another option would be to revise the documentation to reflect the expected behavior. 

I don't think a proposal to add CommandCounterIncrement() calls just
for the convenience of object access hooks has much chance of being
accepted. Possibly there is some work that could be done to ensure
consistent placement of the calls to post-create hooks so that either
all of them happen before, or all of them happen after, a CCI has
occurred, but I'm not sure whether or not that is feasible. Currently,
I don't think we promise anything about whether a post-create hook
call will occur before or after a CCI, which is why
sepgsql_schema_post_create(), sepgsql_schema_post_create(), and
sepgsql_attribute_post_create() perform a catalog scan using
SnapshotSelf, while sepgsql_database_post_create() uses
get_database_oid(). You might want to adopt a similar technique.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Add index scan progress to pg_stat_progress_vacuum
Next
From: Tomas Vondra
Date:
Subject: Re: pgcon unconference / impact of block size on performance