Re: [HACKERS] Restricting maximum keep segments by repslots
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Thomas Munro <thomas.munro@enterprisedb.com>, Sergei Kornilov <sk@zsrv.org>, Michael Paquier <michael.paquier@gmail.com>,
Andres Freund <andres@anarazel.de>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2018-09-04T00:42:20Z
Lists: pgsql-hackers
Thank you for updating the patch.
On Tue, Jul 31, 2018 at 6:11 PM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> Hello.
>
> At Tue, 24 Jul 2018 16:47:41 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in <CAD21AoD0rChq7wQE=_o95quopcQGjcVG9omwdH07nT5cm81hzg@mail.gmail.com>
>> On Mon, Jul 23, 2018 at 4:16 PM, Kyotaro HORIGUCHI
>> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
>> > Hello.
>> >
>> > At Fri, 20 Jul 2018 10:13:58 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in <CAD21AoDayePWwu4t=VPP5P1QFDSBvks1d8j76bXp5rbXoPbZcA@mail.gmail.com>
> ..
>> > Instead, I made the field be shown in flat "bytes" using bigint,
>> > which can be nicely shown using pg_size_pretty;
>>
>> Thank you for updating. I agree showing the remain in bytes.
>>
>> Here is review comments for v6 patch.
>>
>> @@ -967,9 +969,9 @@ postgres=# SELECT * FROM
>> pg_create_physical_replication_slot('node_a_slot');
>> node_a_slot |
>>
>> postgres=# SELECT * FROM pg_replication_slots;
>> - slot_name | slot_type | datoid | database | active | xmin |
>> restart_lsn | confirmed_flush_lsn
>> --------------+-----------+--------+----------+--------+------+-------------+---------------------
>> - node_a_slot | physical | | | f | | |
>> + slot_name | slot_type | datoid | database | active | xmin |
>> restart_lsn | confirmed_flush_lsn | wal_status | min_keep_lsn
>> +-------------+-----------+--------+----------+--------+------+-------------+---------------------+------------+--------------
>> + node_a_slot | physical | | | f | |
>> | | unknown | 0/1000000
>>
>> This funk should be updated.
>
> Perhaps you need a fresh database cluster.
I meant this was a doc update in 0004 patch but it's fixed in v7 patch.
While testing the v7 patch, I got the following result with
max_slot_wal_keep_size = 5GB and without wal_keep_segments setting.
=# select pg_current_wal_lsn(), slot_name, restart_lsn,
confirmed_flush_lsn, wal_status, remain, pg_size_pretty(remain) from
pg_replication_slots ;
pg_current_wal_lsn | slot_name | restart_lsn | confirmed_flush_lsn |
wal_status | remain | pg_size_pretty
--------------------+-----------+-------------+---------------------+------------+----------+----------------
2/A30000D8 | l1 | 1/AC000910 | 1/AC000948 |
streaming | 16777000 | 16 MB
(1 row)
The actual distance between the slot limit and the slot 'l1' is about
1GB(5GB - (2/A30000D8 - 1/AC000910)) but the system view says the
remain is only 16MB. For the calculation of resetBytes in
GetOldestKeepSegment(), the current patch seems to calculate the
distance between the minSlotLSN and restartLSN when (curLSN -
max_slot_wal_keep_size) < minSlotLSN. However, I think that the actual
remained bytes until the slot lost the required WAL is (restartLSN -
(currLSN - max_slot_wal_keep_size)) in that case.
Also, 0004 patch needs to be rebased on the current HEAD.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Commits
-
Save slot's restart_lsn when invalidated due to size
- 12e52ba5a76e 13.0 landed
- 0188bb82531f 14.0 landed
-
Fix checkpoint signalling
- 1816a1c6ffe4 13.0 landed
-
Check slot->restart_lsn validity in a few more places
- d0abe78d8427 13.0 landed
-
Allow users to limit storage reserved by replication slots
- c6550776394e 13.0 landed
-
Remove header noise from test_decoding test
- 69360b34589b 13.0 landed
-
Rework WAL-reading supporting structs
- 709d003fbd98 13.0 cited
-
Flip argument order in XLogSegNoOffsetToRecPtr
- a22445ff0be2 12.0 cited