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
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 |