Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kFVA2-0005hv-61 for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Sep 2020 04:23:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kFV9z-0000Qb-FQ for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Sep 2020 04:23:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kFV9z-0000QT-8S for pgsql-hackers@lists.postgresql.org; Tue, 08 Sep 2020 04:23:11 +0000 Received: from mail-pg1-x541.google.com ([2607:f8b0:4864:20::541]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kFV9w-0002SV-Dl for pgsql-hackers@postgresql.org; Tue, 08 Sep 2020 04:23:10 +0000 Received: by mail-pg1-x541.google.com with SMTP id 5so9146106pgl.4 for ; Mon, 07 Sep 2020 21:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yksWFDCjHOvoU+8cXgIIpdfjhzMD+euUdk13C6xtZ38=; b=GtUwLw+PJdF3/C5/158bPA/SwmoCTFYMDM8YK+9HbCOGvRNp1VeQvowkQU3On0HIm4 CCY+j6P50NCUMJFNkJGZ6kjnipjhJVarsHXs9amzoSmPhAMiUjhOjQW9561aado8cEW5 03ZhePz+a0U9ufyGxDQoC4dBuKnAcIDHC1/O7y+MiDlO92hgRpTcPW2iwxJQEAM0iL1j +ktZx4RCZICZYfhstdFckkO8JnLR0z2Nt/to20nR2w/C7pZivPC4uwVl5W+VF/IavLT0 zmE9SYXykp/jQ1qi5QldwP420CYwcAh/g1rfhTrgkjWK1a//Fxxi0+UuzkWl6ZVM21hr 7psA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yksWFDCjHOvoU+8cXgIIpdfjhzMD+euUdk13C6xtZ38=; b=o1UwqHPhwY2elUld8UJdIjpx9/95jnoBAPcJ3/N21uZHHfWU8mlar8nVbqI2ElSciZ RzcPs4PK4LgL+afyZtrKUbPJEp6yGh5lIwr3v5pWnZPejPaDHnH9nLR/2+egJT8lhnaY c66S3oHmgpN90GeImwDieWt5o/Yf1hgEb06yBIHQ2HzmucOKNvLDyZqrlv0vXL8oHAY5 xybJP8ay1sOvgbAO289IDYcFQHNj7dUqt5HisGioT+K3vZ5TB2wYokRykcnyeiQtm4FA 8UJwmz13IPUGBrX5aelxBtzA+rOWlgwRVBFh/kTLlhxJJJqkN4f7vU194IAlvFz/1TVA VhcA== X-Gm-Message-State: AOAM531V2C/jq7cznqDmDjcHviIRneA76XGgbrFD5SK/1aALUMHoEZbo UJ9miOvUCdUBF3VIO2UQFh2B5Q== X-Google-Smtp-Source: ABdhPJy+Hs0AA5TqyIdAmK4hLYaRvpd8fESqVZswj3hBXMQrphAizV62LZSD7C9zKuJ56ndDGfBkqA== X-Received: by 2002:a17:902:264:: with SMTP id 91mr22106225plc.88.1599538986455; Mon, 07 Sep 2020 21:23:06 -0700 (PDT) Received: from osaka.octopusnet (p4375216-ipngn23601marunouchi.tokyo.ocn.ne.jp. [118.6.208.216]) by smtp.gmail.com with ESMTPSA id x7sm4972573pjv.16.2020.09.07.21.23.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2020 21:23:05 -0700 (PDT) Subject: Re: Improving connection scalability: GetSnapshotData() To: Andres Freund Cc: Michael Paquier , Tom Lane , Robert Haas , Thomas Munro , Alvaro Herrera , Daniel Gustafsson , "Jonathan S. Katz" , Alexander Korotkov , PostgreSQL Hackers , Peter Geoghegan , Bruce Momjian , David Rowley References: <20200815164200.drok4tt5ju7ijivf@alap3.anarazel.de> <20200816181604.l54m6kss5ntd6xow@alap3.anarazel.de> <1006917.1597602624@sss.pgh.pa.us> <1013484.1597609043@sss.pgh.pa.us> <20200816203153.xqfvuevinjkweuez@alap3.anarazel.de> <20200816205258.pjvmoljrk7ntqb3n@alap3.anarazel.de> <20200816211146.nodohy6ck6mzfjwi@alap3.anarazel.de> <20200816212657.3vyijoddr2yvgjjc@alap3.anarazel.de> <20200903081554.GB8559@paquier.xyz> <61291ffe-d611-f889-68b5-c298da9fb18f@2ndquadrant.com> <20200908041114.5woxns33iv765fgh@alap3.anarazel.de> From: Ian Barwick Message-ID: <0006ffe6-6f76-c074-3e58-2801cee1c05f@2ndquadrant.com> Date: Tue, 8 Sep 2020 13:23:01 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200908041114.5woxns33iv765fgh@alap3.anarazel.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/09/08 13:11, Andres Freund wrote: > Hi, > > On 2020-09-08 13:03:01 +0900, Ian Barwick wrote: (...) >> I wonder if it's possible to increment "xactCompletionCount" >> during replay along these lines: >> >> *** a/src/backend/access/transam/xact.c >> --- b/src/backend/access/transam/xact.c >> *************** xact_redo_commit(xl_xact_parsed_commit * >> *** 5915,5920 **** >> --- 5915,5924 ---- >> */ >> if (XactCompletionApplyFeedback(parsed->xinfo)) >> XLogRequestWalReceiverReply(); >> + >> + LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE); >> + ShmemVariableCache->xactCompletionCount++; >> + LWLockRelease(ProcArrayLock); >> } >> >> which seems to work (though quite possibly I've overlooked something I don't >> know that I don't know about and it will all break horribly somewhere, >> etc. etc.). > > We'd also need the same in a few more places. Probably worth looking at > the list where we increment it on the primary (particularly we need to > also increment it for aborts, and 2pc commit/aborts). Yup. > At first I was very confused as to why none of the existing tests have > found this significant issue. But after thinking about it for a minute > that's because they all use psql, and largely separate psql invocations > for each query :(. Which means that there's no cached snapshot around... > > Do you want to try to write a patch? Sure, I'll give it a go as I have some time right now. Regards Ian Barwick -- Ian Barwick https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services