I wrote:
> A quick look through the sources confirms that this error implies that
> SearchSysCache on the RELOID cache must have failed to find a tuple for
> pg_proc --- there are many occurrences of this text, but they all are
> reporting that. Which absolutely should not be happening now that we use
> MVCC catalog scans, concurrent updates or no. So I think this is a bug,
> and possibly a fairly-recently-introduced one, because I can't remember
> seeing buildfarm failures like this one before.
After tweaking elog.c to promote FATAL to PANIC, I got stack traces
confirming that the error occurs here:
#0 0x0000003779a325e5 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0000003779a33dc5 in abort () at abort.c:92
#2 0x000000000080d177 in errfinish (dummy=<value optimized out>) at elog.c:560
#3 0x000000000080df94 in elog_finish (elevel=<value optimized out>,
fmt=<value optimized out>) at elog.c:1381
#4 0x0000000000801859 in RelationCacheInitializePhase3 () at relcache.c:3444
#5 0x000000000081a145 in InitPostgres (in_dbname=<value optimized out>,
dboid=0,
username=<value optimized out>, useroid=<value optimized out>,
out_dbname=0x0)
at postinit.c:982
#6 0x0000000000710c81 in PostgresMain (argc=1, argv=<value optimized out>,
dbname=0x24d4c40 "regression", username=0x24abc88 "postgres") at
postgres.c:3728
#7 0x00000000006a6eae in BackendRun (argc=<value optimized out>,
argv=<value optimized out>) at postmaster.c:4271
#8 BackendStartup (argc=<value optimized out>, argv=<value optimized out>)
at postmaster.c:3945
#9 ServerLoop (argc=<value optimized out>, argv=<value optimized out>)
at postmaster.c:1701
#10 PostmasterMain (argc=<value optimized out>, argv=<value optimized out>)
at postmaster.c:1309
#11 0x00000000006273d8 in main (argc=3, argv=0x24a9b20) at main.c:228
So it's happening when RelationCacheInitializePhase3 is trying to replace
a fake pg_class row for pg_proc (made by formrdesc) with the real one.
That's even odder, because that's late enough that this should be a pretty
ordinary catalog lookup. Now I wonder if it's possible that this can be
seen during ordinary relation opens after connection startup. If so, it
would almost surely be a recently-introduced bug, else we'd have heard
about this from the field.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
