| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: strange relcache.c debug message |
| Date: | 2017-11-01 14:15:47 |
| Message-ID: | 5296.1509545747@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> While messing with BRIN bugs, I noticed this debug message in the server
> log:
> 2017-11-01 12:33:24.042 CET [361429] DEBUG: rehashing catalog cache id 14 for pg_opclass; 17 tups, 8 buckets en carácter 194
> notice that at the end it says "at character 194". I suppose that's
> because of some leftover errposition() value, but why is it being
> reported in this message?
IIRC, there are places in the parser that set up an error callback that
will attach an errposition to any message at all that gets reported within
a particular chunk of code. It's meant to catch something like "name not
found" but could produce this too.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-11-01 14:24:11 | Re: pg_basebackup fails on Windows when using tablespace mapping |
| Previous Message | Craig Ringer | 2017-11-01 14:13:38 | Re: proposal: extend shm_mq to support more use cases |