Re: snapbuild woes

From: Erik Rijkers <er(at)xs4all(dot)nl>
To: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>
Subject: Re: snapbuild woes
Date: 2017-02-22 10:29:12
Message-ID: 5094adef5a2c1cc3f56c18a0252176dd@xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-02-22 03:05, Petr Jelinek wrote:
>
> So to summarize attached patches:
> 0001 - Fixes performance issue where we build tons of snapshots that we
> don't need which kills CPU.
>
> 0002 - Disables the use of ondisk historical snapshots for initial
> consistent snapshot export as it may result in corrupt data. This
> definitely needs backport.
>
> 0003 - Fixes bug where we might never reach snapshot on busy server due
> to race condition in xl_running_xacts logging. The original use of
> extra
> locking does not seem to be enough in practice. Once we have agreed fix
> for this it's probably worth backpatching. There are still some
> comments
> that need updating, this is more of a PoC.
>

I am not not entirely sure what to expect. Should a server with these 3
patches do initial data copy or not? The sgml seems to imply there is
not inital data copy. But my test does copy something.

Anyway, I have repeated the same old pgbench-test, assuming inital data
copy should be working.

With
> 0001-Skip-unnecessary-snapshot-builds.patch
> 0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch
> 0003-Fix-xl_running_xacts-usage-in-snapshot-builder.patch

the consistent (but wrong) end state is always that only one of the four
pgbench tables, pgbench_history, is replicated (always correctly).

Below is the output from the test (I've edited the lines for email)
(below, a,b,t,h stand for: pgbench_accounts, pgbench_branches,
pgbench_tellers, pgbench_history)
(master on port 6972, replica on port 6973.)

port
6972 a,b,t,h: 100000 1 10 347
6973 a,b,t,h: 0 0 0 347

a,b,t,h: a68efc81a 2c27f7ba5 128590a57 1e4070879 master
a,b,t,h: d41d8cd98 d41d8cd98 d41d8cd98 1e4070879 replica NOK

The md5-initstrings are from a md5 of the whole content of each table
(an ordered select *)

I repeated this a few times: of course, the number of rows in
pgbench_history varies a bit but otherwise it is always the same: 3
empty replica tables, pgbench_history replicated correctly.

Something is not right.

thanks,

Erik Rijkers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rushabh Lathia 2017-02-22 10:57:55 Re: Push down more UPDATEs/DELETEs in postgres_fdw
Previous Message Pavel Stehule 2017-02-22 08:51:28 Re: GRANT EXECUTE ON FUNCTION foo() TO bar();