On Mon, Apr 4, 2011 at 4:57 PM, Tom Lane wrote:
> Robert Haas writes:
>> OK. Please comment the crap out of whatever you do, or maybe even add
>> a README. This stuff is just a bit arcane, and guideposts help a lot.
>
> We already have a README for that ;-). PFA, a patch to
> src/backend/utils
Robert Haas writes:
> OK. Please comment the crap out of whatever you do, or maybe even add
> a README. This stuff is just a bit arcane, and guideposts help a lot.
We already have a README for that ;-). PFA, a patch to
src/backend/utils/misc/README describing the proposed revised API.
If nobo
On Mon, Apr 4, 2011 at 3:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 4, 2011 at 2:58 PM, Tom Lane wrote:
>>> Another variant would be to allow the check_hook to pass back a separate
>>> "void *" value that could be passed on to the assign_hook, containing
>>> any necessary derive
Robert Haas writes:
> On Mon, Apr 4, 2011 at 2:58 PM, Tom Lane wrote:
>> Another variant would be to allow the check_hook to pass back a separate
>> "void *" value that could be passed on to the assign_hook, containing
>> any necessary derived data. This is logically a bit cleaner, and would
>>
On Mon, Apr 4, 2011 at 2:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane wrote:
>>> Given these rules, a check_hook and assign_hook could cooperate to store
>>> additional data in what guc.c thinks is just a pointer to a string
>>> value, ie, there can be
Robert Haas writes:
> On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane wrote:
>> Given these rules, a check_hook and assign_hook could cooperate to store
>> additional data in what guc.c thinks is just a pointer to a string
>> value, ie, there can be more data after the terminating \0. The
>> assign_hoo
On Mon, Apr 4, 2011 at 2:41 PM, Tom Lane wrote:
> I wrote:
>> IMO the real problem is essentially that GUC assign hooks have two
>> functions, checking and canonicalization of the value-to-be-stored
>> versus executing secondary actions when an assignment is made; and
>> there's no way to get at j
I wrote:
> IMO the real problem is essentially that GUC assign hooks have two
> functions, checking and canonicalization of the value-to-be-stored
> versus executing secondary actions when an assignment is made; and
> there's no way to get at just the first one. So we cannot canonicalize
> the val
Robert Haas wrote:
> On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane wrote:
>> It would probably take less than a day to flesh out this idea and
>> make it happen, but it does seem like a rather large change for
>> late alpha.
> what we're trying to avoid is committing new stuff that may require
> a
Robert Haas writes:
> On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane wrote:
>> IMO the real problem is essentially that GUC assign hooks have two
>> functions, checking and canonicalization of the value-to-be-stored
>> versus executing secondary actions when an assignment is made; and
>> there's no way
On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane wrote:
> IMO the real problem is essentially that GUC assign hooks have two
> functions, checking and canonicalization of the value-to-be-stored
> versus executing secondary actions when an assignment is made; and
> there's no way to get at just the first o
I wrote:
> Robert Haas writes:
>> I had intended to commit Greg's patch with a show hook and an assign
>> hook and the calculated value stored separately from the GUC variable,
>> which I believe would avoid this is a problem, but Tom thought this
>> way was better. Unfortunately, my knowledge of
Robert Haas writes:
> On Thu, Mar 31, 2011 at 8:38 AM, Bernd Helmle wrote:
>> This might be nitpicking (or i'm currently missing something), but i
>> recognized that setting wal_buffers = -1 always triggers the following on
>> reload, even if nothing to wal_buffers had changed:
>>
>> $ pg_ctl re
On Thu, Mar 31, 2011 at 8:38 AM, Bernd Helmle wrote:
> This might be nitpicking (or i'm currently missing something), but i
> recognized that setting wal_buffers = -1 always triggers the following on
> reload, even if nothing to wal_buffers had changed:
>
> $ pg_ctl reload
> LOG: received SIGHUP,
This might be nitpicking (or i'm currently missing something), but i recognized
that setting wal_buffers = -1 always triggers the following on reload, even if
nothing to wal_buffers had changed:
$ pg_ctl reload
LOG: received SIGHUP, reloading configuration files
LOG: parameter "wal_buffers" c
15 matches
Mail list logo
