Re: Assertion failure in pg_copy_logical_replication_slot() - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Assertion failure in pg_copy_logical_replication_slot()
Date
Msg-id b4469423-b759-c2bc-8d7c-f8496827b1c1@oss.nttdata.com
Whole thread Raw
In response to Re: Assertion failure in pg_copy_logical_replication_slot()  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers

On 2020/06/23 18:42, Kyotaro Horiguchi wrote:
> At Tue, 23 Jun 2020 00:17:47 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in
>> Hi,
>>
>> If restart_lsn of logical replication slot gets behind more than
>> max_slot_wal_keep_size from the current LSN, the logical replication
>> slot would be invalidated and its restart_lsn is reset to an invalid
>> LSN.
>> If this logical replication slot with an invalid restart_lsn is
>> specified
>> as the source slot in pg_copy_logical_replication_slot(), the function
>> causes the following assertion failure.
> 
> Good catch!
> 
>>      TRAP: FailedAssertion("!logical_slot", File: "slotfuncs.c", Line: 727)
>>
>> This assertion failure is caused by
>>
>>     /* Copying non-reserved slot doesn't make sense */
>>     if (XLogRecPtrIsInvalid(src_restart_lsn))
>>         ereport(ERROR,
>>                 (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>>                  errmsg("cannot copy a replication slot that doesn't reserve
>>                  WAL")));
>>
>> I *guess* this assertion check was added because restart_lsn should
>> not be invalid before. But in v13, it can be invalid thanks to
>> max_slot_wal_keep_size.
>> I think that this assertion check seems useless and should be removed
>> in v13.
>> Patch attached. Thought?
> 
> Your diagnosis looks correct to me.

Thanks for the check! I will commit the patch later.

> The assertion failure means that
> copy_replication_slot was not exercised at least for a non-reserving
> logical slots. Greping "pg_copy_logical_replication_slot" on src/test
> showed nothing so I doubt we are exercising the function.
> 
> Don't we need some?

Yes, increasing the test coverage sounds helpful!

Regards,


-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Move syncscan.c?
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Custom compression methods