Re: Executing inet_server_addr/port() in parallel workers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Executing inet_server_addr/port() in parallel workers
Date
Msg-id 1127252.1610463323@sss.pgh.pa.us
Whole thread Raw
In response to Executing inet_server_addr/port() in parallel workers  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Executing inet_server_addr/port() in parallel workers  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Executing inet_server_addr/port() in parallel workers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Masahiko Sawada <sawada.mshk@gmail.com> writes:
> While investigating a customer issue it's turned out that if a
> parallel worker executes inet_server_addr() and inet_server_port() the
> results are always null because MyProcPort is not set in parallel
> workers.

Check.

> To fix this issue, I think there are two options:
> 1. Inherits the local address information from postmaster or the
> leader to parallel workers.
> 2. Have both inet_server_addr() and inet_server_port() parallel restricted.

> Since auxiliary processes including parallel workers don't communicate
> directly to the client, this information is basically not necessary.
> Also, the option #1 needs code change to pass the information, which
> brings complexity and is not good in terms of back-patching. So I'd
> prefer the option #2. I've attached the patch doing the option #2.

Um, but #2 is surely not back-patchable.  Changing initial catalog
contents in a back branch is a big PITA, so we generally wouldn't
even consider it except for critical security problems.  Which this
is not.

Having said that, I'm fine with the idea of just marking these
parallel-restricted in HEAD and ignoring the problem in the back
branches.

            regards, tom lane



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Added schema level support for publication.
Next
From: Alvaro Herrera
Date:
Subject: Re: Fix a typo in xlogreader.c