"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
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.
---
Pa
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.
>
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)
> >
"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/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 cop
"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. W
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:
> 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 f
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 e
"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 exist
11 matches
Mail list logo