Re: cannot read pg_class without having selected a database / is this a bug?

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: cannot read pg_class without having selected a database / is this a bug?
Date: 2011-12-04 14:26:39
Message-ID: 4EDB831F.7040605@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4.12.2011 05:19, Tom Lane wrote:
> Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
>> That might explain why it fails at first and then works just fine,
>> although it's a bit strange. Wouldn't that mean you can't access any
>> catalogs from the auth hook?
>
> It should be possible to access shared catalogs from an auth hook.
> pg_stat_activity is neither shared nor a catalog. Like Robert,
> I find it astonishing that this works ever, because the info needed
> simply isn't available until you've connected to a particular database.
> The fact that the view is actually defined the same in every database
> doesn't enter into that ...

Hmmm, I do admit this is the first time I play with these things
(relcache, catalogs ...) so closely. so there are obviously things I'm
not aware of. For example I'm a bit confused what is / is not a shared
catalogue. Thanks in advance for your patience.

Anyway, the code I posted does not fail because of pg_stat_activity, it
fails because it attempts for find the dbname/username for the backends
(read from pg_stat_activity).

I've removed pg_stat_activity (see the code below) and it still fails.
The reason is that get_database_name attempts to read pg_database, but
once it gets to ScanPgRelation in relcache.c it notices MyDatabaseID=0
and so the check fails

This is the simplified code:

if (status == STATUS_OK)
{
char * db;

LWLockAcquire(lock, LW_EXCLUSIVE);

sleep(1);

if (MyBackendId > 2) {
db = get_database_name(17000);
}

sleep(4);

LWLockRelease(lock);

}

If you start two backends at the same time, the first one gets ID=2 and
skips the get_database_name call, the second one gets ID=3 and calls the
function (and it fails). Subsequent calls work, because the first
backend initializes the relcache or something.

Tomas

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2011-12-04 14:27:06 Re: [PATCH] Caching for stable expressions with constant arguments v3
Previous Message Noah Misch 2011-12-04 12:20:27 Re: foreign key locks, 2nd attempt