Re: Rethinking placement of latch self-pipe initialization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Rethinking placement of latch self-pipe initialization
Date: 2012-10-08 13:54:15
Message-ID: 29911.1349704455@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> We still have to consider how Postgres would operate without the
> latches. I don't see that it can, so a shutdown seems appropriate. Is
> the purpose of this just to allow a cleaner and more informative
> shutdown? Or do you think we can avoid?

The point is that right now, if a new backend fails its initialization
at this specific step, that gets translated into a database-wide crash
and restart cycle, for no good reason. It should just result in that
particular session failing.

> If we did move the init calls, would that alter things for code that
> creates new used defined latches?

Only to the extent that it'd have to make sure it called the
initialization function at some appropriate point. It's not like
required initialization functions are a foreign concept in our code.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2012-10-08 14:03:03 Re: enhanced error fields
Previous Message Peter Geoghegan 2012-10-08 13:39:10 Re: [COMMITTERS] pgsql: Disable _FORTIFY_SOURCE with ICC