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 1sh8xD-00DUcD-ET for pgsql-general@arkaria.postgresql.org; Thu, 22 Aug 2024 14:38:23 +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 1sh8xB-003734-IT for pgsql-general@arkaria.postgresql.org; Thu, 22 Aug 2024 14:38:22 +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 1sh8xB-00372v-7j for pgsql-general@lists.postgresql.org; Thu, 22 Aug 2024 14:38:21 +0000 Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sh8x9-000ulx-C4 for pgsql-general@postgresql.org; Thu, 22 Aug 2024 14:38:20 +0000 Received: by mail-ot1-x32d.google.com with SMTP id 46e09a7af769-7093472356dso578378a34.0 for ; Thu, 22 Aug 2024 07:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724337498; x=1724942298; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=7a9iHRpS9i+cOs0h7LiQ0/jysO2A5Q7Uqbc0x6xX6uQ=; b=JS8xlTFHGV/f/eKuVC/+/Je4QVLddhfijnEY8IcKI+9KXoY1Q1omaBFePNqesVY+0j VtxgGpiA0I3kboLGCbHnRA/jGmsjpZyiDe/623V+j9MBOFlHPT7rIbTsnxVOQ1+WJ0i3 AnxAxNBJaQiS1EGKa9nH6Al7N90i1828AON8LVMRibWmvy7FQHlxcW1GB6I5JmNoWVhB NxX/wa3Am0yu0hGOeY/WRASGbgm1NZNNGt96v2Hyx25DuXVueEBz+FZtQNm9gdJ74GA+ Dy3eYvpz3Gi2QpbibuJY9AZMzt1Zj1cf9MOXV300w8Q5t61HRNTv21jKFsohFWoP4hQp rnRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724337498; x=1724942298; h=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=7a9iHRpS9i+cOs0h7LiQ0/jysO2A5Q7Uqbc0x6xX6uQ=; b=FZNgpqOP/uhjnGKgBhFBP+EAbaznUwcAipqYC4kFfpjGdJ8AgZYJ+lm7y+xbRsovRE HR7ERPpRtXtBQeWFZ9My1CeVsCmgWkYZJyStJEdTunDBRZmLvsbcN10ZoF7NWR8DkrcW oOkfFCR/E2LngrdH/dFJJdKrWXZ7GZjEm55F6f27FwmMY5V+TowY1Sm6QJ2YWBMhmp4Z T307eMWHgOzqE2sHEGLLbhUONQj5DOKVALnL9PcZPsTRMiCH5o9LlP+fRo6b3Q1cwucB C4BufQn5M6v85mW0FUVx2McaTLeQRYBj3q52bKUky2q1Q2pc1GY0EBAPgB+jNjtx/rxn cvtA== X-Gm-Message-State: AOJu0YzkGmFW4wwulfOxUuG9bz1i0QHryuUjIPG9nk29ysr6KFFIfgpz VpT7BlU55OoqUg2M9cRJPdXXwOi7Fa7o6SViV7RpLHBuZkTbzMQrtWRJnGhe0WG6JtHXxWtfkbO nUo2/cWyyZif2VOWxcxy2IFGEz+0DFg== X-Google-Smtp-Source: AGHT+IGPqTFzu7Q93L3jBqu9YtLSHqMzt2r0Db//NQyoZYowtrBW3cwhpqEhYY0gUlmGldV5C7oKVPHOSAVVjmv1a54= X-Received: by 2002:a05:6808:16ac:b0:3d9:41fa:3f42 with SMTP id 5614622812f47-3de19cc703amr6235356b6e.22.1724337498431; Thu, 22 Aug 2024 07:38:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Thu, 22 Aug 2024 10:38:07 -0400 Message-ID: Subject: Re: How to validate restore of backup? To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000112a310620469c8f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000112a310620469c8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 22, 2024 at 9:59=E2=80=AFAM o1bigtenor w= rote: > On Thu, Aug 22, 2024 at 8:03=E2=80=AFAM Ron Johnson > wrote: > >> On Thu, Aug 22, 2024 at 8:49=E2=80=AFAM o1bigtenor wrote: >> >>> On Thu, Aug 22, 2024 at 6:24=E2=80=AFAM Ron Johnson >>> wrote: >>> >>>> That's great on small databases. Not so practical when they're big. >>>> >>>> So - - - - what is the recommended procedure for 'large' databases? >>> >>> (Might be useful to have a definition for what a large database is as >>> well.) >>> >> >> "Large" is when it takes too long to run *TWO* text mode pg_dump >> commands *in addition to* the pg_dump and pg_restore. >> >> > Hmmmmmmmmm - - - - I'd say that's about as neat a non-answer as I've ever > seen. > Eh? If you've got hundreds of hours of down time to pipe a text-mode pg_dump of a TB-sized database through md5sum. twice, then that database isn't too big. I don't have that much down time; thus, it's "too big". Can you try again? > > (You forgot the first question - - - maybe you could try that one too - - > - what is the recommended procedure > for 'large' databases?) > I already did, in my message three hours ago. --=20 Death to America, and butter sauce. Iraq lobster! --000000000000112a310620469c8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 22, 2024 at 9:59=E2=80=AFAM o= 1bigtenor <o1bigtenor@gmail.com<= /a>> wrote:
=
On Thu, Aug 22, 2024 at 8:49=E2=80=AFAM= o1bigtenor <o= 1bigtenor@gmail.com> wrote:
On Thu, Aug 22, 2024 at 6:24=E2=80=AFAM Ron Johnson <ronljohnsonjr@gmail.com&= gt; wrote:
That's great on small datab= ases.=C2=A0 Not so practical when they're big.

So - - - - what is the recommended procedure for 'large' d= atabases?

(Might be useful to have a definition fo= r what a large database is as well.)=C2=A0

"Large" is when it takes too long to run TWO= =C2=A0text mode pg_dump commands in addition to the pg_dump and = pg_restore.


Hmmmmmmmm= m - - - - I'd say that's about as neat a non-answer as I've eve= r seen.=C2=A0
=C2=A0
Eh?=C2=A0= If you've got hundreds of hours of down time to pipe a text-mode pg_du= mp of a TB-sized database through md5sum. twice, then that database isn'= ;t too big.=C2=A0 I don't have that much down time; thus, it's &quo= t;too big".

Can you try ag= ain?

(You forgot the first question - - - mayb= e you could try that one too - - - what is the recommended procedure
for 'large' databases?)

I already did, in my message three hours=C2=A0ago.

--
Death to America, a= nd butter sauce.
Iraq lobster!
--000000000000112a310620469c8f--