Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oLSIX-0000qJ-2p for pgsql-admin@arkaria.postgresql.org; Tue, 09 Aug 2022 16:41:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oLSIV-0000An-WA for pgsql-admin@arkaria.postgresql.org; Tue, 09 Aug 2022 16:41:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oLSIV-0008Ls-Gl for pgsql-admin@lists.postgresql.org; Tue, 09 Aug 2022 16:41:39 +0000 Received: from mail-oi1-x231.google.com ([2607:f8b0:4864:20::231]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oLSIT-00045k-AV for pgsql-admin@lists.postgresql.org; Tue, 09 Aug 2022 16:41:39 +0000 Received: by mail-oi1-x231.google.com with SMTP id bb16so14459121oib.11 for ; Tue, 09 Aug 2022 09:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc; bh=ytqbgnL8SuI8Q9cPls5yq82GyxBy3YcLj7e9fe9wqlI=; b=lZ4AGGx9RTXBrpMjKvq3Dk6VEQuCQjeGf99ChnqD5H4NGBJCdRRJa6pr9OzSBlEDXK eFjv7Xsk9nH/qFsR7AKaRVsndYUJz2KplNvw7EaU1fCR9P/Unyk3BxOQe2/rYAajGaSv NB/Q1o8ozV4EgeaV1+b7GKYvPUq7Vu1rV8a3A5rOusILIDm1f9fRZe4L3GoQOnl9QPaW Cy+Xv9DChUp8Yzy8RoaeJRuO5ePcu+AnwLgd3Q+Fg/z3JhUwtn1FwFWQbSTvj6g/mrDn I9WNJq3oVPH7pIKJBJV7YFrKoEUrGHy0rbV4BDiC/BS/lEMWwO/aERzXmcKgnnsQU3Oy AAtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc; bh=ytqbgnL8SuI8Q9cPls5yq82GyxBy3YcLj7e9fe9wqlI=; b=cq5tHGh5aoR5/Hy90TxAVxBMfExW7grC+yra1viBWfHmm6DbOYcmXJM9qr4FDJXvt0 Q8NX/w7hwJHpiRDy8vyYJPHfxb9jb3KuKVnGO372B+UFCeK40anv4FhxwuP1tcqKmCje oDQ5cbAruBMVrNYIK/CW8RZI24EYwwTCsDu1TF1QgGqSLruuI3KFAYWLVW/wI9LvV0wP Uu2hZXqc/7ON275EPPDUBjUpekG7Y9flldXNQdtpBJtAWONazfpGNavSTC11nU+Skqu0 Miu5UvkcPh1IAEgBNQT8UDOb33Glv69epMAnMqN40Kq65a34KQIiat0JRhwrbrVifiWW PkUw== X-Gm-Message-State: ACgBeo2RncyPQU2qEqRt1EKVvnu6Mq23MH8wqplCysTnh5HWUaVasf3Y ySEfeTpGAv2EevvH2Gq1m/953vgF7mA= X-Google-Smtp-Source: AA6agR5lRJgg/5if+PzJEpFoJRZrmHQmWBiRL83vMyJEwqIpnEUKFEW3rpptwLOHtjAEt+lcfdvQ4Q== X-Received: by 2002:aca:a913:0:b0:343:fe9:951a with SMTP id s19-20020acaa913000000b003430fe9951amr1720865oie.94.1660063294774; Tue, 09 Aug 2022 09:41:34 -0700 (PDT) Received: from [192.168.88.10] (ip68-11-68-85.no.no.cox.net. [68.11.68.85]) by smtp.googlemail.com with ESMTPSA id w41-20020a05687033a900b0010efb044e37sm3200748oae.27.2022.08.09.09.41.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Aug 2022 09:41:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------yYpTDcn2G7bLu69Nthml0nMV" Message-ID: <93797605-23dc-de94-d49e-0849475ad426@gmail.com> Date: Tue, 9 Aug 2022 11:41:33 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: How to fully restore a single table from a custom dump? Content-Language: en-US To: pgsql-admin@lists.postgresql.org References: <1622540476.1110533.1660049347030@email.ionos.com> <9ca2d8ca-a175-630e-e449-48c2dee5e0f6@jakobs.com> From: Ron In-Reply-To: <9ca2d8ca-a175-630e-e449-48c2dee5e0f6@jakobs.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------yYpTDcn2G7bLu69Nthml0nMV Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/9/22 08:21, Holger Jakobs wrote: > Am 09.08.22 um 14:49 schrieb MichaelDBA Vitale: >> Hi, >> If you use the directory dump method, -Fd, then you could generate an >> editable listing where you can selectively remove stuff that you don't >> want to restore, just keeping the stuff related to your specific table.  >>  You run pg_restore once to generate the listing. Then run pg_restore >> again using that modified listing to load into the target database. See >> the pg_restore docs for exact syntax. >> Regards, >> Michael Vitale >>> On 08/09/2022 8:06 AM EDT Thomas Kellerer wrote: >>> Hello, >>> I just realized that using >>> pg_restore -t some_table ... some_dump_file >>> doesn't restore things like identity attributes >>> or indexes on the specified table. >>> The dump contains much more than just that table, so simply >>> using pg_restore without -t is not an option. >>> While I could extract the indexes manually using some clever regex >>> on the index names, I don't see a way to make sure that identity >>> definitions (or sequence values) are restored properly for the selected >>> table. >>> Any ideas, how I can _fully_ restore a single table from a custom dump? >>> Thomas > > Creating a list of contained items and restoring some of them works the > same with custom dumps. Directory dumps have no advantage here. > > Just comment out all items you don't want to restore by putting a ; in > front of the lines or delete the unwanted lines altogether and restore. > Which is less than convenient when there's 4000 tables, and each one has 3 or four indices, a Primary Key and one or more Foreign Keys. -- Angular momentum makes the world go 'round. --------------yYpTDcn2G7bLu69Nthml0nMV Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/9/22 08:21, Holger Jakobs wrote:
Am 09.08.22 um 14:49 schrieb MichaelDBA Vitale:
Hi,
If you use the directory dump method, -Fd, then you could generate an editable listing where you can selectively remove stuff that you don't want to restore, just keeping the stuff related to your specific table.   You run pg_restore once to generate the listing.  Then run pg_restore again using that modified listing to load into the target database. See the pg_restore docs for exact syntax.
 
Regards,
Michael Vitale
 
On 08/09/2022 8:06 AM EDT Thomas Kellerer <shammat@gmx.net> wrote:
 
 
Hello,
 
I just realized that using
 
pg_restore -t some_table ... some_dump_file
 
doesn't restore things like identity attributes
or indexes on the specified table.
 
The dump contains much more than just that table, so simply
using pg_restore without -t is not an option.
 
While I could extract the indexes manually using some clever regex
on the index names, I don't see a way to make sure that identity
definitions (or sequence values) are restored properly for the selected table.
 
Any ideas, how I can _fully_ restore a single table from a custom dump?
 
Thomas

Creating a list of contained items and restoring some of them works the same with custom dumps. Directory dumps have no advantage here.

Just comment out all items you don't want to restore by putting a ; in front of the lines or delete the unwanted lines altogether and restore.


Which is less than convenient when there's 4000 tables, and each one has 3 or four indices, a Primary Key and one or more Foreign Keys.

--
Angular momentum makes the world go 'round.
--------------yYpTDcn2G7bLu69Nthml0nMV--