Re: Improving replay of XLOG_BTREE_VACUUM records

From: Vladimir Borodin <root(at)simply(dot)name>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improving replay of XLOG_BTREE_VACUUM records
Date: 2016-03-25 18:09:13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 25 марта 2016 г., в 19:11, David Steele <david(at)pgmasters(dot)net> написал(а):
> Hi Vladimir,
> On 3/14/16 2:15 PM, Vladimir Borodin wrote:
>> JFYI, I’m preparing the stand to reproduce the initial problem and I
>> hope to finish testing this week.
> Do you know when you'll have the results from the testing you were going to do? It seems this patch is currently waiting on that to be finished.

I couldn’t reproduce the problem on pgbench database with scale factor 50000 last week. The test case was quite simple:
1. On master I was adding data to pgbench_accounts table.
2. On standby I was doing the following:
postgres(at)pgload01d ~ $ cat /tmp/query
\set naccounts 100000 * :scale
SELECT aid FROM pgbench_accounts WHERE aid = :naccounts;
postgres(at)pgload01d ~ $ /usr/pgsql-9.6/bin/pgbench -M prepared -f /tmp/query -c 1 -j 1 -T 3600 -P 10 -S -n pgbench
3. On master I was sometimes calling VACUUM pgbench_accounts.

Without applying patches there weren’t huge replication lags on standbys. Seems, that I'm doing something wrong… I’m doing my best right now to find the reason but I can’t give you any time evaluation :(

> Thanks,
> --
> -David
> david(at)pgmasters(dot)net
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:

May the force be with you…

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Ivanov 2016-03-25 18:42:12 Re: [PATCH] Phrase search ported to 9.6
Previous Message Abhijit Menon-Sen 2016-03-25 17:57:20 Re: dealing with extension dependencies that aren't quite 'e'