Re: Order of operations in SubPostmasterMain()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Order of operations in SubPostmasterMain()
Date: 2016-09-29 20:32:44
Message-ID: 7430.1475181164@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> On Thu, Sep 29, 2016 at 8:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> We could probably refactor things enough so that we do pq_init()
>> before PGSharedMemoryReAttach(). It would be a little bit ugly,
>> and it would fractionally increase the chance of a reattach failure
>> because pq_init() palloc's a few KB worth of buffers. I'm not quite
>> sure if it's worth it; thoughts? In any case the mentioned comments
>> are obsolete and need to be moved/rewritten.

> Alternately we could call pq_init in the error path if it hasn't been
> called yet. I'm sure there are problems with doing that in general but
> for the specific errors that can happen before pq_init it might be
> feasible since they obviously can't have very much shared state yet to
> have corrupted.

Thanks for the suggestion, but I don't think it helps much. Most of
the refactoring pain comes from the fact that we'd have to set up
MyProcPort earlier (since pqcomm.c needs that to be valid), and
it's not very clear just where to do that. Having pq_init be called
behind the scenes does nothing to fix that issue.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-09-29 20:35:15 Re: Order of operations in SubPostmasterMain()
Previous Message Emrul 2016-09-29 20:15:46 Learning to hack Postgres - Keeping track of ctids