Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g8Qb2-0002qM-1V for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Oct 2018 13:56:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g8Qaz-0000ex-JA for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Oct 2018 13:56:45 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g8Qaz-0000eq-95 for pgsql-hackers@lists.postgresql.org; Fri, 05 Oct 2018 13:56:45 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g8Qaw-0006Ko-MX for pgsql-hackers@postgresql.org; Fri, 05 Oct 2018 13:56:44 +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 w95DuZ6X004269; Fri, 5 Oct 2018 09:56:35 -0400 From: Tom Lane To: Konstantin Knizhnik cc: PostgreSQL Hackers Subject: Re: now() vs transaction_timestamp() In-reply-to: <6406dbd2-5d37-4cb6-6eb2-9c44172c7e7c@postgrespro.ru> References: <6406dbd2-5d37-4cb6-6eb2-9c44172c7e7c@postgrespro.ru> Comments: In-reply-to Konstantin Knizhnik message dated "Fri, 05 Oct 2018 16:29:28 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4267.1538747795.1@sss.pgh.pa.us> Date: Fri, 05 Oct 2018 09:56:35 -0400 Message-ID: <4268.1538747795@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Konstantin Knizhnik writes: > Postgres documentation says that |"now()| is a traditional PostgreSQL > equivalent to |transaction_timestamp()|". > Also both use the same implementation. Right. > But them have different parallel safety property: That seems like a bug/thinko. I am not sure which property setting is correct though. It'd only be safe if the parallel-query infrastructure transfers the relevant timestamp to workers, and I don't know if it does. regards, tom lane