Re: backtrace_on_internal_error

Поиск
Список
Период
Сортировка
Искать
От
Andres Freund
Тема
Re: backtrace_on_internal_error
Дата
Msg-id
20231208221554.f5fmjjqowktnmqlk@awork3.anarazel.de
Ответ на
Список
Дерево обсуждения
backtrace_on_internal_error Peter Eisentraut <peter@eisentraut.org>
Re: backtrace_on_internal_error Nathan Bossart <nathandbossart@gmail.com>
Re: backtrace_on_internal_error Robert Haas <robertmhaas@gmail.com>
Re: backtrace_on_internal_error Nathan Bossart <nathandbossart@gmail.com>
Re: backtrace_on_internal_error Robert Haas <robertmhaas@gmail.com>
Re: backtrace_on_internal_error Matthias van de Meent <boekewurm+postgres@gmail.com>
Re: backtrace_on_internal_error Nathan Bossart <nathandbossart@gmail.com>
Re: backtrace_on_internal_error Tom Lane <tgl@sss.pgh.pa.us>
Re: backtrace_on_internal_error Robert Haas <robertmhaas@gmail.com>
Re: backtrace_on_internal_error Peter Eisentraut <peter@eisentraut.org>
Re: backtrace_on_internal_error Tom Lane <tgl@sss.pgh.pa.us>
Re: backtrace_on_internal_error Peter Eisentraut <peter@eisentraut.org>
Re: backtrace_on_internal_error Tom Lane <tgl@sss.pgh.pa.us>
Re: backtrace_on_internal_error Andres Freund <andres@anarazel.de>
Re: backtrace_on_internal_error Tom Lane <tgl@sss.pgh.pa.us>
Re: backtrace_on_internal_error Andres Freund <andres@anarazel.de>
Re: backtrace_on_internal_error Tom Lane <tgl@sss.pgh.pa.us>
Re: backtrace_on_internal_error Andres Freund <andres@anarazel.de>
Re: backtrace_on_internal_error Andres Freund <andres@anarazel.de>
Re: backtrace_on_internal_error Tom Lane <tgl@sss.pgh.pa.us>
Re: backtrace_on_internal_error Andres Freund <andres@anarazel.de>
Re: backtrace_on_internal_error Tom Lane <tgl@sss.pgh.pa.us>
Re: backtrace_on_internal_error Tom Lane <tgl@sss.pgh.pa.us>
Re: backtrace_on_internal_error Andres Freund <andres@anarazel.de>
Re: backtrace_on_internal_error Tom Lane <tgl@sss.pgh.pa.us>
Re: backtrace_on_internal_error Jelte Fennema-Nio <postgres@jeltef.nl>
Re: backtrace_on_internal_error Andres Freund <andres@anarazel.de>
Re: backtrace_on_internal_error Jelte Fennema-Nio <postgres@jeltef.nl>
Re: backtrace_on_internal_error Andres Freund <andres@anarazel.de>
Re: backtrace_on_internal_error Andres Freund <andres@anarazel.de>
Re: backtrace_on_internal_error Tom Lane <tgl@sss.pgh.pa.us>
Re: backtrace_on_internal_error Andres Freund <andres@anarazel.de>
Re: backtrace_on_internal_error Robert Haas <robertmhaas@gmail.com>
Re: backtrace_on_internal_error Tom Lane <tgl@sss.pgh.pa.us>
Re: backtrace_on_internal_error Peter Eisentraut <peter@eisentraut.org>
Re: backtrace_on_internal_error Robert Haas <robertmhaas@gmail.com>
Re: backtrace_on_internal_error Jelte Fennema-Nio <postgres@jeltef.nl>
Re: backtrace_on_internal_error Peter Eisentraut <peter@eisentraut.org>
Hi,

On 2023-12-08 11:33:16 -0800, Andres Freund wrote:
> On 2023-12-08 10:51:01 -0800, Andres Freund wrote:
> > On 2023-12-08 13:46:07 -0500, Tom Lane wrote:
> > > Andres Freund  writes:
> > > > On 2023-12-08 13:23:50 -0500, Tom Lane wrote:
> > > >> Hmm, don't suppose you have a way to reproduce that?
> > >
> > > > After a bit of trying, yes.  I put an abort() into pgtls_open_client(), after
> > > > initialize_SSL(). Connecting does result in:
> > > > LOG:  could not accept SSL connection: Success
> > >
> > > OK.  I can dig into that, unless you're already on it?
>
> [...]
>
> Seems like we should just treat errno == 0 as a reason to emit the "EOF
> detected" message?

I thought it'd be nice to have a test for this, particularly because it's not
clear that the behaviour is consistent across openssl versions.

I couldn't think of a way to do that with psql. But it's just a few lines of
perl to gin up an "SSL" startup packet and then close the socket.  I couldn't
quite figure out when IO::Socket::INET was added, but I think it's likely been
long enough, I see references from 1999.

This worked easily on linux and freebsd, but not on windows and macos, where
it seems to cause ECONNRESET. I thought that explicitly shutting down the
socket might help, but that just additionally caused freebsd to fail.

Windows uses an older openssl, so it could also be caused by the behaviour
differing back then.

To deal with that, I changed the test to instead check if "not accept SSL
connection: Success" is not logged.  I'm not sure that actually would be
logged on windows, it does seem to have different strings for errors than
other platforms.

Greetings,

Andres Freund
В списке pgsql-hackers по дате отправления
От: Joe Conway
Дата:
От: Tatsuo Ishii
Дата:
Сообщение: Re: Row pattern recognition
FAQ