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 1jKNKR-00028N-99 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2020 14:29:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jKNKQ-0006Dd-5i for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2020 14:29:50 +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 1jKNKP-0006DW-Qg for pgsql-hackers@lists.postgresql.org; Fri, 03 Apr 2020 14:29:49 +0000 Received: from cyclops.postgrespro.ru ([93.174.131.138] helo=mail.postgrespro.ru) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jKNKN-00081L-2i for pgsql-hackers@lists.postgresql.org; Fri, 03 Apr 2020 14:29:49 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 3B57C21C580C; Fri, 3 Apr 2020 17:29:46 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from mail.postgrespro.ru (cyclops.l.postgrespro.ru [192.168.27.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id C975621C5807; Fri, 3 Apr 2020 17:29:45 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1585924186; bh=CAFB50f9OikvQ0uy/DidKDoVZekqCkvsFeaP+oOgwYs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=D6xvbk5yXgbC+tkVatkVMh0y00DkEPEv/JkYHpBApFARtnI6LtO1ry50qVd4oCjVH VnlGC1Zk8QW4H69PVXiwGE+OvL5LBaI9KAzdX6T0N8Ba9JmvpJDGEuV0zrKKtaPVti So5dn4zkAb+iV19PYEHFQ7L6wiYWJsrCHyGbxXNo= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 03 Apr 2020 17:29:45 +0300 From: Alexey Kondratov To: Anna Akenteva , Ivan Kartyshov , Kyotaro Horiguchi , Adam Brusselback Cc: pgsql-hackers@lists.postgresql.org Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed In-Reply-To: <674ad239b725a11d89c21574e44e376b@postgrespro.ru> References: <80f267591b373db5588d580fdfb432f0@postgrespro.ru> <20200306.145445.1788163547829857988.horikyota.ntt@gmail.com> <3cc883048264c2e9af022033925ff8db@postgrespro.ru> <674ad239b725a11d89c21574e44e376b@postgrespro.ru> User-Agent: Roundcube Webmail/1.4.0 Message-ID: <69a363498b76cd079ae19c4ee93bced0@postgrespro.ru> X-Sender: a.kondratov@postgrespro.ru List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-04-01 02:26, Anna Akenteva wrote: > On 2020-03-27 04:15, Kartyshov Ivan wrote: >> Anna, feel free to work on this patch. > > Ivan and I worked on this patch a bit more. We fixed the bugs that we > could find and cleaned up the code. For now, we've kept both options: > WAIT as a standalone statement and WAIT as a part of BEGIN. The new > patch is attached. > > The syntax looks a bit different now: > > - WAIT FOR [ANY | ALL] event [, ...] > - BEGIN [ WORK | TRANSACTION ] [ transaction_mode [, ...] ] [ WAIT FOR > [ANY | ALL] event [, ...]] > where event is one of: > LSN value > TIMEOUT number_of_milliseconds > timestamp > > Now, one event cannot contain both an LSN and a TIMEOUT. > In my understanding the whole idea of having TIMEOUT was to do something like 'Do wait for this LSN to be replicated, but no longer than TIMEOUT milliseconds'. What is the point of having plain TIMEOUT? It seems to be equivalent to pg_sleep, doesn't it? Regards -- Alexey Kondratov Postgres Professional https://www.postgrespro.com Russian Postgres Company