Re: Complier warnings on mingw gcc 4.5.0

Andrew Dunstan <andrew@dunslane.net> writes:
> On 12/13/2010 04:34 PM, Tom Lane wrote:
>> Oh really ... are we using src/port/unsetenv.c on that platform?
>> I wonder if that little hack is incompatible with latest mingw
>> libraries ...

> It is using pgwin32_putenv() and pgwin32_unsetenv(). It appears not to 
> be related to how the environment is set at all, but to how the backend 
> is handling PGOPTIONS.

Mmm, right.  Even if that was messed up, it could only manifest as
pg_regress shipping a bogus connection request packet.  But speaking of
which ...

> Here's a TCP level dump of traffic showing the problem. The client is on 
> Linux.

> 18:34:03.106882 IP aurelia.34700 > 192.168.10.109.postgres: Flags [P.], 
> seq 9:86, ack 2, win 46, options [nop,nop,TS val 1504831233 ecr 
> 1085898], length 77
>      0x0000:  4500 0081 f95d 4000 4006 aaf3 c0a8 0a68  E....]@.@......h
>      0x0010:  c0a8 0a6d 878c 1538 a55b 18ce c920 b723  ...m...8.[.....#
>      0x0020:  8018 002e 07ae 0000 0101 080a 59b1 e701  ............Y...
>      0x0030:  0010 91ca 0000 004d 0003 0000 7573 6572  .......M....user
>      0x0040:  0070 6772 756e 6e65 7200 6461 7461 6261  .pgrunner.databa
>      0x0050:  7365 0070 6f73 7467 7265 7300 6f70 7469  se.postgres.opti
>      0x0060:  6f6e 7300 2d63 206c 6f67 5f6d 696e 5f6d  ons.-c.log_min_m
>      0x0070:  6573 7361 6765 733d 7761 726e 696e 6700  essages=warning.
>      0x0080:  00                                       .

This seems quite odd now that I look at it.  The packet contents imply
that libpq saw PGOPTIONS="-c log_min_messages=warning" and no other
environment variables that would cause it to append stuff to the
connection request.  Which is not at all how pg_regress ought to behave,
even assuming that the buildfarm script sets up PGOPTIONS that way.
I'd expect to see settings for timezone, datestyle, and intervalstyle
in there.  What was the client here exactly?

Another line of attack is that we know from the response packet that the
failure is being reported at guc.c:4794.  It would be really useful to
know what the call stack is there.  Could you change that elog to an
elog(PANIC) and get a stack trace from the ensuing core dump?
        regards, tom lane