Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)
От | Alvaro Herrera |
---|---|
Тема | Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?) |
Дата | |
Msg-id | 20230324093547.amsbfoql2kmbqco2@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?) (Greg Stark <stark@mit.edu>) |
Ответы |
Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)
|
Список | pgsql-hackers |
On 2023-Mar-23, Greg Stark wrote: > 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" Hmm, I don't disagree with your argument in principle, but I think this proposal is going too far. I think stating the PID is more than sufficient. And I don't think we need this patch to go great lengths to explain what acquisition is, either; I mean, maybe that's a good thing to have, but then that's a different patch. > 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. Hmm, you should be able to match things using the connection information. I don't think the slot acquisition operation in itself is that important. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Use it up, wear it out, make it do, or do without"
В списке pgsql-hackers по дате отправления: