9.6.7 -> 9.6.8 analyze worker behaviour changed?

From: Marius Vaičiulis <marius(at)vaiciulis(dot)com>
To: <marius(at)vaiciulis(dot)com>, <pgsql-bugs(at)postgresql(dot)org>
Subject: 9.6.7 -> 9.6.8 analyze worker behaviour changed?
Date: 2018-03-08 11:45:42
Message-ID: 005401d3b6d2$fd471d80$f7d55880$@com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

Updated our server from 9.6.7 to 9.6.8 (PostgreSQL 9.6.8 on
x86_64-pc-linux-gnu (Debian 9.6.8-1.pgdg80+1), compiled by gcc (Debian
4.9.2-10+deb8u1) 4.9.2, 64-bit), and not really funny messages started to
appear in the logs:

2018-03-08 12:59:06 EET ERROR: relation "spatial_ref_sys" does not
exist at character 23

2018-03-08 12:59:06 EET QUERY: SELECT proj4text FROM spatial_ref_sys
WHERE srid = 4326 LIMIT 1

2018-03-08 12:59:06 EET CONTEXT: automatic analyze of table
"gpt_v2.customer101.t_customer"

That table (not the only one) uses the functional indexes, one of which uses
postgis functions, so the failing call comes from within postgis function
written in C. No changes were noticed in selects, updates, no errors except
that. I did some kind of workaround to make that problem go away by doing
ALTER FUNCTION … SET SEARCH_PATH TO public; for every postgis function used
in the indexes. public is where postgis extension is located (from long time
ago).

Not sure what to do next, is this a bug, is my realization considered to be
a bug, or workaround is a bug? Maybe some configuration parameter was (were)
introduced, that I have missed?

Thanks for any input.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2018-03-08 14:28:58 Re: 9.6.7 -> 9.6.8 analyze worker behaviour changed?
Previous Message Andrew Gierth 2018-03-08 08:54:56 Re: BUG #15101: function set search_path = '' breaks dump/restore