Re: Basebackups reported as idle

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: David Steele <david(at)pgmasters(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Basebackups reported as idle
Date: 2017-12-21 00:38:55
Message-ID: CAB7nPqRBYp=miw2LchSsUgDLjdUTUqNp4Bi_U8=fg+M+45Gk4g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 20, 2017 at 9:02 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Wed, Dec 20, 2017 at 12:50 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> Yes. Of course. I can't read. That's the same as the notice below about it
> not returning false -- I managed to miss the extra if() there, and thought
> it always exited with ERROR.

I think that the call to pgstat_report_activity in WalSndLoop() should
be kept as well. There is a small gap between the moment the process
is started and the first replication command is run.

>> + /* Report to pgstat that this process is running */
>> + pgstat_report_activity(STATE_RUNNING, NULL);
>> Bonus points if cmd_string is used instead of string? This way, you
>> can know what is the replication command running ;)
>
> Do we want that though? That would be a compat break at least, wouldn't it?

Perhaps not, I found the idea funky but you actually don't want to
show a string in exec_replication_command for a T_SQLCmd node. That's
not complicated to check either. So let's discard such a thing for
now.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-12-21 00:51:58 Re: Tracking of page changes for backup purposes. PTRACK [POC]
Previous Message Haisheng Yuan 2017-12-20 23:13:10 Re: Bitmap table scan cost per page formula