Simon Riggs wrote:
> On Thu, 2007-03-29 at 17:27 -0400, Tom Lane wrote:
>> "Simon Riggs" <simon@2ndquadrant.com> 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
