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 1uzSOA-003fMe-7t for pgsql-general@arkaria.postgresql.org; Fri, 19 Sep 2025 04:06:26 +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 1uzSO8-003uwq-RY for pgsql-general@arkaria.postgresql.org; Fri, 19 Sep 2025 04:06:24 +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 1uzSO8-003uvY-8A for pgsql-general@lists.postgresql.org; Fri, 19 Sep 2025 04:06:24 +0000 Received: from mail-oa1-x2f.google.com ([2001:4860:4864:20::2f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uzSO5-001Cbt-2P for pgsql-general@postgresql.org; Fri, 19 Sep 2025 04:06:23 +0000 Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-32bd4f1b671so1759285fac.0 for ; Thu, 18 Sep 2025 21:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758254781; x=1758859581; 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=Nod0v4vAjLIYiMH0OQ3FvEITLUyn2KcqOqgLuAoG6g4=; b=eDwKqH4Be7rTD0oJD9AlzxjGhFCKwlBbVdHegOy3I0H4eKZ8FMHUk4hidiB+bhX8qL nGbWy0CfIugDFNoLIo9hnjJYn0N1uJZwuL9KpdD4L6kdkkMZd1LxevpQd3TPpQGhZLD0 CBeT89mImjCf6XZO44iVtvIV656gBSW1ep1chjEboWMStdNAmYV+ixxLcGCCCEubLXZR 9Gqd5bPIHqR3FBgLEeAqEbEfP7oKv/0ZQg0uZOCmOtMWALqCtBi5SmDr+wvXS380RE5D NXKhGoiTM7QFMP5miXBxq1eyKbpV+q8s/P8OsIr8PJi9zDbVO6X6hBgcorGUA0S8kkji UOeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758254781; x=1758859581; 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=Nod0v4vAjLIYiMH0OQ3FvEITLUyn2KcqOqgLuAoG6g4=; b=coP6hfAdOL6cypblRXohMsBzWxRUuky5PdCyJAQeNjBcNsjTSioSC22u3ytn5BYHas V0uYUoDA6mWqTBPCNuX+Y2JmDb/699jLcQJavroNGyppiAoM+PRN8rSZpSROwM0om79H UkOQo+C6pweNMfhsGKgMKei7pBbpDNK/Hirp1w4p98JxBH9nYEH1TSTmJQNWLPEO3AWk Gv6c2CuQkbpYwx2OB6GKT5AHqrPcwfFbg+aOokr76NNHs4jd7VgH7p3ca6F1vLU/ioDP FJ3ffWjelNkZSEa9RQ8V0/j0FbYJ2cY6Aywl9Ta6U5FK8n0pBuMUbxIKQrw1vlS4tXxZ OFXA== X-Gm-Message-State: AOJu0YyEDFeFonakhKRs5Zeu4+jW92jmky94z8KpNIos1piOGx7hTq/G lLYxoripJeLQ7DVm9n+ivwSMPZpXK8biL2kbJByIhQZ99+xrqEh7lsO+EbemfR5+BzlJ7n09k4r tnCrdWax31ZFR3HApOTVTKyCzlPJoBjb+Ew== X-Gm-Gg: ASbGncslETCh0PUif0SMOFtPKNAHn4tZarrFrivM01wP/DCwOPrHrtz9mQJQApJc6J7 ID/q9QQDkJVwNmo3oYySfhDu7bdNpG7q7VIOhbJgVNok7LH3zvPwxh+fdJpGEnqYps1lHiDCBFI 5IcwiHsGDwjDAiWYpfFMwDOi26dPrpucw+SvORQjhkcDohR5HycNhBwf4d1OgE1dTxPYm1WeaCa bAnEZYB X-Google-Smtp-Source: AGHT+IGU1eEe2MAMhpOKLVur3Mt8L+dZNnjD3tQCLgYgRF34Z3Wok2RZ8op/D2eSRpZxVTnr/BF4HDd0xGsVrNbYf88= X-Received: by 2002:a05:6870:8608:b0:31d:8552:85eb with SMTP id 586e51a60fabf-33bb69fa696mr1116869fac.24.1758254781145; Thu, 18 Sep 2025 21:06:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Fri, 19 Sep 2025 00:06:09 -0400 X-Gm-Features: AS18NWAQqd9iPN3MGu52TwR7oYitp7a7oNGmqHSR7Lj3KdRxBuPetkpfbpfixSs Message-ID: Subject: Re: pg_restore scan To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000a7a708063f1f97c1" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a7a708063f1f97c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 18, 2025 at 5:37=E2=80=AFPM R Wahyudi wrot= e: > I've been given a database dump file daily and I've been asked to restore > it. > I tried everything I could to speed up the process, including using -j 40= . > > I discovered that at the later stage of the restore process, the > following behaviour repeated a few times : > 40 x pg_restore process doing 100% CPU > Threads are not magic. IO and memory limitations still exist. > 40 x postgres process doing COPY but using 0% CPU > ..... and zero disk write activity > > I don't see this behaviour when restoring the database that was dumped > with -Fd. > Also with an un-piped backup file, I can restore a specific table without > having to wait for hours. > We explained this three days ago. Heck, it's in this very email. Click on "the three dots", scroll down a bit. > On Fri, 19 Sept 2025 at 01:54, Adrian Klaver > wrote: > >> On 9/18/25 05:58, R Wahyudi wrote: >> > Hi All, >> > >> > Thanks for the quick and accurate response! I never been so happy >> > seeing IOwait on my system! >> >> Because? >> >> What did you find? >> >> > >> > I might be blind as I can't find information about 'offset' in pg_dum= p >> > documentation. >> > Where can I find more info about this? >> >> It is not in the user documentation. >> >> From the thread Ron referred to, there is an explanation here: >> >> https://www.postgresql.org/message-id/366773.1756749256%40sss.pgh.pa.us >> >> I believe the actual code, for the -Fc format, is in pg_backup_custom.c >> here: >> >> >> https://github.com/postgres/postgres/blob/master/src/bin/pg_dump/pg_back= up_custom.c#L723 >> >> Per comment at line 755: >> >> " >> If possible, re-write the TOC in order to update the data offset >> information. This is not essential, as pg_restore can cope in most >> cases without it; but it can make pg_restore significantly faster >> in some situations (especially parallel restore). We can skip this >> step if we're not dumping any data; there are no offsets to update >> in that case. >> " >> >> > >> > Regards, >> > Rianto >> > >> > On Wed, 17 Sept 2025 at 13:48, Ron Johnson > > > wrote: >> > >> > >> > PG 17 has integrated zstd compression, while --format=3Ddirectory = lets >> > you do multi-threaded dumps. That's much faster than a single- >> > threaded pg_dump into a multi-threaded compression program. >> > >> > (If for _Reasons_ you require a single-file backup, then tar the >> > directory of compressed files using the --remove-files option.) >> > >> > On Tue, Sep 16, 2025 at 10:50=E2=80=AFPM R Wahyudi > > > wrote: >> > >> > Sorry for not including the full command - yes , its piping to= a >> > compression command : >> > | lbzip2 -n --best > >> >> > >> > >> > I think we found the issue! I'll do further testing and see ho= w >> > it goes ! >> > >> > >> > >> > >> > >> > On Wed, 17 Sept 2025 at 11:02, Ron Johnson >> > > >> wrote: >> > >> > So, piping or redirecting to a file? If so, then that's t= he >> > problem. >> > >> > pg_dump directly to a file puts file offsets in the TOC. >> > >> > This how I do custom dumps: >> > cd $BackupDir >> > pg_dump -Fc --compress=3Dzstd:long -v -d${db} -f ${db}.dum= p >> > 2> ${db}.log >> > >> > On Tue, Sep 16, 2025 at 8:54=E2=80=AFPM R Wahyudi >> > > wrote: >> > >> > pg_dump was done using the following command : >> > pg_dump -Fc -Z 0 -h -U -w -d >> > >> > On Wed, 17 Sept 2025 at 08:36, Adrian Klaver >> > > > > wrote: >> > >> > On 9/16/25 15:25, R Wahyudi wrote: >> > > >> > > I'm trying to troubleshoot the slowness issue >> > with pg_restore and >> > > stumbled across a recent post about pg_restore >> > scanning the whole file : >> > > >> > > > "scanning happens in a very inefficient way, >> > with many seek calls and >> > > small block reads. Try strace to see them. This >> > initial phase can take >> > > hours in a huge dump file, before even starting >> > any actual restoration." >> > > see : https://www.postgresql.org/message-id/ >> > E48B611D-7D61-4575-A820- > > >> www.postgresql.org/message-id/E48B611D-7D61-4575-A820-> >> > > B2C3EC2E0551%40gmx.net >> > > > www.postgresql.org/message-id/> >> > > E48B611D-7D61-4575-A820-B2C3EC2E0551%40gmx.net >> > > >> > >> > This was for pg_dump output that was streamed to a >> > Borg archive and as >> > result had no object offsets in the TOC. >> > >> > How are you doing your pg_dump? >> > >> > >> > >> > -- >> > Adrian Klaver >> > adrian.klaver@aklaver.com >> > >> > >> > >> > >> > -- >> > Death to , and butter sauce. >> > Don't boil me, I'm still alive. >> > lobster! >> > >> > >> > >> > -- >> > Death to , and butter sauce. >> > Don't boil me, I'm still alive. >> > lobster! >> > >> >> >> -- >> Adrian Klaver >> adrian.klaver@aklaver.com >> > --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000a7a708063f1f97c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 18, 2025 at 5:37=E2=80=AFPM R= Wahyudi <rwahyudi@gmail.com&g= t; wrote:
I've bee= n given a database dump file daily and I've been asked to restore it.= =C2=A0
I tried everything I could to speed up the process, incl= uding using -j 40.=C2=A0

I discovered that at = the later stage of the restore process,=C2=A0 the following=C2=A0behaviour = repeated a few times :=C2=A0
40 x pg_restore process doing 100%= CPU

Threads are not magic.=C2= =A0 IO and memory limitations still=C2=A0exist.
=C2=A0
40 x= =C2=A0 postgres process doing COPY but using 0% CPU=C2=A0
...= .. and zero disk write activity

I don't se= e this behaviour when restoring the database that was dumped with -Fd.
Also with an un-piped backup file, I can restore a specific table w= ithout having to wait for hours.=C2=A0

We explained this three days ago.=C2=A0 Heck, it's in this very= email.=C2=A0 =C2=A0Click on "the three dots", scroll down a bit.=
=C2=A0
On Fri, 19 S= ept 2025 at 01:54, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
=
On 9/18/25 05:58, R Wahyu= di wrote:
> Hi All,
>
> Thanks for the quick and accurate response!=C2=A0 I never been so happ= y
> seeing IOwait on my system!

Because?

What did you find?

>
> I might be blind as=C2=A0 I can't find information about 'offs= et' in pg_dump
> documentation.
> Where can I find more info about this?

It is not in the user documentation.

=C2=A0From the thread Ron referred to, there is an explanation here:

https://www.postgresql.org/me= ssage-id/366773.1756749256%40sss.pgh.pa.us

I believe the actual code, for the -Fc format, is in pg_backup_custom.c here:

https://gith= ub.com/postgres/postgres/blob/master/src/bin/pg_dump/pg_backup_custom.c#L72= 3

Per comment at line 755:

"
=C2=A0 If possible, re-write the TOC in order to update the data offset information.=C2=A0 This is not essential, as pg_restore can cope in most cases without it; but it can make pg_restore significantly faster
in some situations (especially parallel restore).=C2=A0 We can skip this step if we're not dumping any data; there are no offsets to update
in that case.
"

>
> Regards,
> Rianto
>
> On Wed, 17 Sept 2025 at 13:48, Ron Johnson <ronljohnsonjr@gmail.com
> <mailto:ronljohnsonjr@gmail.com>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0PG 17 has integrated zstd compression, while --form= at=3Ddirectory lets
>=C2=A0 =C2=A0 =C2=A0you do multi-threaded dumps.=C2=A0 That's much = faster than a single-
>=C2=A0 =C2=A0 =C2=A0threaded pg_dump into a multi-threaded compression = program.
>
>=C2=A0 =C2=A0 =C2=A0(If for _Reasons_ you require a single-file backup,= then tar the
>=C2=A0 =C2=A0 =C2=A0directory of compressed files using the=C2=A0--remo= ve-files option.)
>
>=C2=A0 =C2=A0 =C2=A0On Tue, Sep 16, 2025 at 10:50=E2=80=AFPM R Wahyudi = <rwahyudi@gmail.= com
>=C2=A0 =C2=A0 =C2=A0<mailto:rwahyudi@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sorry for not including the full comm= and - yes , its piping to a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compression command :
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| lbzip2 -n <threadsforbzip= goeshere>--best > <filenamegoeshere>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think=C2=A0we found the issue! I= 9;ll do further testing and see how
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it goes !
>
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, 17 Sept 2025 at 11:02, Ron Jo= hnson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ronljohnsonjr@gmail.com <mailto:ronljohnsonjr@gmail.c= om>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So, piping or redirecti= ng to a file?=C2=A0 If so, then that's the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0problem.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pg_dump directly to a f= ile puts file offsets in the TOC.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This how I do custom du= mps:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cd $BackupDir
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pg_dump -Fc --compress= =3Dzstd:long -v -d${db} -f ${db}.dump
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02> ${db}.log<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Sep 16, 2025 at= 8:54=E2=80=AFPM R Wahyudi
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<rwahyudi@gmail.com <mailto:rwahyudi@gmail.com&= gt;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pg_dump w= as done using the following command :
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pg_dump -= Fc -Z 0 -h <host> -U <user> -w -d <database>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, 1= 7 Sept 2025 at 08:36, Adrian Klaver
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<adrian.klaver@akl= aver.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailt= o:adrian.kla= ver@aklaver.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0On 9/16/25 15:25, R Wahyudi wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 > I'm trying to troubleshoot the slowness issue
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0with pg_restore and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 > stumbled across a recent post about pg_restore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0scanning the whole file :
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 >=C2=A0 > "scanning happens in a very inefficient way, >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0with many seek calls and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 > small block reads. Try strace to see them. This
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0initial phase can take
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 > hours in a huge dump file, before even starting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0any actual restoration."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 > see : https://www.postgresql.org/message-id/ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0E48B611D-7D61-4575-A820- <https://
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0www.postgresql.org/message-id/E48= B611D-7D61-4575-A820->
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 > B2C3EC2E0551%40gmx.net <http://40gmx.net>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<https://www.postgresql.org/message-id/ <https= ://
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0www.postgresql.org/message-id/>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 > E48B611D-7D61-4575-A820-B2C3EC2E0551%40gmx.net
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://40gmx.net>>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0This was for pg_dump output that was streamed to a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Borg archive and as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0result had no object offsets in the TOC.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0How are you doing your pg_dump?
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0--
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Adrian Klaver
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0adrian= .klaver@aklaver.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<mailto:adrian.klaver@aklaver.com>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Death to <Redacted&g= t;, and butter sauce.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Don't boil me, I= 9;m still alive.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<Redacted> lobste= r!
>
>
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Death to <Redacted>, and butter sauce.
>=C2=A0 =C2=A0 =C2=A0Don't boil me, I'm still alive.
>=C2=A0 =C2=A0 =C2=A0<Redacted> lobster!
>


--
Adrian Klaver
adrian.klave= r@aklaver.com


--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000a7a708063f1f97c1--