Date: Wed, 28 Sep 2022 19:40:38 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Stark <stark@mit.edu>, pgsql-hackers@postgresql.org
Subject: Re: identifying the backend that owns a temporary schema
Message-ID: <20220929024038.GA4945@nathanxps13>
References: <20220815205811.GA250990@nathanxps13>
 <CAM-w4HMZ03AbQjBbfN_mTxct68HX3NPRQVfLaRxLGJTejJ8xbg@mail.gmail.com>
 <20220829230757.GA542616@nathanxps13>
 <2297420.1664041298@sss.pgh.pa.us>
 <20220926160822.GA1298186@nathanxps13>
 <3499642.1664221809@sss.pgh.pa.us>
 <20220926201113.GA1340606@nathanxps13>
 <4157446.1664405780@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4157446.1664405780@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/20220929024038.GA4945%40nathanxps13>
Precedence: bulk

On Wed, Sep 28, 2022 at 06:56:20PM -0400, Tom Lane wrote:
> I reviewed this and made some changes, some cosmetic some less so.

Thanks for the detailed review.

> A point that still bothers me a bit about pg_stat_get_backend_idset is
> that it could miss or duplicate some backend IDs if the user calls
> pg_stat_clear_snapshot() partway through the SRF's run, and we reload
> a different set of backend entries than we had before.  I added a comment
> about that, with an argument why it's not worth working harder, but
> is the argument convincing?  If not, what should we do?

Isn't this an existing problem?  Granted, it'd manifest differently with
this patch, but ISTM we could already end up with too many or too few
backend IDs if there's a refresh partway through.  I don't know if there's
an easy way to avoid mismatches altogether besides perhaps ERROR-ing if
there's a concurrent refresh.

> -	if (beid < 1 || beid > localNumBackends)
> -		return NULL;

The reason I'd kept this in was because I was worried about overflow in the
comparator function.  Upon further inspection, I don't think there's
actually any way that will produce incorrect results.  And I'm not sure we
should worry about such cases too much, anyway.

Overall, LGTM.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com