| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, m(dot)kiianov(at)rtk-dc(dot)ru, 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 17:32:43 |
| Message-ID: | 31217.1550511163@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2019-Feb-18, Andres Freund wrote:
>> My initial guess would be that one of the extensions registered a
>> relcache callback, and does catalog accesses in an unconditional manner.
> Hmm but why is extension code running in autovacuum launcher?
Anything registered in shared_preload_libraries is going to be active
in every process. I don't particularly believe Andres' theory that
CacheRegisterRelcacheCallback is involved, but it seems very likely
that one of these extensions has hooked into some code path that the
launcher can traverse, and it's doing more than is safe there.
If this weren't a production database, I'd suggest changing that error
to a PANIC so we could get a stack trace. That would almost certainly
pinpoint the culprit.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-02-18 17:35:55 | Re: BUG #15640: FATAL: XX000: cannot read pg_class without having selected a database |
| Previous Message | Maksim Milyutin | 2019-02-18 17:03:10 | Re: BUG #15638: pg_basebackup with --wal-method=stream incorrectly generates WAL segment created during backup |