Re: [GENERAL] Logical decoding client has the power to crash the server - Mailing list pgsql-general

From Michael Paquier
Subject Re: [GENERAL] Logical decoding client has the power to crash the server
Date
Msg-id CAB7nPqSME6i3J2MK3j=Ybgmwy9Hrn2iXcekCMoq9DuaV51SWOA@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Logical decoding client has the power to crash theserver  (Igor Neyman <ineyman@perceptron.com>)
List pgsql-general
On Fri, Sep 22, 2017 at 5:44 AM, Igor Neyman <ineyman@perceptron.com> wrote:
> I think the difference between pg_current_wal_lsn() and confirmed_flush_lsn form pg_catalog.pg_replication_slots for
specificreplication 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,
andhence 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


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

pgsql-general by date:

Previous
From: mike davis
Date:
Subject: [GENERAL] Dynamic use of RAISE with USING to generate and catch non-hardcodedcustom exceptions
Next
From: Pavel Stehule
Date:
Subject: Re: [GENERAL] Dynamic use of RAISE with USING to generate and catchnon-hardcoded custom exceptions