From: | Jeff Frost <jeff(at)pgexperts(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15299: relation does not exist errors |
Date: | 2018-07-26 20:18:33 |
Message-ID: | 38FCBCD9-0145-4CCD-8A9A-496E532F0AAE@pgexperts.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Jul 26, 2018, at 12:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Jeff Frost <jeff(at)pgexperts(dot)com> writes:
>> On Jul 26, 2018, at 9:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> My first thought would be something to do with a restrictive search_path.
>
>> Good thought. As far as I can tell we never change it from the default and everything in that DB is in the public schema.
>
> Right, but what I'm half-theorizing is that the patches for CVE-2018-1058
> affected you somehow. Maybe something "transiently" installed pg_catalog
> (only) as search_path and forgot to remove it again. It would be easy
> to explain it that way if the errors had been coming out of autovacuum
> worker processes, for instance, though your log didn't match that exactly.
>
> If you see it again it would be a good idea to look very closely at what
> happened right before the errors started.
Oh, I see what you're saying. Don't the autovacuum processes connect to their own backends which then exit after they're complete though?
I have the logs around, so if you know what I should look for, I'd be happy to dig.
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-07-26 20:23:23 | Re: BUG #15299: relation does not exist errors |
Previous Message | Soni M | 2018-07-26 19:46:28 | Scanning all partition when more than 100 items in "where id in ()" clause |