From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Pavan Deolasee <pavan(dot)deolasee(at)enterprisedb(dot)com> |
Subject: | Re: CREATE INDEX and HOT - revised design |
Date: | 2007-03-29 22:54:00 |
Message-ID: | 460C4388.6060805@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
> On Thu, 2007-03-29 at 17:27 -0400, Tom Lane wrote:
>> "Simon Riggs" <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Koichi Suzuki | 2007-03-30 01:00:14 | Re: [PATCHES] Full page writes improvement, code update |
Previous Message | Carlos Chacon | 2007-03-29 22:51:32 | Is this an psql Error??? |