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 1g9ZHH-0005Ee-Oa for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Oct 2018 17:25:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g9ZHG-0005Z3-3R for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Oct 2018 17:25:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g9ZHF-0005Yw-ST for pgsql-hackers@lists.postgresql.org; Mon, 08 Oct 2018 17:25:05 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g9ZHB-0004T3-3f for pgsql-hackers@lists.postgresql.org; Mon, 08 Oct 2018 17:25:05 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id EEAB5221C6; Mon, 8 Oct 2018 13:24:59 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 08 Oct 2018 13:24:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:to:cc:from:message-id; s=fm2; bh=5lMxYcHZelGbwG/Ec/j8W/LUQEWNcHF17v13LHD8xzo=; b=uLbNw+Se/NNx HpmzMHhuGFIm9t4O7BsSlyCsXuOKDTl1ifbYHbWdezUdDDX7fMmo7r2mWZZxdq8n 0wB2yZUkaMtQyP1nrwwpM9vdlZT/A5nNBDluZQPplWq+LTaXvFmoFUpMmV1TGa0J pfGvD7/gXYpDjUFY9aRwYXiP/7WQwpk+mYY7LyktnY/ON4KfXhAeZ3ODiJEGaWiI Zff5YG6y66E1ttMysJD0+DjuacCm9jdqHxnOmP/mq2vZSvD/M4ta2ov3ftssruDw Xe9FTiaKWtHCgFujReo0a25ynp446EnYn1TdTaSeydxqbJrwaiOvV04P8Ypa/p2n 4VoEvDCCWw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=5lMxYcHZelGbwG/Ec/j8W/LUQEWNcHF17v13LHD8x zo=; b=AHfzET7H/cZSI26Ci4XQcEaiVRRsXdgpN78l9cgND/bXRR4Rm7glSR4bv nV6w9WfoRqWbHzCTnGgRHGglxWkSa5ti43SBAuYDKD7OV65GIkfD8dgviJjVlk7f bULwVEncrxfHFutd3S3PuU2qbX9Q1LDVR5q2FGcSoG3/PMnQ0ABZfCsGn4a1BlMN JcJcaSaVJCtnCSy1IQ5uSbSxzv4/20IzypWMG0RtTkkpwhs3VNCdGflfHB8Zc0Kd MdLXV9nrK5pbUdwVss3JGhcGDcbBQsLoKmEDT6KwtglCLeAzDjHdESDfMRMa6ZwS hXdDGJxV3XCc7+6YQq0FJ/0iJIw6g== X-ME-Sender: X-ME-Proxy: Received: from [100.234.112.101] (unknown [172.58.35.84]) by mail.messagingengine.com (Postfix) with ESMTPA id 0CD52E473B; Mon, 8 Oct 2018 13:24:58 -0400 (EDT) Date: Mon, 08 Oct 2018 10:24:56 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <27414.1539018874@sss.pgh.pa.us> References: <20180926155443.u4zh7jactzflys3z@alvherre.pgsql> <20181002145853.wvhcb7pbrzgjyxns@alap3.anarazel.de> <38e36919-8bee-c717-be99-91137ad28aaf@2ndquadrant.com> <27414.1539018874@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: transction_timestamp() inside of procedures To: pgsql-hackers@lists.postgresql.org,Tom Lane ,Peter Eisentraut CC: PostgreSQL-development ,Alvaro Herrera ,Bruce Momjian ,Michael Paquier From: Andres Freund Message-ID: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On October 8, 2018 10:14:34 AM PDT, Tom Lane wro= te: >Peter Eisentraut writes: >> On 02/10/2018 16:58, Andres Freund wrote: >>> It's a bit weird to make this decision based on these two timestamps >>> differing=2E For one, it only indirectly seems to be guaranteed that >>> xactStartTimestamp is even set to anything here (to 0 by virtue of >being >>> a global var)=2E > >> Maybe but it seems to be the simplest way without doing major surgery >to >> all this code=2E > >This patch doesn't apply over 07ee62ce9=2E Also, I like the >timestamp-comparison approach even less than Andres does: I think it's >probably outright broken, especially since it treats the equality case >as license to advance xactStartTimestamp=2E > >Surely there is some way that we can directly test whether we're inside >a >procedure or not? I think the logic should be basically > > if (!IsParallelWorker()) >+ { >+ if (!InsideProcedure()) > xactStartTimestamp =3D stmtStartTimestamp; >+ else >+ xactStartTimestamp =3D GetCurrentTimestamp(); >+ } > else > Assert(xactStartTimestamp !=3D 0); Seems more reasonable from here=2E Andres --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E