Re: Global temporary tables

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Global temporary tables
Date: 2019-08-21 08:54:29
Message-ID: 2d51d648-87f9-3480-e8d9-0279e8f8cd53@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20.08.2019 20:01, Pavel Stehule wrote:
> Another solution is wait on ZHeap storage and replica can to have own
> UNDO log.
>
>>
> I thought about implementation of special table access method for
> temporary tables.
>
>
> +1
>
Unfortunately implementing special table access method for temporary
tables doesn't solve all problems.
XID generation is not part of table access methods.
So we still need to assign some XID to write transaction at replica
which will not conflict with XIDs received from master.
Actually only global temp tables can be updated at replica and so
assigned XIDs can be stored only in tuples of such relations.
But still I am not sure that we can use arbitrary XID for such
transactions at replica.

Also I upset by amount of functionality which has to be reimplemented
for global temp tables if we really want to provide access method for them:

1. CLOG
2. vacuum
3. MVCC visibility

And still it is not possible to encapsulate all changes need to support
writes to temp tables at replica inside table access method.
XID assignment, transaction commit and abort, subtransactions - all this
places need to be patched.

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2019-08-21 09:20:18 Optimization of vacuum for logical replication
Previous Message Dilip Kumar 2019-08-21 07:54:53 Re: POC: Cleaning up orphaned files using undo logs