Re: straightening out backend process startup

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: straightening out backend process startup
Date: 2021-08-02 16:57:36
Message-ID: 1641854.1627923456@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> I think there's quite a few different issues around this - here I'm just
> trying to tackle a few of the most glaring (to me):

No opinion yet about most of this, but I did want to react to

> In fact, I think there's a good argument to be made that we should
> entirely remove the concept of BackendIds and just use pgprocnos. We
> have a fair number of places like SignalVirtualTransaction() that need
> to search the procarray just to find the proc to signal based on the
> BackendId. If we used pgprocno instead, that'd not be needed.

If I understand what you're suggesting, it'd result in unused slots
in sinvaladt.c's procState[] array, which could create an annoying
drag on performance. However, I think it might be reasonable to
switch other things over to using pgprocnos, with an eye to
eventually making BackendIds private to the sinval mechanism.
There's certainly no strong reason why sinval's array indexes
need to be used as identifiers by other modules.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-08-02 17:12:55 Re: straightening out backend process startup
Previous Message Chris Cleveland 2021-08-02 16:41:51 Passing data out of indexam or tableam