Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tiiBi-001RkU-7m for pgsql-general@arkaria.postgresql.org; Thu, 13 Feb 2025 23:00:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tiiBg-00Flrj-1E for pgsql-general@arkaria.postgresql.org; Thu, 13 Feb 2025 23:00:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tiiBf-00Flrb-MY for pgsql-general@lists.postgresql.org; Thu, 13 Feb 2025 23:00:04 +0000 Received: from mail-io1-xd43.google.com ([2607:f8b0:4864:20::d43]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tiiBe-000f9C-1z for pgsql-general@lists.postgresql.org; Thu, 13 Feb 2025 23:00:03 +0000 Received: by mail-io1-xd43.google.com with SMTP id ca18e2360f4ac-852050432a8so36352439f.1 for ; Thu, 13 Feb 2025 15:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739487602; x=1740092402; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=aYUR81NudEvFC91NpaJw/feXh0bOgGfKY32HH0bSBFA=; b=aggAKsVbmntnot7EBrdIQhrgaaA8nkN9WtPLdd5ff+hY3imNDLUQOtCZjoypajD/7w wGtwrvacVp9/yCPbwDUWdxgcxES78uU9yKO1RrAMr83who80GgsS6JN9aMOZYPHRpgjE zkDiRAEgdABFUWYjef02VYrp7t/bfpByxU7S1xk5wqlQVZj6oHJGiwwIR4fi2jRGynjL 2CZRea/F5TJWT0SdnB8N8I+xsdjXPcRXpNohuc1crrBLbKWzoWQDTebBvN3oJ1BAJLGP SOeKgufzh7/yBUnQxMakguZ6QWTj8R9eFWJuOBmN/n/t6FSN3cYrzY+FCpLsIfnJXf1N TzcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739487602; x=1740092402; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aYUR81NudEvFC91NpaJw/feXh0bOgGfKY32HH0bSBFA=; b=eEjO7oxEmJ7GOFbOFcmOKmXXeM/sxWJNjxjpOD1D0PTKi59DYpw+06mW/vGQ1F4lWi f7hJXDkC+LQ83cMf55+1fw2ddR0l5NPNaNmEWDOJyzMbVhPfrjT0snp7XyEQzIwHpTnL zdS25fqgwzZ9C287CTucMVe6PrDHa0c/XXAAeZc9eWc0RemkjZHR3o7+aXsy5FLt+VYw XMTkzMfxLYd3DMIh9yT7hR7ZVoEfuLEtzJTHgS5uAj+KTOy4onfD5Dzi0Q4v54pPyZWj xBdq1lj4UQ1Pv50H8oPK/y2RwYqW9Xr+l6jNS6rR5iJectowwg0bxBB/3jQnd+qeyRb+ 9tJw== X-Forwarded-Encrypted: i=1; AJvYcCVs/sCZUKURY0Rc1VdILOgnLVKKLkGKPUyvyomssluLuy3M+jBKRPCqvCz7oASJqhuxAbjZOU63v2sDM0YQ@lists.postgresql.org X-Gm-Message-State: AOJu0YwmJy7aRKKruLXhwKF4CyHDE6qlHwBh06ehMCNuGQIs5QOwtigy CZsTYTV3b81jZmDIMxEDlr9iYWV5/czwXjFVmrrjsrqFRLaxZMqs3d+MRKEyTske2+O4siuesYw N9/kCoQUgfruP4WPYLBiplHDJ4Is= X-Gm-Gg: ASbGncsoO7qVu41kmwvpYpMD2bc0MJsm2rWjJt4pUbDj6DwAvzDy8bxuUk5gEhXiV1l R9TvnScJzpJW3UD5p5xtJqgVXuoNTJ/mW9v029quvBfnqjOuHWe36rVak8MepCANsFuAec8AJ X-Google-Smtp-Source: AGHT+IFRY9KseVaLFegdnx2/SGc/4C3xaUetCv1k5ZSyjRGp5GSTBTFsGrkq7F6LAM9daXHvp+3bW/dBs7vTuPzSU+Y= X-Received: by 2002:a5e:8f41:0:b0:841:ab27:acac with SMTP id ca18e2360f4ac-855651b8463mr341461639f.2.1739487601751; Thu, 13 Feb 2025 15:00:01 -0800 (PST) MIME-Version: 1.0 References: <8ac6a1dd-db82-4ea7-8186-0c354d79049f@aklaver.com> <9fa75099-1ee9-43de-ac6e-945841b184eb@aklaver.com> <22406cdf-83f5-4b98-b07e-7827afe97f93@aklaver.com> <94e1205e-8ddf-403b-8477-02d7939f2905@aklaver.com> In-Reply-To: <94e1205e-8ddf-403b-8477-02d7939f2905@aklaver.com> From: Marcelo Fernandes Date: Fri, 14 Feb 2025 11:59:50 +1300 X-Gm-Features: AWEUYZnvgI9uXkErlTAxeD9ZpEv9tNiuUxOjIpo720m_6yx6rXK6a68l0gtGPUQ Message-ID: Subject: Re: Best Approach for Swapping a Table with its Copy To: Adrian Klaver Cc: Dominique Devienne , Greg Sabino Mullane , pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Feb 13, 2025 at 7:37=E2=80=AFPM Laurenz Albe wrote: > Yes, but only if you are willing to write C code that runs inside the > database server. That way, you can do anything (and cause arbitrary > damage). > > 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? Exactly! This is part of what I am trying to figure out (-: The plan that I have in mind so far to swap a table safely is: 1. Run the following query to grab information about the toast and the toas= t index of the tables involved in the swapping: 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; 2. Open a transaction and acquire an access exclusive lock. 3. Ensure that the cloned table has the same owner as the original table ALTER TABLE copy_table OWNER TO owner_of_the_original_table; 4. Now I need to swap all the data in the catalogue tables that point to th= e old table and the toast to point to the new one and vice-versa (in case = I need to rollback). 5. Commit Step 4 is what I am stuck on. What bits of the catalogue do I need to chang= e? And for what reasons? It may be a risky operation, as you say and I might decide not to do pursue= it in the end, but first I must understand (-: Regards, - Marcelo