Horton

Re: Complier warnings on mingw gcc 4.5.0

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Itagaki Takahiro <itagaki.takahiro@gmail.com>, Hiroshi Inoue <inoue@tpf.co.jp>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2010-12-14T21:17:32Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make the win32 putenv() override update *all* present versions of the

  2. Remove the use of the pg_auth flat file for client authentication.


On 12/14/2010 12:42 PM, Tom Lane wrote:
> 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?


Maybe I didn't explain this properly. The trace was not from pg_regress. 
It was from a connection from a standard Linux psql client.


> 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?
>
> 			


I can try that. Not sure how easy that is on Windows.

cheers

andrew