Greg Stark writes:
> On Wed, May 11, 2011 at 3:20 AM, Tom Lane wrote:
>> So this is fine if the
>> current value was from the file or was the boot_val, but if we'd
>> overridden the boot value with a "replacement" default value using
>> PGC_S_DEFAULT, that code would cause the value to revert to
On Wed, May 11, 2011 at 3:20 AM, Tom Lane wrote:
> So this is fine if the
> current value was from the file or was the boot_val, but if we'd
> overridden the boot value with a "replacement" default value using
> PGC_S_DEFAULT, that code would cause the value to revert to the boot_val
> not the rep
On tis, 2011-05-10 at 22:20 -0400, Tom Lane wrote:
> My conclusion about all this is that we really need to invent another
> GucSource value falling between PGC_S_DEFAULT and PGC_S_ENV_VAR,
> called perhaps PGC_S_DYNAMIC_DEFAULT, for the purpose of denoting
> values that are defaults in terms of th
I believe I've sussed the reason for the recent reports of Windows
builds crashing when asked to process 'infinity'::timestamp. It's
a bit tedious, so bear with me:
1. The immediate cause is that datebsearch() is being called with a NULL
pointer and zero count, ie, the powerup default values of t
