On Thu, 2007-03-29 at 17:27 -0400, Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > ISTM that the run-another-transaction-afterwards idea is the only one > > that does everything I think we need. I really do wish we could put in a > > wait, like CIC, but I just think it will break existing programs. > > Actually, there's a showstopper objection to that: plain CREATE INDEX > has to be able to run within a larger transaction. (To do otherwise > breaks "pg_dump --single-transaction", just for starters.) This means > it can *not* commit partway through.
I agree with most of that, but thats why we-are-where-we-are and I don't think its a showstopper at all. The idea is to make note that the transaction has created an index within a transaction block, so that after the top level transaction commits we sneak in an extra hidden transaction to update the pg_index tuple with the xcreate of the first transaction. We don't do this after the CREATE INDEX statement ends, only at the end of the transaction in which it ran. We only do this if we are creating an index on a table that is not a temporary table and was not created during the transaction (so --single-transaction isn't broken and doesn't require this additional action). i.e. MyTransactionCreatedVisibleIndex, with special processing in xact.c. The only other alternative is to forcibly throw a relcache inval event in the same circumstances without running the additional transaction, but the solution is mostly the same. I agree this is weird, but no more weird a solution as CIC was when that first came out. I don't like it, or think its clever; I just think its the only thing on the table. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
