Simon Riggs wrote:
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.
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.
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 think one alternative might be to store a list of xid's together with
a cached plan, and replan if the commit status (as percieved by the
transaction the plan will be executed in) of one of those xid's changes.
greetings, Florian Pflug
---------------------------(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
