Re: pgsql: Modify pg_basebackup to use a new COPY subprotocol for base back

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pgsql: Modify pg_basebackup to use a new COPY subprotocol for base back
Дата
Msg-id CA+TgmoaC6OoLOnDj5tt_MopTjACcpa6Udd04X6qxdbnPZewocQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgsql: Modify pg_basebackup to use a new COPY subprotocol for base back  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Jan 18, 2022 at 4:36 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Andres pointed out to me that longfin is sad:
>
> > 2022-01-18 14:52:35.484 EST [82470:4] LOG:  server process (PID 82487)
> > was terminated by signal 4: Illegal instruction: 4
>
> > Tom, any chance you can get a stack trace?
>
> Hmm, I'd assumed that was just a cosmic ray or something.
> I'll check if it reproduces, though.

Thomas pointed out to me that thorntail also failed, and that it
included a backtrace. Unfortunately it's not somewhat confusing. The
innermost frame is:

#0  0x00000100006319a4 in bbsink_archive_contents (len=<optimized
out>, sink=<optimized out>) at
/home/nm/farm/sparc64_deb10_gcc_64_ubsan/HEAD/pgsql.build/../pgsql/src/backend/replication/basebackup.c:1672
1672 return true;

Line 1672 of basebackup.c  is indeed "return true" but we're inside of
sendFile(), not bbsink_archive_contents(). However,
bbsink_archive_contents() is an inline function so maybe the failure
is misattributed. I wonder whether the "sink" pointer in that function
is somehow not valid ... but I don't know how that would happen, or
why it would happen only on this machine.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Allow root ownership of client certificate key
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Modify pg_basebackup to use a new COPY subprotocol for base back