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 1jMHQN-0004m7-8L for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Apr 2020 20:35: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 1jMHQM-0001eo-5K for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Apr 2020 20:35:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jMHQL-0001eg-Uf for pgsql-hackers@lists.postgresql.org; Wed, 08 Apr 2020 20:35:49 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jMHQJ-00031N-P1 for pgsql-hackers@lists.postgresql.org; Wed, 08 Apr 2020 20:35:48 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id 038KZkwk013717; Wed, 8 Apr 2020 16:35:46 -0400 From: Tom Lane To: Anna Akenteva cc: Kyotaro Horiguchi , a.korotkov@postgrespro.ru, i.kartyshov@postgrespro.ru, amit.kapila16@gmail.com, pgsql-hackers@lists.postgresql.org Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed In-reply-to: References: <20200408.100945.375702947246835193.horikyota.ntt@gmail.com> Comments: In-reply-to Anna Akenteva message dated "Wed, 08 Apr 2020 22:36:28 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13715.1586378146.1@sss.pgh.pa.us> Date: Wed, 08 Apr 2020 16:35:46 -0400 Message-ID: <13716.1586378146@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Anna Akenteva writes: > I'd like to hear others' opinions on the syntax as well. Pardon me for coming very late to the party, but it seems like there are other questions that ought to be answered before we worry about any of this. Why is this getting grafted onto BEGIN/START TRANSACTION in the first place? It seems like it would be just as useful as a separate command, if not more so. You could always start a transaction just after waiting. Conversely, there might be reasons to want to wait within an already-started transaction. If it could survive as a separate command, then I'd humbly suggest that it requires no grammar work at all. You could just invent one or more functions that take suitable parameters. regards, tom lane