From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | InvokeObjectAccessHook versus DROP INDEX CONCURRENTLY |
Date: | 2012-11-28 17:33:42 |
Message-ID: | 8249.1354124022@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2012-11-28 18:10:17 | Re: InvokeObjectAccessHook versus DROP INDEX CONCURRENTLY |
Previous Message | Andrew Dunstan | 2012-11-28 17:04:45 | json accessors |