Tom Lane wrote:
> 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.
We don't have autonomous transactions currently, but there has been
plenty of talk about adding them. Presumably an access hook could use
them to, say, maintain an audit log. In that case, the autonomous
transaction could very well make other updates before we get to this
point; but I assume the state of the other transaction should not affect
what's going on in the transaction that's running the DROP INDEX
CONCURRENTLY.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services