Subject: Re: Global temporary tables
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Craig Ringer <craig@2ndquadrant.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <73954ab7-44d3-b37b-81a3-69bdcbb446f7@postgrespro.ru>
 <CAMsr+YF-_ni33MWLEMc3jtbh_-SFSfBBpXCsPBfiB_bTYKoQug@mail.gmail.com>
 <758e5293-3ccd-3a6a-8464-6373bb441994@postgrespro.ru>
 <d9e4ad3a-4532-17aa-b928-d861602bccc6@postgrespro.ru>
 <CAFj8pRDfDGReVdPcD_nXqnukMfY2gmi1mjkB3o1-KQgQz17mwA@mail.gmail.com>
 <0bc85c39-67a2-3bb4-d6fc-bf78862147a5@postgrespro.ru>
 <CAFj8pRBEVp-wp-EAbuHaTuefc1WPg897iBW_1r5-wZ2NKKkNOw@mail.gmail.com>
 <0e2cf77c-a67f-0bdc-fb4f-844c166d71de@postgrespro.ru>
 <d43b82e2-41da-eaae-065f-6aaf1c7728a8@postgrespro.ru>
 <CAFj8pRCScMe34apHZz7HL6tmzkVwBba_HbcqTBJAv9n=oq1ADA@mail.gmail.com>
 <b7fd5769-e505-e64d-94b8-237a81531be9@postgrespro.ru>
 <CAFj8pRAFbHvdOTyOjB2utcBQDojXBr+Uuw+yWRCsz9Rv7GYJhg@mail.gmail.com>
 <c504633d-1658-8cf2-3446-d031f9b8b2c3@postgrespro.ru>
 <CAFj8pRB5PPsNRCuihUvU192jDs1=Tb5khynoR73x69Rhupqe7Q@mail.gmail.com>
 <202c1a08-463d-3e8b-a5be-99f59df4e9f9@postgrespro.ru>
 <CAFj8pRCMmU7XPYpfA7FZS4pFBPwHZ=+B6wF6Z72LTXHEzfkDFA@mail.gmail.com>
From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Message-ID: <2d51d648-87f9-3480-e8d9-0279e8f8cd53@postgrespro.ru>
Date: Wed, 21 Aug 2019 11:54:29 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: 
 <CAFj8pRCMmU7XPYpfA7FZS4pFBPwHZ=+B6wF6Z72LTXHEzfkDFA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------0F5FC3A79C76D2F55928D27B"
Content-Language: en-US
Precedence: bulk

This is a multi-part message in MIME format.
--------------0F5FC3A79C76D2F55928D27B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


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


--------------0F5FC3A79C76D2F55928D27B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 20.08.2019 20:01, Pavel Stehule
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAFj8pRCMmU7XPYpfA7FZS4pFBPwHZ=+B6wF6Z72LTXHEzfkDFA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Another solution is wait on ZHeap storage and
        replica can to have own UNDO log. <br>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div bgcolor="#FFFFFF">
              <blockquote type="cite">
                <div dir="ltr">
                  <div class="gmail_quote">
                    <div><br>
                    </div>
                  </div>
                </div>
              </blockquote>
              I thought about implementation of special table access
              method for temporary tables.<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>+1<br>
          </div>
          <div> </div>
          <br>
        </div>
      </div>
    </blockquote>
    Unfortunately implementing special table access method for temporary
    tables doesn't solve all problems.<br>
    XID generation is not part of table access methods.<br>
    So we still need to assign some XID to write transaction at replica
    which will not conflict with XIDs received from master.<br>
    Actually only global temp tables can be updated at replica and so
    assigned XIDs can be stored only in tuples of such relations.<br>
    But still I am not sure that we can use arbitrary XID for such
    transactions at replica.<br>
    <br>
    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:<br>
    <br>
    1. CLOG<br>
    2. vacuum<br>
    3. MVCC visibility<br>
    <br>
    And still it is not possible to encapsulate all changes need to
    support writes to temp tables at replica inside table access method.<br>
    XID assignment, transaction commit and abort, subtransactions - all
    this places need to be patched.<br>
    <br>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Konstantin Knizhnik
Postgres Professional: <a class="moz-txt-link-freetext" href="http://www.postgrespro.com">http://www.postgrespro.com</a>
The Russian Postgres Company </pre>
  </body>
</html>

--------------0F5FC3A79C76D2F55928D27B--