Re: [HACKERS] Comparing primary/HS standby in tests - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Comparing primary/HS standby in tests
Date
Msg-id 20210507180424.kq2huo6425c3sfgn@alap3.anarazel.de
Whole thread Raw
In response to Comparing primary/HS standby in tests  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2015-03-03 16:49:22 +0100, Andres Freund wrote:
> I every now and then run installcheck against a primary, verify that
> replay works without errors, and then compare pg_dumpall from both
> clusters. Unfortunately that currently requires hand inspection of
> dumps, there are differences like:
> -SELECT pg_catalog.setval('default_seq', 1, true);
> +SELECT pg_catalog.setval('default_seq', 33, true);
> 
> The reason these differences is that the primary increases the
> sequence's last_value by 1, but temporarily sets it to +SEQ_LOG_VALS
> before XLogInsert(). So the two differ.
> 
> Does anybody have a good idea how to get rid of that difference? One way
> to do that would be to log the value the standby is sure to have - but
> that's not entirely trivial.

I found a way that's actually fairly simple. On the primary call nextval
often enough to use up all the cached values. The below query does so:

DO $$
DECLARE
    s regclass;
BEGIN
    FOR s IN SELECT oid::regclass FROM pg_class WHERE relkind = 'S' LOOP
        EXECUTE format($s$SELECT nextval(%s), generate_series(1, log_cnt) FROM %s;$s$, s::oid, s::text);
    END LOOP;
END;$$;

After that dumps on master generate the same dump on primary / standby
for me, after running a regression test.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Draft back-branch release notes are up
Next
From: James Coleman
Date:
Subject: Re: Processing btree walks as a batch to parallelize IO