Pavan Deolasee [EMAIL PROTECTED] writes:
Please see the attached updated patch, based on Tom's comments.
Attempt to reload index information for system indexes such as
pg_class_oid_index can cause infinite recursion. But I realized that
we don't need to reload system index information because
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Where are we on this?
---
Tom Lane wrote:
[squint...] How can that fail during a reload if it worked the first
time? Needs a closer look at what's happening.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Where are we on this?
---
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
On 3/28/07, Tom Lane [EMAIL PROTECTED] wrote:
It seems a bit brute-force. Why didn't you use SearchSysCache(INDEXRELID)
the same as
Pavan Deolasee [EMAIL PROTECTED] writes:
Here is a patch which fixes this. We re-read part of the pg_index
row and update rd_index with the new data. I tested REINDEX and CIC
and both seems to work fine with the patch applied.
Tom, does this look good ?
It seems a bit brute-force. Why
On 3/28/07, Tom Lane [EMAIL PROTECTED] wrote:
It seems a bit brute-force. Why didn't you use SearchSysCache(INDEXRELID)
the same as RelationInitIndexAccessInfo does?
I tried that initially, but it gets into infinite recursion during initdb.
And what's the point of
the extra tuple copy
Pavan Deolasee [EMAIL PROTECTED] writes:
On 3/28/07, Tom Lane [EMAIL PROTECTED] wrote:
It seems a bit brute-force. Why didn't you use SearchSysCache(INDEXRELID)
the same as RelationInitIndexAccessInfo does?
I tried that initially, but it gets into infinite recursion during initdb.
On 3/26/07, Tom Lane [EMAIL PROTECTED] wrote:
It might be feasible to have RelationReloadClassinfo re-read the
pg_index row and apply only the updates for specific known-changeable
columns. The stuff it's worried about is the subsidiary data such
as support function fmgr lookup records, but
Pavan Deolasee [EMAIL PROTECTED] writes:
While experimenting with the proposed CREATE INDEX support with
HOT, I realized that SI invalidation are not sent properly for pg_index
updates.
Hmm ... actually, CREATE INDEX CONCURRENTLY gets this wrong already, no?
I suspect that sessions existing at
On 3/26/07, Tom Lane [EMAIL PROTECTED] wrote:
Hmm ... actually, CREATE INDEX CONCURRENTLY gets this wrong already, no?
I suspect that sessions existing at the time C.I.C is done will never
see the new index as valid, unless something else happens to make them
drop and rebuild their relcache
Pavan Deolasee [EMAIL PROTECTED] writes:
On 3/26/07, Tom Lane [EMAIL PROTECTED] wrote:
Hmm ... actually, CREATE INDEX CONCURRENTLY gets this wrong already, no?
Yes, C.I.C gets it wrong. I confirmed that new index is seen as invalid
for existing sessions. Is it something we should fix ?
11 matches
Mail list logo
