Message-ID: <ebdbbe8d0b905e797d4bb10157e44f9fe6ecb389.camel@cybertec.at>
Subject: Re: Best Approach for Swapping a Table with its Copy
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Marcelo Fernandes <marcefern7@gmail.com>, Adrian Klaver
	 <adrian.klaver@aklaver.com>
Cc: Dominique Devienne <ddevienne@gmail.com>, Greg Sabino Mullane
	 <htamfids@gmail.com>, pgsql-general@lists.postgresql.org
Date: Fri, 14 Feb 2025 06:41:07 +0100
In-Reply-To: <CAM2F1VMApyPvdA4ERoF7Fob6CXimgOWMKC1vayO5OQa3TtJAFQ@mail.gmail.com>
References: 
	<CAM2F1VP9nn0F6fSjbmhJCNSjv-dbAJcAytZ2HkTkZ0dGYZvxrw@mail.gmail.com>
	 <8ac6a1dd-db82-4ea7-8186-0c354d79049f@aklaver.com>
	 <CAM2F1VOOn1izCrtcrDx4YUtCY-H64Vj5yvN5H1Lhk8kCY+_W6Q@mail.gmail.com>
	 <9fa75099-1ee9-43de-ac6e-945841b184eb@aklaver.com>
	 <CAM2F1VONo8M9gcybhmf8-CdmRUC2QrFGZkZLYF-+uLZuhRKaxQ@mail.gmail.com>
	 <22406cdf-83f5-4b98-b07e-7827afe97f93@aklaver.com>
	 <CAM2F1VMdDSxLhccn=0pXriJrR6a7Oe9Kir1DB_0pW1v88bsvCg@mail.gmail.com>
	 <CAKAnmmJ04kH_gWR+cOFWD0h63RDck1k6hqQYH8K30-cfCvtO_Q@mail.gmail.com>
	 <CAFCRh-9xC0CXKM2GTQBfjYY5GQx29Uit+fY5PpBFTvX927YC8w@mail.gmail.com>
	 <94e1205e-8ddf-403b-8477-02d7939f2905@aklaver.com>
	 <CAM2F1VMApyPvdA4ERoF7Fob6CXimgOWMKC1vayO5OQa3TtJAFQ@mail.gmail.com>
User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) 
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/ebdbbe8d0b905e797d4bb10157e44f9fe6ecb389.camel%40cybertec.at>
Precedence: bulk

On Fri, 2025-02-14 at 11:59 +1300, Marcelo Fernandes wrote:
> On Thu, Feb 13, 2025 at 7:37=E2=80=AFPM Laurenz Albe <laurenz.albe@cybert=
ec.at> wrote:
> > The big challenge here would be to do the swap in a safe way.  How do
> > you intend to guarantee that the foreign keys are valid without a table
> > scan?  How do you handle concurrent data modifications?
>=20
> Exactly! This is part of what I am trying to figure out (-:
>=20
> The plan that I have in mind so far to swap a table safely is:
>=20
> 1. Run the following query to grab information about the toast and the to=
ast
>    index of the tables involved in the swapping:
>=20
>   SELECT
>     X.oid,
>     X.reltoastrelid,
>     X.relowner,
>     TOAST_X.indexrelid
>   FROM pg_catalog.pg_class X
>     LEFT JOIN
>       pg_catalog.pg_index TOAST_X ON X.reltoastrelid =3D
> TOAST_X.indrelid AND TOAST_X.indisvalid
>   WHERE X.oid =3D ('my_sweet_table')::regclass;
>=20
> 2. Open a transaction and acquire an access exclusive lock.
> 3. Ensure that the cloned table has the same owner as the original table
>=20
>   ALTER TABLE copy_table OWNER TO owner_of_the_original_table;
>=20
> 4. Now I need to swap all the data in the catalogue tables that point to =
the
>    old table and the toast to point to the new one and vice-versa (in cas=
e I
>    need to rollback).
> 5. Commit
>=20
> Step 4 is what I am stuck on. What bits of the catalogue do I need to cha=
nge?
> And for what reasons?
>=20
> It may be a risky operation, as you say and I might decide not to do purs=
ue it
> in the end, but first I must understand (-:

In your steps, you carefully avoid the question of whether the foreign key =
is
valid or not.  So you are trusting the user to have made sure that everythi=
ng
is fine with the foreign key...

I may forget something, but I'd say that swapping out the files from under =
a
table's butt is just a question of updating the "pg_class.relfilenode" of t=
he
tables and the TOAST tables.  But if you just UPDATE the catalogs, concurre=
nt
statements that are using the tables will be in trouble, so you need to tak=
e
an ACCESS EXCLUSIVE lock.  Moreover, you have to make sure to send out
invalidation messages so that every session that caches statistics or
execution plans for the tables discards them.

Yours,
Laurenz Albe

--=20

*E-Mail Disclaimer*
Der Inhalt dieser E-Mail ist ausschliesslich fuer den=20
bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat=
=20
dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte,=20
dass jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder=
=20
Weitergabe des Inhalts dieser E-Mail unzulaessig ist. Wir bitten Sie, sich=
=20
in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen.

*CONFIDENTIALITY NOTICE & DISCLAIMER
*This message and any attachment are=20
confidential and may be privileged or otherwise protected from disclosure=
=20
and solely for the use of the person(s) or entity to whom it is intended.=
=20
If you have received this message in error and are not the intended=20
recipient, please notify the sender immediately and delete this message and=
=20
any attachment from your system. If you are not the intended recipient, be=
=20
advised that any use of this message is prohibited and may be unlawful, and=
=20
you must not copy this message or attachment or disclose the contents to=20
any other person.