From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | m(dot)kiianov(at)rtk-dc(dot)ru |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15640: FATAL: XX000: cannot read pg_class without having selected a database |
Date: | 2019-02-18 15:25:50 |
Message-ID: | 17473.1550503550@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> 2019-02-18 05:30:36 GMT [40378]: [2-1] db=,user= FATAL: XX000: cannot read
> pg_class without having selected a database
> 2019-02-18 05:30:36 GMT [40378]: [3-1] db=,user= LOCATION: ScanPgRelation,
> relcache.c:314
> 2019-02-18 05:30:36 GMT [40267]: [7-1] db=,user= LOG: 00000: autovacuum
> launcher process (PID 40378) exited with exit code 1
Hm. So something is trying to access pg_class (perhaps only on the way to
reading something else) inside the autovacuum launcher, which it cannot
do because the launcher isn't connected to any specific database.
I have not heard of such behavior in core Postgres, which makes me think
that the problem is in one of your extensions. You mention
> shared_preload_libraries = 'pg_stat_statements, timescaledb,
> pg_wait_sampling, repmgr, auto_explain'
I'd suggest removing entries from shared_preload_libraries one at a
time to see if the problem stops occurring. (Obviously, you have to
restart the postmaster each time you change the list.) Once you've
found the culprit, closer analysis would be possible.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2019-02-18 16:23:39 | Re: BUG #15636: PostgreSQL 11.1 pg_basebackup backup to a CIFS destination throws fsync error at end of backup |
Previous Message | Alvaro Herrera | 2019-02-18 14:45:55 | Re: BUG #15640: FATAL: XX000: cannot read pg_class without having selected a database |