Re: Track replica origin progress for Rollback Prepared

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Ajin Cherian <itsajin(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Nikhil Sontakke <nikhils(at)2ndquadrant(dot)com>
Subject: Re: Track replica origin progress for Rollback Prepared
Date: 2021-03-05 01:41:39
Message-ID: CAA4eK1JGAZJA5r=J4h5uDM9C59JeHteTQfvjuh9fDugM6LO8pQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 4, 2021 at 8:03 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> Having said that, I think we use
> replication origins to test it. For example:
>
> Create Table t1(c1 int);
>
> SELECT pg_replication_origin_create('regress');
> SELECT pg_replication_origin_session_setup('regress');
> SELECT pg_replication_origin_xact_setup('0/aabbccdd', '2013-01-01 00:00');
> Begin;
> Select txid_current();
> Insert into t1 values(1);
> Prepare Transaction 'foo';
> SELECT pg_replication_origin_xact_setup('0/aabbccee', '2013-01-01 00:00');
> Rollback Prepared 'foo';
> SELECT pg_replication_origin_session_progress(true);
>
> -- Restart the server
> SELECT pg_replication_origin_session_setup('regress');
> SELECT pg_replication_origin_session_progress(true);
>
> The value before the patch will be aabbccdd and after the patch, it
> will be aabbccee.
>
> I think here we have a slight timing thing which is if the checkpoint
> happens before restart then the problem won't occur, not sure but
> maybe increase the checkpoint_timeout as well to make it reproducible.
> I am of opinion that this area won't change much and anyway once
> subscriber-side 2PC feature gets committed, we will have few tests
> covering this area but I am fine if you still insist to have something
> like above and think that we don't need to bother much about timing
> stuff.
>

I have just checked via code coverage that we don't seem to have tests
for recovery of replication origin advance for commit [1], see
function xact_redo_commit. Similarly, a similar code is not covered
for prepare [2], see EndPrepare. I think overall the test cases for
replication origins are not very many. Now, I think if we want to have
more tests in this area then we need to look at it more broadly. I
think it could be that currently only subscriber-side covers some part
of origins testing, otherwise, we don't have a detailed test suite by
using replication origin APIs and second is probably it might be
tricky to write a reliable recovery test case. One idea could be to
just write a test for the non-recovery code path (the code added in
function RecordTransactionAbortPrepared) and leave recovery testing
for now.

[1] - https://coverage.postgresql.org/src/backend/access/transam/xact.c.gcov.html
[2] - https://coverage.postgresql.org/src/backend/access/transam/twophase.c.gcov.html

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-03-05 01:46:07 Re: Parallel INSERT (INTO ... SELECT ...)
Previous Message Jan Wieck 2021-03-05 01:38:00 Re: Extensibility of the PostgreSQL wire protocol