Re: [HACKERS] snapbuild woes
От | Erik Rijkers |
---|---|
Тема | Re: [HACKERS] snapbuild woes |
Дата | |
Msg-id | 5094adef5a2c1cc3f56c18a0252176dd@xs4all.nl обсуждение исходный текст |
Ответ на | Re: [HACKERS] snapbuild woes (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] snapbuild woes
|
Список | 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
В списке pgsql-hackers по дате отправления: