Re: Recovery performance of DROP DATABASE with many tablespaces

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recovery performance of DROP DATABASE with many tablespaces
Date: 2019-10-02 08:38:36
Message-ID: CAHGQGwF2CVw1h833yER1qdvWrxrFpq_Kw+0ME0SBe_4OYVbi7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 5, 2018 at 5:15 PM Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On 4 June 2018 at 17:46, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > Hi,
> >
> > My colleague encountered the problem that WAL replay took a long time
> > in the standby with large shared_buffers when he dropped the database
> > using many tablespaces. As far as I read the code, this happens because
> > DROP DATABASE generates as many XLOG_DBASE_DROP WAL records as
> > the number of tablespaces that the database to drop uses,
> > and then WAL replay of one XLOG_DBASE_DROP record causes full scan of
> > shared_buffers. That is, DROP DATABASE causes the scans of shared_buffers
> > as many times as the number of the tablespaces during recovery.
> >
> > Since the first scan caused by the first XLOG_DBASE_DROP record invalidates
> > all the pages related to the database to drop, in shared_buffers,
> > the subsequent scans by the subsequent records seem basically useless.
> > So I'd like to change the code so that we can avoid such subsequent
> > unnecessary scans, to reduce the recovery time of DROP DATABASE.
>
> +1
>
> > Generally the recovery performance of DROP DATABASE is not critical
> > for many users. But unfortunately my colleague's project might need to
> > sometimes drop the database using multiple tablespaces, for some reasons.
> > So, if the fix is not so complicated, I think that it's worth applying that.
>
> Agreed
>
> > The straight approach to avoid such unnecessary scans is to change
> > DROP DATABASE so that it generates only one XLOG_DBASE_DROP record,
> > and register the information of all the tablespace into it. Then, WAL replay
> > of XLOG_DBASE_DROP record scans shared_buffers once and deletes
> > all tablespaces. POC patch is attached.
>
> Seems clear on read of patch, but not tested it.
>
> Please replace tablespace_num with ntablespaces so its clearer and
> consistent with other other WAL records

Thanks for the review! I changed the patch that way. Also I rebased it
on master.
Attached is the latest version of the patch.

I will add this patch to next CommitFest.

Regards,

--
Fujii Masao

Attachment Content-Type Size
xlog_dbase_drop_v2.patch application/octet-stream 5.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2019-10-02 08:39:55 Re: Recovery performance of DROP DATABASE with many tablespaces
Previous Message Smith, Peter 2019-10-02 07:31:48 RE: Proposal: Make use of C99 designated initialisers for nulls/values arrays