Re: CREATE INDEX and HOT - revised design
| От | Pavan Deolasee |
|---|---|
| Тема | Re: CREATE INDEX and HOT - revised design |
| Дата | |
| Msg-id | 2e78013d0703281112l5498c03ejfc6b0cb1b731214c@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: CREATE INDEX and HOT - revised design ("Simon Riggs" <simon@2ndquadrant.com>) |
| Ответы |
Re: CREATE INDEX and HOT - revised design
|
| Список | pgsql-hackers |
On 3/28/07, Simon Riggs <simon@2ndquadrant.com> wrote:
At the end of what ? It does not help to set it at the end of CREATE
INDEX because the transaction may not commit immediately. In
the meantime, many new transactions may start with
transaction id > xcreate. All these transactions can see the old
tuple (which we did not index) and can also see the index once
CREATE INDEX commits.
Why do we need to handle the case where table is created in
the same transaction ? Neither the table nor the index is visible
until we commit. So thats a simple case.
Thanks,
Pavan
--
Set it at the end, not the beginning.
At the end of what ? It does not help to set it at the end of CREATE
INDEX because the transaction may not commit immediately. In
the meantime, many new transactions may start with
transaction id > xcreate. All these transactions can see the old
tuple (which we did not index) and can also see the index once
CREATE INDEX commits.
If you are indexing a table that hasn't just been created by you, set
the xcreate field on pg_index at the *end* of the build using
ReadNewTransactionId(). Any xid less than that sees the index as
invalid. If you created the table in this transaction ( i.e.
createSubId != 0) then set xcreate to creating xid.
Why do we need to handle the case where table is created in
the same transaction ? Neither the table nor the index is visible
until we commit. So thats a simple case.
Thanks,
Pavan
EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: