Re: Crash dumps

Поиск
Список
Период
Сортировка
От Radosław Smogura
Тема Re: Crash dumps
Дата
Msg-id 201107070800.16015.rsmogura@softperience.eu
обсуждение исходный текст
Ответ на Re: Crash dumps  (Craig Ringer <craig@postnewspapers.com.au>)
Ответы Re: Crash dumps
Список pgsql-hackers
Craig Ringer <craig@postnewspapers.com.au> Thursday 07 of July 2011 01:05:48
> On 6/07/2011 11:00 PM, Radosław Smogura wrote:
> > I think IPC for fast shout down all backends and wait for report
> > processing is quite enaugh.
>
> How do you propose to make that reliable, though?
>
> --
> Craig Ringer
>
> POST Newspapers
> 276 Onslow Rd, Shenton Park
> Ph: 08 9381 3088     Fax: 08 9388 2258
> ABN: 50 008 917 717
> http://www.postnewspapers.com.au/

I want to add IPC layer to postgresql, few approches may be considerable,
1. System IPC
2. Urgent data on socket
3. Sockets (at least descriptors) + threads
4. Not portable, fork in segfault (I think forked process should start in
segfault too).

I actualy think for 3. sockets (on Linux pipes) + threads will be the best and
more portable, for each backend PostgreSQL will open two channels urgent and
normal, for each channel a thread will be spanned and this thread will just
wait for data, backend will not start if it didn't connected to postmaster.
Some security must be accounted when opening plain socket.

In context of crash, segfault sends information on urgent channel, and
postmaster kills all backends except sender, giving it time to work in
segfault.

Normal channels may, be used for scheduling some async operations, like read
next n-blocks when sequence scan started.

By the way getting reports on segfault isn't something "unusal", Your favorite
software Java(tm) Virtual Machine does it.

Regards,
Radosław Smogura





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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: spurious use of %m format in pg_upgrade
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: dropping table in testcase alter_table.sql