Re: ENABLE ROW LEVEL SECURITY cause huge produce of checkpoints - Mailing list pgsql-general

From Michael Paquier
Subject Re: ENABLE ROW LEVEL SECURITY cause huge produce of checkpoints
Date
Msg-id CAB7nPqT61a+Mb-YSrh7vD-nx0arSWfdZ+Up4qCxFopeyRFU0Fw@mail.gmail.com
Whole thread Raw
In response to ENABLE ROW LEVEL SECURITY cause huge produce of checkpoints  (david.turon@linuxbox.cz)
Responses Re: ENABLE ROW LEVEL SECURITY cause huge produce of checkpoints  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: ENABLE ROW LEVEL SECURITY cause huge produce of checkpoints  (david.turon@linuxbox.cz)
List pgsql-general
On Wed, Nov 2, 2016 at 12:09 AM,  <david.turon@linuxbox.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


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists
Next
From: Pierre Ducroquet
Date:
Subject: FTS query, statistics and planner estimations…