Re: Force update_process_title=on in crash recovery?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Christoph Berg <myon(at)debian(dot)org>
Subject: Re: Force update_process_title=on in crash recovery?
Date: 2020-09-16 05:43:32
Message-ID: 1443723.1600235012@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Wed, Sep 16, 2020 at 2:30 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> Another thing to be careful here is WIN32, see 0921554. And slowing
>> down recovery is never a good idea.

> Right, that commit makes a lot of sense because it suppresses many
> system calls that happen for each query. The same problem existed on
> older FreeBSD versions and I saw that costing ~10% of TPS on read-only
> pgbench. In other commits I've been removing system calls that happen
> for every WAL record. But in this thread I'm talking about an update
> per 16MB WAL file, which seems like an acceptable ratio to me.

Hmm ... the thread leading up to 0921554 indicates that the performance
penalty of update_process_title=on is just ridiculously large on Windows.
Maybe those numbers are not relevant to crash recovery WAL-application,
but it might be smart to actually measure that not just assume it.

In any case, I'd recommend setting up any patch you create for this
to be easily "ifndef WIN32"'d in case we change our minds on the
point later.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Guo 2020-09-16 05:46:03 Re: Parallelize stream replication process
Previous Message Thomas Munro 2020-09-16 05:24:01 Re: Force update_process_title=on in crash recovery?