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 1g91pY-000506-R6 for pgsql-hackers@arkaria.postgresql.org; Sun, 07 Oct 2018 05:42:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g91pW-0001tp-Lj for pgsql-hackers@arkaria.postgresql.org; Sun, 07 Oct 2018 05:42:14 +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 1g91pW-0001ti-8U for pgsql-hackers@lists.postgresql.org; Sun, 07 Oct 2018 05:42:14 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g91pO-0007mH-25 for pgsql-hackers@postgresql.org; Sun, 07 Oct 2018 05:42:12 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 42F1221C1FB8; Sun, 7 Oct 2018 08:42:03 +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 [192.168.0.37] (unknown [92.243.182.171]) (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 C8A4F21C1FA4; Sun, 7 Oct 2018 08:42:02 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1538890922; bh=hH4PT3z8unn8TtppPdfe7PXkOSSQIWRjgXE1w6NiIVE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=jkuo7cK4aXH5GpZWufGNhbP9IXXPPVBgPHkGpIUzkRG6kLZOg/4O194H/LrLxoL4C lb2pzQE0wi8qxRehSjWu2jutZqwS0QISSkLmfiBxad86L5zJEqjkF8b4pN27TtBYtZ +bLPjS5D0BV21aJ2GC9bTJ+TlTwiTztr1mnjiSX4= Subject: Re: now() vs transaction_timestamp() To: Amit Kapila , Tom Lane Cc: pgsql-hackers , Robert Haas References: <6406dbd2-5d37-4cb6-6eb2-9c44172c7e7c@postgrespro.ru> <4268.1538747795@sss.pgh.pa.us> <4911.1538774725@sss.pgh.pa.us> <9c78b24f-4ec9-e1dd-bdf6-e09e9b5f0e31@postgrespro.ru> <14825.1538842224@sss.pgh.pa.us> From: Konstantin Knizhnik Message-ID: <3096a889-7ad2-94fa-1c58-468444690d3e@postgrespro.ru> Date: Sun, 7 Oct 2018 08:42:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 07.10.2018 07:58, Amit Kapila wrote: > On Sat, Oct 6, 2018 at 9:40 PM Tom Lane wrote: >> Konstantin Knizhnik writes: >>> On 06.10.2018 00:25, Tom Lane wrote: >>>> So maybe the right answer is to change the parallel mode infrastructure >>>> so it transmits xactStartTimestamp, making transaction_timestamp() >>>> retroactively safe, and then in HEAD only we could re-mark now() as >>>> safe. We might as well do the same for statement_timestamp as well. >>> Attached please find very small patch fixing the problem (propagating >>> transaction and statement timestamps to workers). >> That's a bit too small ;-) ... one demonstrable problem with it is >> that the parallel worker will report the wrong xactStartTimestamp >> to pgstat_report_xact_timestamp(), since you aren't jamming the >> transmitted value in soon enough. Also, I found that ParallelWorkerMain >> executes at least two transactions before it ever gets to the "main" >> transaction that does real work, and I didn't much care for the fact >> that those were running with worker-local values of xactStartTimestamp >> and stmtStartTimestamp. So I rearranged things a bit to ensure that >> parallel workers wouldn't generate their own values for either >> timestamp, and pushed it. >> > Currently, we serialize the other transaction related stuff via > PARALLEL_KEY_TRANSACTION_STATE. Yes, it was my first though to add serialization of timestamps to SerializeTransactionState. But it performs serialization into array of TransactionId, which is 32-bit (except PGProEE), and so too small for TimestampTz. Certainly it is possible to store timestamp into pair of words, but frankly speaking I do not like approach used in SerializeTransactionState: IMHO serializer should either produce stream of bytes, either use some structure. Serialization to array of words combines drawbacks of both approaches. Also using type TransactionId for something very different from XIDs seems to be not so good idea. > However, this patch has serialized > xact_ts via PARALLEL_KEY_FIXED which appears okay, but I think it > would have been easier for future readers of the code if all the > similar state variables have been serialized by using the same key. >