Re: Logical decoding client has the power to crash the server

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Igor Neyman <ineyman(at)perceptron(dot)com>
Cc: Meel Velliste <meel(at)fivetran(dot)com>, PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org>
Subject: Re: Logical decoding client has the power to crash the server
Date: 2017-09-22 02:04:24
Message-ID: CAB7nPqSME6i3J2MK3j=Ybgmwy9Hrn2iXcekCMoq9DuaV51SWOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Sep 22, 2017 at 5:44 AM, Igor Neyman <ineyman(at)perceptron(dot)com> wrote:
> I think the difference between pg_current_wal_lsn() and confirmed_flush_lsn form pg_catalog.pg_replication_slots for specific replication slot:
>
> SELECT (pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance
> FROM pg_catalog.pg_replication_slots
> WHERE slot_name = '<some_subscibtion_name>';
>
> provides a measure in Logical Replication environment of how far did (or did not) Subscriber fell behind Publisher, and hence some kind of measure of how much "extra" WALs is stored on the Publisher.

More or less. I also make use of the value of max_wal_size in
pg_settings to do the decision-making, value set depending on a
fraction of the size of the partition dedicated to pg_xlog. By
applying pg_size_bytes() which is new to 9.6 on top of the value
fetched from pg_settings you can make a direct comparison and decide
if a slot can be dropped or not. Make sure that things are casted to
bigint though.
--
Michael

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2017-09-22 04:15:56 Re: Dynamic use of RAISE with USING to generate and catch non-hardcoded custom exceptions
Previous Message mike davis 2017-09-21 23:40:48 Dynamic use of RAISE with USING to generate and catch non-hardcoded custom exceptions