Re: Assertion failure in pg_copy_logical_replication_slot()

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Assertion failure in pg_copy_logical_replication_slot()
Date: 2020-06-23 18:29:32
Message-ID: b4469423-b759-c2bc-8d7c-f8496827b1c1@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/06/23 18:42, Kyotaro Horiguchi wrote:
> At Tue, 23 Jun 2020 00:17:47 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-06-23 20:00:42 Re: [HACKERS] Custom compression methods
Previous Message Andres Freund 2020-06-23 18:28:52 Re: Move syncscan.c?