Horton

Re: [Proposal] Global temporary tables

曾文旌 (义从) <wenjing.zwj@alibaba-inc.com>

View thread
From: 曾文旌(义从) <wenjing.zwj@alibaba-inc.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "Konstantin Knizhnik" <k.knizhnik@postgrespro.ru>, "Pavel Stehule" <pavel.stehule@gmail.com>, "Erik Rijkers" <er@xs4all.nl>, "Tomas Vondra" <tomas.vondra@2ndquadrant.com>, "Julien Rouhaud" <rjuju123@gmail.com>, "Dean Rasheed" <dean.a.rasheed@gmail.com>, "PostgreSQL Hackers" <pgsql-hackers@postgresql.org>, 蔡松露(子嘉) <zijia@taobao.com>, Cai, Le <le.cai@alibaba-inc.com>, 萧少聪(铁庵) <shaocong.xsc@alibaba-inc.com>
Date: 2020-02-05T09:51:48Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. PageAddItemExtended(): Add LP_UNUSED assertion.

  2. Remove temporary files after backend crash

  3. Fix comment in indexing.c

  4. Fix failure to ignore leftover temp tables after a server crash.


> 2020年2月5日 上午4:57，Robert Haas <robertmhaas@gmail.com> 写道：
> 
> On Sat, Feb 1, 2020 at 11:14 AM 曾文旌(义从) <wenjing.zwj@alibaba-inc.com> wrote:
>> As global_private_temp-8.patch, think about:
>> 1 session X tale several hours doing some statistical work with the GTT A, which generated some data using transaction 100, The work is not over.
>> 2 Then session Y vacuumed A, and the GTT's relfrozenxid (in pg_class) was updated to 1000 0000.
>> 3 Then the aotuvacuum happened, the clog  before 1000 0000 was cleaned up.
>> 4 The data in session A could be lost due to missing clog, The analysis task failed.
>> 
>> However This is likely to happen because you allowed the GTT do vacuum.
>> And this is not a common problem, that not happen with local temp tables.
>> I feel uneasy about leaving such a question. We can improve it.
> 
> Each session is going to need to maintain its own notion of the
> relfrozenxid and relminmxid of each GTT to which it is attached.
> Storing the values in pg_class makes no sense and is completely
> unacceptable.
Yes, I've implemented it in global_temporary_table_v10-pg13.patch

> 
> -- 
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company