Re: ENABLE ROW LEVEL SECURITY cause huge produce of checkpoints

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: david(dot)turon(at)linuxbox(dot)cz
Cc: PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org>
Subject: Re: ENABLE ROW LEVEL SECURITY cause huge produce of checkpoints
Date: 2016-11-09 06:10:39
Message-ID: CAB7nPqT61a+Mb-YSrh7vD-nx0arSWfdZ+Up4qCxFopeyRFU0Fw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Nov 2, 2016 at 12:09 AM, <david(dot)turon(at)linuxbox(dot)cz> wrote:
> we tried new feature RLS - tested on postgres 9.5.3 / CentOS6. When we turn
> on ENABLE RLS + FORCE RLS on normal workload cause huge produce checkpoints
> (about 30x or more), our disk partition for xlog was full and log shipping
> to replica maybe delayed removing old checkpoints. Have anybody same
> experiences after turn on RLS? Looks like more buffers set as dirty. Yes,
> we can provide more space for xlog, but it will take much more space for
> xlog backups. We do not know if it's worth it. We had log_checkpoints ON and
> I send log as attachment (RLS Turn ON at 13:26).

Interesting, I don't recall RLS generating a burst in activity. The
first heavier checkpoints happen 20 minutes after enabling RLS and
those are triggered by time. Then things cool down and 1 hour later
comes the real deal with a set of checkpoints triggered by volume. It
is difficult though to draw a conclusion without more idea about your
load, the WAL record generated, etc.
--
Michael

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message david.turon 2016-11-09 07:20:00 Re: ENABLE ROW LEVEL SECURITY cause huge produce of checkpoints
Previous Message Tom Lane 2016-11-09 04:35:48 Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists