On Fri, Sep 22, 2017 at 5:44 AM, Igor Neyman 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.
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Michael Paquier
Sent: Thursday, September 21, 2017 12:33 AM
To: Meel Velliste
Cc: PostgreSQL mailing lists
Subject: Re: [GENERAL] Logical decoding client has the power to
On Thu, Sep 21, 2017 at 1:09 PM, Meel Velliste wrote:
> In this situation, neither us, nor our customer has the power to install the
> required monitoring of pg_xlog. The database hosting provider would have to
> do it. In most cases (e.g. Amazon RDS) the hosting provider does provide a
> way of m
Hi Michael,
Thank you, I appreciate your response. Now that you mention, I am realizing
that I don't really care about dropping the oldest log entries. Mandatory
monitoring makes a lot of sense and dropping the entire slot would be
perfect when it consumes too much space.
The only problem with mo
On Wed, Sep 20, 2017 at 3:14 PM, Meel Velliste wrote:
> From what I understand about logical decoding, there is no limit to how many
> log entries will be retained by the server if nobody reads them from the
> logical slot. This means that a client that fails to read from the slot has
> the power
>From what I understand about logical decoding, there is no limit to how
many log entries will be retained by the server if nobody reads them from
the logical slot. This means that a client that fails to read from the slot
has the power to bring down the master database because the server's disk
wi
