Re: oat_post_create expected behavior

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Mary Xu <yxu2162(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: oat_post_create expected behavior
Date: 2022-06-06 14:51:12
Message-ID: CA+TgmoY_oHRT_8poN16jLNFbzhi0aUg_p=FUj_kZO7T9VXH+wQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 2, 2022 at 6:37 PM Mary Xu <yxu2162(at)gmail(dot)com> wrote:
> I was using an object access hook for oat_post_create access while creating an extension and expected that I would be able to query for the newly created extension with get_extension_oid(), but it was returning InvalidOid. However, the same process 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 which implied 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 the hook. 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2022-06-06 15:00:56 Re: pgcon unconference / impact of block size on performance
Previous Message Robert Haas 2022-06-06 14:41:54 Re: Add index scan progress to pg_stat_progress_vacuum