From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Comparing primary/HS standby in tests |
Date: | 2021-05-07 18:04:24 |
Message-ID: | 20210507180424.kq2huo6425c3sfgn@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2021-05-07 18:11:23 | Re: Processing btree walks as a batch to parallelize IO |
Previous Message | Tom Lane | 2021-05-07 17:56:55 | Re: Draft back-branch release notes are up |