Re: [GENERAL] Logical decoding client has the power to crash the server

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [GENERAL] Logical decoding client has the power to crash the server
Дата
Msg-id CAB7nPqSME6i3J2MK3j=Ybgmwy9Hrn2iXcekCMoq9DuaV51SWOA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Logical decoding client has the power to crash theserver  (Igor Neyman <ineyman@perceptron.com>)
Список 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 по дате отправления:

Предыдущее
От: mike davis
Дата:
Сообщение: [GENERAL] Dynamic use of RAISE with USING to generate and catch non-hardcodedcustom exceptions
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [GENERAL] Dynamic use of RAISE with USING to generate and catchnon-hardcoded custom exceptions