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 1rps7r-009BWn-Ir for pgsql-general@arkaria.postgresql.org; Thu, 28 Mar 2024 15:57:12 +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 1rps7q-00GZM5-1S for pgsql-general@arkaria.postgresql.org; Thu, 28 Mar 2024 15:57:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rps7p-00GZLw-LM for pgsql-general@lists.postgresql.org; Thu, 28 Mar 2024 15:57:09 +0000 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rps7m-0071Gz-H2 for pgsql-general@lists.postgresql.org; Thu, 28 Mar 2024 15:57:09 +0000 Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-33ececeb19eso627169f8f.3 for ; Thu, 28 Mar 2024 08:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711641425; x=1712246225; darn=lists.postgresql.org; h=mime-version:subject:user-agent:references:in-reply-to:message-id :date:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=iNCu2KbfhECd0mvCv4bZ+UvqtweuN2ZPKudWwFAW0nU=; b=QTkQLDPDJ2uI34McfyOlUEYa1dG0aTU+JwZ5uoDI71nviEa9IkBtyfRsrUzMhJ6Opi i5+mFMnelk6/LEPApcoba/SPm/lproA5ux1PFnTJOm4+4c8P9AjNiZWUKDW01tYqKw1E to8WhfN8tdVAipDxIemA8SyjLw8svjR9AAGZpg+bMVOnqdeY+XaZbwNt8f5RjvQqVTHF 2Llbg9FGp5Fp4EJIRl+R7ZRMS3RTQrypu00exxdSMJPQ1k9BinvQVdcuoO1G1TeE3m7S 96ric3EXUx2PIKL75pszc83IjWlDmUNTEY1OxT+OemFP85zpgKyhj0w8MVIraU18NHHy Rx5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711641425; x=1712246225; h=mime-version:subject:user-agent:references:in-reply-to:message-id :date:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=iNCu2KbfhECd0mvCv4bZ+UvqtweuN2ZPKudWwFAW0nU=; b=h/bXH6aNWO5BB1XnQUsu4r96hxADyPXLBvxFFAqVxftJnO6KaTN8igdx4UYz2xwQ5q rM5S3FxXHiSIZh/0uTcCW4041U4oQwxfYaXadJ2wX0F24tKppYIufaCZxMYzRAYnh3qf RADNXmN751sLu0C008O7DwgqhPiFdAcWvM4k4osGnMQjQz5MrUEqpuudU3AHMGFJtrym tlQLqKiKSPIGU0rGHnyPkHXBFBL9XGJq+hs1s6DN/XTn3AD6FDKLyerf04Hxkm450oGH QDSPnsRzyO3LzQUCU8W/y6EkSEOo7LTXOHVYfwecjYfo8UpvAw71DVC4UUUjOFRBueIG n+lg== X-Gm-Message-State: AOJu0YyhUHpFiAId4pgi96VA7k2S/k5YM359venJKkbIb8+a9LRY7lB3 THCtus/tnRfB9D89XKG2cczmD25MJsVpyitqzu0Ljqrr26qnZcYzds9wjOr25is= X-Google-Smtp-Source: AGHT+IHzaoZc7ZLeJXJmUcHFVBmNOVMyynZdN1+PBUwxgsAOVgWvX03KOxAP9lyvuNlCfmCbgpJ5Tw== X-Received: by 2002:a05:6000:4023:b0:33e:c271:8ca3 with SMTP id cp35-20020a056000402300b0033ec2718ca3mr3053079wrb.10.1711641425005; Thu, 28 Mar 2024 08:57:05 -0700 (PDT) Received: from [10.152.178.235] (dynamic-176-007-168-178.176.7.pool.telefonica.de. [176.7.168.178]) by smtp.gmail.com with ESMTPSA id dn13-20020a0560000c0d00b00341b7d5054bsm2079402wrb.72.2024.03.28.08.57.04 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 28 Mar 2024 08:57:04 -0700 (PDT) From: Fire Emerald To: Tom Lane CC: Date: Thu, 28 Mar 2024 16:57:04 +0100 Message-ID: <18e85c76c98.2815.a5aef60df33e8d2ac3d54c6545825f63@gmail.com> In-Reply-To: <3571436.1711634406@sss.pgh.pa.us> References: <18e84674c10.2815.a5aef60df33e8d2ac3d54c6545825f63@gmail.com> <3571436.1711634406@sss.pgh.pa.us> User-Agent: AquaMail/1.50.0 (build: 105000429) Subject: Re: How to interpret 'depends on' errors in pg_restore? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="18e85c770976a2e2815da1f857" 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. --18e85c770976a2e2815da1f857 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Am 28. März 2024 15:00:06 schrieb Tom Lane : > Fire Emerald writes: >> Then i did a pg_restore -d target --verbose -Fc file.dump and saw in the >> output this: > >> 5145 0 730750 TABLE subpartitions backends_y2024w03 userA >> ; depends on: 237 >> .... and so on ... > > That is not an error, it's just verbose display of one of the items > in the dump. Well, I know it's not an error, but it's everything i got. There was no error shown. The command completed, but without anything imported. > >> Nothing was restored. > > You would need to show us the actual errors. (Suggestion: > leave off --verbose, it's just clutter.) A guess though is > that the import failed because of foreign key constraints. > --data-only mode is not good at ordering the table loads to > ensure that FK constraints are satisfied on-the-fly. > > regards, tom lane As i said, the same import but with INSERT INTOs worked without any issues. So no, there are no FK constraints failing. But the target and source table had partitioned tables attached, using ATTACH PARTITION. The schema was like: db1 schema1 public table1 (links to the listed below) db1 schema1 subpartitions backends_y2024w03 db1 schema1 subpartitions backends_y2024w04 db1 schema1 subpartitions backends_y2024w05 The partitioning must be the problem somehow. --18e85c770976a2e2815da1f857 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Am 28. M=C3=A4rz 2024 15= :00:06 schrieb Tom Lane <tgl@sss.pgh.pa.us>:

Fire Emerald <fire.github@gmail.com> writes:
Then i did a pg_restore -d target --verbose -Fc file.dump= and saw in the 
output this:

5145 0 730750 TABLE subpartitions backends_y2024w03 userA=
;        depends on: 237
.... and so on ...

That is not an error, it's just verbose display of one of= the items
in the dump.
Well, I know it's not an error, but it's everythi= ng i got. There was no error shown. The command completed, but without anyt= hing imported.

Nothing was restored.

You would need to show us the actual errors.  (Sugge= stion:
leave off --verbose, it's just clutter.)  A guess th= ough is
that the import failed because of foreign key constraints= .
--data-only mode is not good at ordering the table loads = to
ensure that FK constraints are satisfied on-the-fly.

 =09=09regards, tom lane

As i said, the same imp= ort but with INSERT INTOs worked without any issues. So no, there are no FK= constraints failing.

But the target and source table had partitioned tables attached, using= ATTACH PARTITION.

The s= chema was like:
db1 schema1 public table1 (links to = the listed below)
db1 schema1 subpartitions backends= _y2024w03
db1 schema1 subpartitions backends_y2024w0= 4
db1 schema1 subpartitions backends_y2024w05
<= div dir=3D"auto">
The partitioning must be the p= roblem somehow.
--18e85c770976a2e2815da1f857--