Re: Crash dumps - Mailing list pgsql-hackers

From Radosław Smogura
Subject Re: Crash dumps
Date
Msg-id 201107070800.16015.rsmogura@softperience.eu
Whole thread Raw
In response to Re: Crash dumps  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: Crash dumps
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: spurious use of %m format in pg_upgrade
Next
From: Ashutosh Bapat
Date:
Subject: dropping table in testcase alter_table.sql