Re: Moving slot restart_lsn/catalog_xmin more eagerly from SQL functions

From: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Moving slot restart_lsn/catalog_xmin more eagerly from SQL functions
Date: 2018-12-30 19:31:34
Message-ID: a1a8f768-e1f0-6915-88cd-2b0ec32d8bf8@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30/12/2018 20:27, Petr Jelinek wrote:
> Hi,
>
> while messing around with slot code I noticed that the SQL functions for
> consuming/moving logical replication slots only move restart_lsn up to
> previously consumed position and not to currently consumed position. The
> reason for that is that restart_lsn is not moved forward unless new
> value is smaller that current confirmed_lsn of the slot. But we only
> update confirmed_lsn of the slot at the end of the SQL functions so we
> can only move restart_lsn up to the position we reached on previous
> call. Same is true for catalog_xmin.
>
> This does not really hurt much functionality wise but it means that
> every record is needlessly processed twice as we always restart from
> position that was reached 2 calls of the function ago and that we keep
> older catalog_xmin than necessary which can potentially affect system
> catalog bloat.
>
> This affects both the pg_logical_slot_get_[binary_]changes and
> pg_replication_slot_advance.
>
> Attached patch improves things by adding call to move the slot's
> restart_lsn and catalog_xmin to the last serialized snapshot position
> right after we update the confirmed_lsn.
>

Meh, and it has copy-paste issue. Fixed in new attachment.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
0001-Move-restart_lsn-and-catalog_xmin-more-agresivelly-i.patch text/x-patch 4.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-12-30 19:45:23 Re: Unified logging system for command-line programs
Previous Message Vik Fearing 2018-12-30 19:29:18 Re: Optimize constant MinMax expressions