MIME-Version: 1.0
References: <CAA4eK1+CoHVhP6hs+5-_1_A9EymSyqDPzHxBs1jSrTm5fj6CvQ@mail.gmail.com>
 <20230323100726.vzrgvpjt3il7uemq@alvherre.pgsql> <CALj2ACXvqFcxro64q4gjDeBNLgyPH0E6bG-WJ6w7qBqbggj3=w@mail.gmail.com>
 <c42d5634-ca9b-49a7-85cd-9eff9feb33b4@app.fastmail.com> <CALj2ACWHvzq05mZ25M0Rk9p0c5YpcrvkdVXHAoQaqRtFiDGS3A@mail.gmail.com>
In-Reply-To: <CALj2ACWHvzq05mZ25M0Rk9p0c5YpcrvkdVXHAoQaqRtFiDGS3A@mail.gmail.com>
From: Greg Stark <stark@mit.edu>
Date: Thu, 23 Mar 2023 23:52:31 -0400
Message-ID: <CAM-w4HORsLbxwv8KVUHWu1PxKQLuCN1JjAnXknP8pFNSQfbh3A@mail.gmail.com>
Subject: Re: add log messages when replication slots become active and
 inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Euler Taveira <euler@eulerto.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, 
	Amit Kapila <amit.kapila16@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAM-w4HORsLbxwv8KVUHWu1PxKQLuCN1JjAnXknP8pFNSQfbh3A%40mail.gmail.com>
Precedence: bulk

On Thu, 23 Mar 2023 at 23:30, Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> > + ereport(log_replication_commands ? LOG : DEBUG3,
> > + (errmsg("acquired physical replication slot \"%s\"",
> > + slotname)));

So this is just a bit of bike-shedding but I don't feel like these log
messages really meet the standard we set for our logging. Like what
did the acquiring? What does "acquired" actually mean for a
replication slot? Is there not any meta information about the
acquisition that can give more context to the reader to make this
message more meaningful?

I would expect a log message like this to say, I dunno, something like
"physical replication slot \"%s\" acquired by streaming TCP connection
to 192.168.0.1:999 at LSN ... with xxxMB of logs to read"

I even would be wondering if the other end shouldn't also be logging a
corresponding log and we shouldn't be going out of our way to ensure
there's enough information to match them up and presenting them in a
way that makes that easy.

-- 
greg