Re: Complier warnings on mingw gcc 4.5.0
| От | Alvaro Herrera |
|---|---|
| Тема | Re: Complier warnings on mingw gcc 4.5.0 |
| Дата | |
| Msg-id | 1292425426-sup-8936@alvh.no-ip.org обсуждение исходный текст |
| Ответ на | Re: Complier warnings on mingw gcc 4.5.0 (Andrew Dunstan <andrew@dunslane.net>) |
| Ответы |
Re: Complier warnings on mingw gcc 4.5.0
Re: Complier warnings on mingw gcc 4.5.0 |
| Список | 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@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: