Thread: Re: [SQL] Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOW Dont!! HELP

I can confirm with current sources:
test=> CREATE UNIQUE INDEX shadow_index ON pg_shadow (usename);CREATEtest=> select * from pg_shadow;ERROR:  Index
'pg_shadow_sysid_index'does not existtest=> \q$ psql testpsql: FATAL 1:  Index 'pg_shadow_name_index' does not exist$
 

gdb shows that the check in heap_create() is working because the
index name does not begin with pg_, just the base table:
Breakpoint 1, heap_create (relname=0x838d1d0 "shadow_index",     tupDesc=0x83915e4, istemp=0 '\000', storage_create=0
'\000',    allow_system_table_mods=0) at heap.c:183183             bool            nailme = false;
 

First, should we allow user-specified indexes on system tables, and if
so, why does this error happen?

Notice the user wanted an index named shadow_index, but the error
mentioned is pg_shadow_name_index.


> Hi 
> 
> Regarding my previous post, I just successfully created a unique index on 
> pg_shadow. DON'T DO THIS!!!
> -------
> CREATE UNIQUE INDEX shadow_index ON pg_shadow (usename)
> -------
> I couldn't create at pg_shadow_index as the pg prefix is reserved for 
> system tables. 
> 
> This BROKE the database. At least I can't connect anymore with a:
> -------
> template1=# \c statements
> FATAL 1:  Index 'pg_shadow_name_index' does not exist
> Previous connection kept
> template1=#
> -------
> If I look at the error log I get :
> -------
> ERROR:  Illegal class name 'pg_shadow_index'
>         The 'pg_' name prefix is reserved for system catalogs
> ERROR:  Index 'pg_shadow_name_index' does not exist
> ERROR:  SearchSysCache: recursive use of cache 23
> ERROR:  SearchSysCache: recursive use of cache 23
> ERROR:  SearchSysCache: recursive use of cache 23
> ERROR:  SearchSysCache: recursive use of cache 23 <-- quite psql here
> FATAL 1:  Index 'pg_shadow_name_index' does not exist <-- restarted again
> FATAL 1:  Index 'pg_shadow_name_index' does not exist
> FATAL 1:  Index 'pg_shadow_name_index' does not exist
> -------
> 
> What can I do??? I've got a non-trivial amount of data that I cannot afford 
> to lose!! HELP!..
> 
> Regards
> MArCin - Thanks
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Bruce Momjian <pgman@candle.pha.pa.us> writes:
>     test=> CREATE UNIQUE INDEX shadow_index ON pg_shadow (usename);
>     CREATE
>     test=> select * from pg_shadow;
>     ERROR:  Index 'pg_shadow_sysid_index' does not exist
>     test=> \q
>     $ psql test
>     psql: FATAL 1:  Index 'pg_shadow_name_index' does not exist
>     $

> Notice the user wanted an index named shadow_index, but the error
> mentioned is pg_shadow_name_index.

What's failing is catcache lookups on pg_shadow.  The catcache has table
entries that claim that there are indexes on pg_shadow(usename) and
pg_shadow(usesysid).  The system would not work at all, except that
catcache's use of these indexes is defeated by sanity-check code that
notices that relhasindex is FALSE for pg_shadow (line 880 of
catcache.c).

As soon as you create an index on pg_shadow, relhasindex becomes TRUE
and catcache.c starts trying to use these nonexistent indexes for
routine operations like ACL permissions checks.  So, nothing works
anymore.

We ought to create those indexes someday ;-)
        regards, tom lane