Re: alter user set local_preload_libraries.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: alter user set local_preload_libraries.
Date: 2014-12-09 02:18:27
Message-ID: 13711.1418091507@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 12/8/14 12:39 PM, Robert Haas wrote:
>> On Sun, Dec 7, 2014 at 9:54 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>>> My radical proposal therefore would have been to embrace this
>>> inconsistency and get rid of PGC_BACKEND and PGC_SU_BACKEND altogether,
>>> relying on users interpreting the parameter names to indicate that
>>> changing them later may or may not have an effect. Unfortunately, the
>>> concerns about ignore_system_indexes prevent that.

>> What exactly are those concerns? Do you have a link to previous discussion?

> Earlier in the thread:
> http://www.postgresql.org/message-id/20108.1415120322@sss.pgh.pa.us

The core of the mentioned issues is that catalog searches done via the
systable_beginscan/systable_getnext API will ordinarily visit catalog
entries in the order of the specified index. However, if
ignore_system_indexes is set, you get a seqscan that will return the same
tuples in heap order (effectively, random order). There are known cases
where this results in minor planner inefficiencies, and I'm worried that
there might be outright bugs we don't know about, since that whole
operating mode can be best be described as entirely untested outside of
the bootstrap sequence.

Barring someone committing to spend the time to improve that situation
(time that would be poorly invested IMO), I don't think that we want to
open up ignore_system_indexes as USERSET, or do anything else to encourage
its use.

If we're intent on removing PGC_BACKEND then I'd be okay with
reclassifying ignore_system_indexes as SUSET; but I'm not exactly
convinced that we should be trying to get rid of PGC_BACKEND.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2014-12-09 02:38:05 Re: On partitioning
Previous Message Craig Ringer 2014-12-09 02:17:02 Re: Status of Commit fest 2014-10