Subject: Re: snapbuild woes
To: Andres Freund <andres@anarazel.de>
References: <20170418041657.hvwss6hz73ghozp5@alap3.anarazel.de>
 <20170422053621.2qtvurecfatet2ei@alap3.anarazel.de>
 <20170428043444.GD787347@rfd.leadboat.com>
 <D8279AAF-3532-4F66-9D31-1BEEDBAC0819@anarazel.de>
 <20170504054516.GA850485@rfd.leadboat.com>
 <F8C3AE44-4507-4C26-9B50-112A929D276D@anarazel.de>
 <20170511215155.bnigoevqoe4hejmg@alap3.anarazel.de>
 <20170511215426.5u2itcy5mruo65on@alap3.anarazel.de>
 <20170512013127.ytncnqvlluheandz@alap3.anarazel.de>
 <c8d39fad-d163-7a6d-512c-03c4999a8e67@2ndquadrant.com>
 <20170513202331.pkbmv2n5yqfjhety@alap3.anarazel.de>
Cc: Noah Misch <noah@leadboat.com>, pgsql-hackers@postgresql.org,
 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
 Erik Rijkers <er@xs4all.nl>, David Steele <david@pgmasters.net>,
 Robert Haas <robertmhaas@gmail.com>, Craig Ringer <craig@2ndquadrant.com>,
 pgsql-hackers-owner@postgresql.org
From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Message-ID: <76d171d2-7765-680a-7868-68f6f4a43623@2ndquadrant.com>
Date: Sun, 14 May 2017 14:54:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170513202331.pkbmv2n5yqfjhety@alap3.anarazel.de>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 13/05/17 22:23, Andres Freund wrote:
> On 2017-05-12 10:57:55 +0200, Petr Jelinek wrote:
>> Hmm, well it helps but actually now that we don't track individual
>> running transactions anymore it got much less effective (my version of
>> 0005 does as well).
>>
>> The example workload I test with is:
>> session 1: open transaction, do a write, keep it open
>> session 2: pgbench  -M simple -N -c 10 -P 1 -T 5
>> session 3: run CREATE_REPLICATION_SLOT LOGICAL in walsender
>> session 2: pgbench  -M simple -N -c 10 -P 1 -T 20
>> session 1: commit
>>
>> And wait for session 3 to finish slot creation, takes about 20 mins on
>> my laptop without patches, minute and half with your patches for 0004
>> and 0005 (or with your 0004 and my 0005) and about 2s with my original
>> 0004 and 0005.
> 
> Is that with assertions enabled or not?  With assertions all the time
> post patches seems to be spent in some Asserts in reorderbuffer.c,
> without it takes less than a second for me here.
>

Right you are, I always forget to switch that off before benchmarks.

> I'm appylying these now.

Cool. Just for posterity, this also fixes the issue number 3 as the
switch to consistent state is done purely based on xl_running_xacts and
not decoded commits/aborts.

So all done here, thanks!

-- 
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers