On Sat, Jun 27, 2015 at 07:20:43PM -0400, Tom Lane wrote:
> Tatsuo Ishii writes:
> >> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
> >> view doesn't act as its author presumably intended. Specifically, it
> >> reads as empty until/unless the current session processes a
On Mon, Jun 29, 2015 at 11:42 PM, Tom Lane wrote:
> Sawada Masahiko writes:
>> On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane wrote:
>>> So let me make a radical proposal that both gets rid of the portability
>>> problem and, arguably, makes the view more useful than it is today.
>>> I think we shou
Sawada Masahiko writes:
> On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane wrote:
>> So let me make a radical proposal that both gets rid of the portability
>> problem and, arguably, makes the view more useful than it is today.
>> I think we should define the view as showing, not what was in the config
On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane wrote:
> I wrote:
>> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
>> view doesn't act as its author presumably intended. Specifically, it
>> reads as empty until/unless the current session processes a SIGHUP event.
>> ...
>> M
I wrote:
> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
> view doesn't act as its author presumably intended. Specifically, it
> reads as empty until/unless the current session processes a SIGHUP event.
> ...
> More or less bad alternative answers include:
> ...
> 3. Fo
>> I'm just wondering why we did not catch this earlier. If this is
>> because threre's no regression test case for pg_file_settings view,
>
> Yeah, exactly. Unfortunately I see no way to add a useful test, at least
> not one that will work in installcheck mode. There's no way to predict
> what
On Sun, Jun 28, 2015 at 10:40 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Sun, Jun 28, 2015 at 8:20 AM, Tom Lane wrote:
>>> Yeah, exactly. Unfortunately I see no way to add a useful test, at least
>>> not one that will work in installcheck mode. There's no way to predict
>>> what will
Michael Paquier writes:
> On Sun, Jun 28, 2015 at 8:20 AM, Tom Lane wrote:
>> Yeah, exactly. Unfortunately I see no way to add a useful test, at least
>> not one that will work in installcheck mode. There's no way to predict
>> what will be in the view in that case. Even for "make check", the
On Sun, Jun 28, 2015 at 8:20 AM, Tom Lane wrote:
> Tatsuo Ishii writes:
>>> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
>>> view doesn't act as its author presumably intended. Specifically, it
>>> reads as empty until/unless the current session processes a SIGHUP eve
Tatsuo Ishii writes:
>> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
>> view doesn't act as its author presumably intended. Specifically, it
>> reads as empty until/unless the current session processes a SIGHUP event.
> I'm just wondering why we did not catch this ear
> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
> view doesn't act as its author presumably intended. Specifically, it
> reads as empty until/unless the current session processes a SIGHUP event.
> This is because before that happens, it's depending on having inherited
>
I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
view doesn't act as its author presumably intended. Specifically, it
reads as empty until/unless the current session processes a SIGHUP event.
This is because before that happens, it's depending on having inherited
the state
12 matches
Mail list logo
