| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Complier warnings on mingw gcc 4.5.0 |
| Date: | 2010-12-15 15:08:18 |
| Message-ID: | 1292425426-sup-8936@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Excerpts from Andrew Dunstan's message of mié dic 15 02:08:24 -0300 2010:
>
> On 12/14/2010 12:42 PM, Tom Lane wrote:
>
> > 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?
> >
>
> That didn't work. But git bisect says it's this commit that's to blame:
> <https://github.com/postgres/postgres/commit/e710b65c1c56ca7b91f662c63d37ff2e72862a94>
Hmm I wonder if this is reproducible in a non-Windows EXEC_BACKEND
scenario.
This bug seems closely related to process_postgres_switches. I guess
it'd be useful to add some debugging printouts there to figure out
what's being passed the second time around.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-12-15 15:08:47 | Re: unlogged tables |
| Previous Message | Robert Haas | 2010-12-15 15:05:37 | Re: hstores in pl/python |