Re: Executing inet_server_addr/port() in parallel workers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Executing inet_server_addr/port() in parallel workers
Date: 2021-01-12 14:55:23
Message-ID: 1127252.1610463323@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-01-12 15:07:21 Re: Fix a typo in xlogreader.c
Previous Message vignesh C 2021-01-12 14:53:11 Re: Added schema level support for publication.