Excerpts from Dimitri Fontaine's message of lun dic 20 14:25:14 -0300 2010:
> Robert Haas writes:
> > Patches are better for me, anyway...
>
> Here it is then, version 21. Changes:
Just noticed a small problem: you're removing the "SET search_path"
lines in contrib Makefiles but you're leaving t
On Mon, Dec 20, 2010 at 11:36 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> The effect of that has to be that the postmaster adds a certain amount
>> of space to PostgreSQL's initial shared memory allocation. That means
>> the postmaster has to know that pg_stat_statements is a valid cust
Robert Haas writes:
> The effect of that has to be that the postmaster adds a certain amount
> of space to PostgreSQL's initial shared memory allocation. That means
> the postmaster has to know that pg_stat_statements is a valid custom
> variable class.
Ah. Yes. Indeed. So you still needed to ed
On Mon, Dec 20, 2010 at 3:56 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I bet it doesn't. The *postmaster* never connects to a database, so
>> which copy of pg_extension does it ever read?
>
> None, which does it need to read? My answer is none, you're saying it's
> wrong, I don't get
Itagaki Takahiro writes:
> I think so. It would be better to remove the CVC support and related code.
Will isolate that into another branch just in case and prepare a patch
with that removed.
> Preloading modules that defines CVC is a good direction to fix the issue,
> but we need more considera
Robert Haas writes:
> I bet it doesn't. The *postmaster* never connects to a database, so
> which copy of pg_extension does it ever read?
None, which does it need to read? My answer is none, you're saying it's
wrong, I don't get why. postmaster surely has no business with what's in
a specific da
On Mon, Dec 20, 2010 at 03:39, Dimitri Fontaine wrote:
> Just so that we're on the same line here, if we are to remove
> custom_variable_classes then we don't keep any GUC related code into the
> extension patch, right? So that ExtensionSetCVC() and friends disappear
> entirely.
I think so. It w
On Sun, Dec 19, 2010 at 1:35 PM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> Just to point out one concrete problem: the postmaster reads
>> postgresql.conf too, so it would have to do this as well in order to
>> parse postgresql.conf correctly.
>
> Well, if I parse you correctly, in my patch,
Itagaki Takahiro writes:
> +1 to split the custom_variable_classes issue. It's a longstanding
> TODO item, but EXTENSION is still very useful without the fix.
>
> It's my guess that ExtensionSetCVC() can initialize modules one-by-one
> and be called on demand, for example, at SHOW, searching pg_se
Tom Lane writes:
> Just to point out one concrete problem: the postmaster reads
> postgresql.conf too, so it would have to do this as well in order to
> parse postgresql.conf correctly.
Well, if I parse you correctly, in my patch, it does. There's another
GUC array where to store invalid placehol
On Sun, Dec 19, 2010 at 11:21 AM, Tom Lane wrote:
> I agree with Robert that that is an utterly horrid, broken concept.
That's a little stronger than what I said, though the same general idea.
> Just to point out one concrete problem: the postmaster reads
> postgresql.conf too, so it would have
Dimitri Fontaine writes:
> Now, for people following but not reading the patch, what's in is that
> in order for extensions using custom_variable_classes to work without
> the user having to care about it, I've added an step at backend startup
> time to seqscan pg_extension and update custom_varia
Robert Haas writes:
> Looking at this a little more, I am inclined to think that
> ExtensionSetCVC() is entirely unacceptable. Our backend startup is
> high enough already. Sequential scanning the pg_extension catalog on
> every startup to spare the DBA the trouble of setting up
> postgresql.con
13 matches
Mail list logo
