Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iqRpY-0003GZ-UP for pgsql-hackers@arkaria.postgresql.org; Sun, 12 Jan 2020 01:14: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 1iqRpV-0006hL-Vw for pgsql-hackers@arkaria.postgresql.org; Sun, 12 Jan 2020 01:14:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iqRpV-0006dx-BV for pgsql-hackers@lists.postgresql.org; Sun, 12 Jan 2020 01:14:13 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iqRpP-0005zV-QD for pgsql-hackers@postgresql.org; Sun, 12 Jan 2020 01:14:11 +0000 Received: by mail-wr1-x443.google.com with SMTP id g17so5260086wro.2 for ; Sat, 11 Jan 2020 17:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=33jkJGiEXcmH/pxMyTUuK5E6MaUsxUTgsLP+Fik5QFc=; b=SCubAtGtvsFop6CjuDa0WQADm36cu0LjO+RU8hVwwe6zhUjbp9U9q3fQ6pbU+lnwI7 W8WFtsM2fXrgrDHxZFkCOtJ/UBG6FeQqQs1XV/cjVoGpW29fqiP3lupYs+VZ7g+aZv1/ ryrkX4PTvuxPhsvNZZSLRhgeLM5WVUQoX5VjAF4UjTvn1Z1ZYRxpbx3YCltQDH3uuObO a6A7oWuHqr292qAB4WbBZY32hFKSlid+Y7yqjogtgLSk3tnS6IZgweinOLVnU/7HDYf1 DiS1awBgYCtTzqTbqVLKTf6GiOUIr71Vpm6eLxC6vizrESA9Yrg9eCaUCxOp4WoU3LjF Ytcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=33jkJGiEXcmH/pxMyTUuK5E6MaUsxUTgsLP+Fik5QFc=; b=cLxhO5Z9JA+HcOzmdXoYTSYrScymsL8dBzwSD2q/rVAm+Iqszwpr3AbIxxCQH/SOC+ TsLApWulH5iRkdvayeEJeicpw4m5WhvMrm7ORUKoe9vnLDVuH/rWp2L6crNV0tyTgNe/ fbjQIJP/1KaLaDyvewU6FnBC/6ElZeF6qIqgxYUMiig8zXRwvWg5WftJvjFWYdrNn9xp 8VxSijZILGYbtuLYINUffH0RVSjZgiDXLDD/FEQqpbczfx17EPJ7/OUXeBgjzzAgC++r iIVYjy8/f9Uke5+N/iLPcLq8QOX6qc3egKijp3TV2pTd6XnNyU5RVEDR00wfgQv9cTsr trdw== X-Gm-Message-State: APjAAAX9qHnxz+Tyovo7Bxq6JFZzo4K0wqr6pm1GriVZ67FKZpfhUjLU E+8QQbZgircT1GdTnnd9FEztKQ== X-Google-Smtp-Source: APXvYqy3OGsnYm+dSg7db4AzQHQOs6WINt5V8CcMV4VKkZzY38Ow5vpUU48OxLehvjNeJmEPi6kgFQ== X-Received: by 2002:adf:edd0:: with SMTP id v16mr10787314wro.310.1578791645430; Sat, 11 Jan 2020 17:14:05 -0800 (PST) Received: from localhost (ip-86-49-253-92.net.upcbroadband.cz. [86.49.253.92]) by smtp.gmail.com with ESMTPSA id f1sm8763811wmc.45.2020.01.11.17.14.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jan 2020 17:14:03 -0800 (PST) Date: Sun, 12 Jan 2020 02:14:01 +0100 From: Tomas Vondra To: Konstantin Knizhnik Cc: =?utf-8?B?5pu+5paH5peMKOS5ieS7jik=?= , Pavel Stehule , Robert Haas , PostgreSQL Hackers , =?utf-8?B?6JSh5p2+6ZyyKOWtkOWYiSk=?= , "Cai, Le" , =?utf-8?B?6JCn5bCR6IGqKOmTgeW6tSk=?= Subject: Re: [Proposal] Global temporary tables Message-ID: <20200112011401.zwvvxoywrrivl542@development> References: <80cf30c2-ebd5-a568-9f62-a970e4d91326@postgrespro.ru> <5767433E-1A77-4682-B3FD-4869911021C8@alibaba-inc.com> <6b7570aa-14ea-2f28-c3b5-74dd785bbafe@postgrespro.ru> <20200105200603.wrb4beacwb57hhpk@development> <33969545-BEF7-4518-A741-302CBF7FF269@alibaba-inc.com> <20200106110119.zfrg2m5e2q5mvi5v@development> <3f360d7b-a46a-79f6-27b6-1b1df8c3ee82@postgrespro.ru> <20200109163037.u76k3kdr3pcmrytb@development> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Jan 10, 2020 at 03:24:34PM +0300, Konstantin Knizhnik wrote: > > >On 09.01.2020 19:30, Tomas Vondra wrote: > > >> >>> >>>> >>>>>3 Still no one commented on GTT's transaction information >>>>>processing, they include >>>>>3.1 Should gtt's frozenxid need to be care? >>>>>3.2 gtt’s clog clean >>>>>3.3 How to deal with "too old" gtt data >>>>> >>>> >>>>No idea what to do about this. >>>> >>> >>>I wonder what is the specific of GTT here? >>>The same problem takes place for normal (local) temp tables, doesn't it? >>> >> >>Not sure. TBH I'm not sure I understand what the issue actually is. > >Just open session, create temporary table and insert some data in it. >Then in other session run 2^31 transactions (at my desktop it takes >about 2 hours). >As far as temp tables are not proceeded by vacuum, database is stalled: > > ERROR:  database is not accepting commands to avoid wraparound data >loss in database "postgres" > >It seems to be quite dubious behavior and it is strange to me that >nobody complains about it. >We discuss  many issues related with temp tables (statistic, parallel >queries,...) which seems to be less critical. > >But this problem is not specific to GTT - it can be reproduced with >normal (local) temp tables. >This is why I wonder why do we need to solve it in GTT patch. > Yeah, I think that's out of scope for GTT patch. Once we solve it for plain temporary tables, we'll solve it for GTT too. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services