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 1jLn1E-0005jx-3x for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2020 12:07:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jLn1B-00087O-GU for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2020 12:07:49 +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 1jLn1B-00087H-4g for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2020 12:07: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 1jLn16-0004pz-Nu for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2020 12:07:47 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 3CAD921C595A; Tue, 7 Apr 2020 15:07:43 +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 0421E21C5825; Tue, 7 Apr 2020 15:07:42 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1586261263; bh=JMeTSPcAcCWBTDAJJoUQrAN7xDnzhmLDCXn3ixYs1vo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=KjtMfjvZZfZt8HJkNnuF6bb6OLgeV3QL5hwRDXzOMD2BJP+Ya9Rx/Bi7B3SbIxiVL lgwugr73/j/o1COP/9I3LA1NDegkyjtcXZREHZhjQU07baB3qB0GTE+lfoOPxtCXyl 9OZStPVkoiT9RpBWJryaFVnVtRMzRBQN8AaDIUX0= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 07 Apr 2020 15:07:42 +0300 From: Anna Akenteva To: Amit Kapila Cc: Alexander Korotkov , Kartyshov Ivan , PostgreSQL Hackers Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed In-Reply-To: References: <80f267591b373db5588d580fdfb432f0@postgrespro.ru> <20200306.145445.1788163547829857988.horikyota.ntt@gmail.com> <3cc883048264c2e9af022033925ff8db@postgrespro.ru> <674ad239b725a11d89c21574e44e376b@postgrespro.ru> <69a363498b76cd079ae19c4ee93bced0@postgrespro.ru> <06bfb1e542a25c3ebfc4232be4d49555@postgrespro.ru> <9d112e474c311b6b4c20566314283638@postgrespro.ru> User-Agent: Roundcube Webmail/1.4.0 Message-ID: X-Sender: a.akenteva@postgrespro.ru Organization: Postgres Professional List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-04-07 13:32, Amit Kapila wrote: > First, I don't > think we have a consensus on the syntax being used in the patch > (various people didn't agree to LSN specific syntax). They wanted a > more generic syntax and I see that we tried to implement it and it > turns out to be a bit complex but that doesn't mean we just give up on > the idea and take the simplest approach and that too without a broader > agreement. Thank you for your comments! Initially, the syntax used to be "WAITLSN", which confined us with only waiting for LSN-s and not anything else. So we switched to "WAIT FOR LSN", which would allow us to add variations like "WAIT FOR XID" or "WAIT FOR COMMIT TOKEN" in the future if we wanted. A few people seemed to imply that this kind of syntax is expandable enough: On 2018-02-01 14:47, Simon Riggs wrote: > I agree that WAIT LSN is good syntax because this allows us to wait > for something else in future. On 2017-10-31 12:42:56, Ants Aasma wrote: > For lack of a better proposal I would like something along the lines > of: > WAIT FOR state_id[, state_id] [ OPTIONS (..)] As for giving up waiting for multiple events: we can only wait for LSN-s at the moment, and there seems to be no point in waiting for multiple LSN-s at once, because it's equivalent to waiting for the biggest LSN. So we opted for simpler grammar for now, only letting the user specify one LSN and one TIMEOUT. If in the future we allow waiting for something else, like XID-s, we can expand the grammar as needed. What are your own thoughts on the syntax? -- Anna Akenteva Postgres Professional: The Russian Postgres Company http://www.postgrespro.com