Just a side note that the above combination doesn't work, at least not
if the object access hook tries to make any database state updates.
I've put a hack into index_drop that should detect the case:
/*
* We must commit our transaction in order to make the first pg_index
* state update visible to other sessions. If the DROP machinery
* has already performed any other actions (removal of other objects,
* pg_depend entries, etc), the commit would make those actions
* permanent, which would leave us with inconsistent catalog state
* if we fail partway through the following sequence. Since DROP
* INDEX CONCURRENTLY is restricted to dropping just one index that
* has no dependencies, we should get here before anything's been
* done --- but let's check that to be sure. We can verify that the
* current transaction has not executed any transactional updates by
* checking that no XID has been assigned.
*/
if (GetTopTransactionIdIfAny() != InvalidTransactionId)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("DROP INDEX CONCURRENTLY must be first action in
transaction")));
but I wonder exactly what people think they're going to be doing with
object access hooks, and whether the hook call needs to be done
somewhere else instead.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
