Re: alter table set TABLE ACCESS METHOD

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Jacob Champion <pchampion(at)vmware(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Ashwin Agrawal <aagrawal(at)pivotal(dot)io>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: alter table set TABLE ACCESS METHOD
Date: 2021-03-01 02:16:36
Message-ID: YDxOhIGLPEGYINNP@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 28, 2021 at 04:25:30PM -0600, Justin Pryzby wrote:
> I called this "set TABLE access method" rather than just "set access method"
> for the reasons given on the LIKE thread:
> https://www.postgresql.org/message-id/20210119210331.GN8560@telsasoft.com

ALTER TABLE applies to a table (or perhaps a sequence, still..), so
that sounds a bit weird to me to add again the keyword "TABLE" for
that.

> I've tested this with zedstore, but the lack of 2nd, in-core table AM limits
> testing possibilities. It also limits at least my own ability to reason about
> the AM API.
>
> For example, I was surprised to hear that toast is a concept that's
> intended to be applied to AMs other than heap.
> https://www.postgresql.org/message-id/flat/CA%2BTgmoYTuT4sRtviMLOOO%2B79VnDCpCNyy9rK6UZFb7KEAVt21w%40mail.gmail.com

What kind of advanced testing do you have in mind? It sounds pretty
much enough to me for a basic patch to use the trick with heap2 as
your patch does. That would be enough to be sure that the rewrite
happens and that data is still around. If you are worrying about
recovery, a TAP test with an immediate stop of the server could
equally be used to check after the FPWs produced for the new
relfilenode during the rewrite.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2021-03-01 02:22:07 Re: [BUG] segfault during delete
Previous Message Ajin Cherian 2021-03-01 01:53:17 Re: repeated decoding of prepared transactions