From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Jonathan S. Katz" <jkatz@postgresql.org>
cc: Robert Haas <robertmhaas@gmail.com>, Noah Misch <noah@leadboat.com>,
        Andrew Dunstan <andrew@dunslane.net>,
 Bruce Momjian <bruce@momjian.us>,
        Michael Paquier <michael@paquier.xyz>,
        Justin Pryzby <pryzby@telsasoft.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
        Shruthi Gowda <gowdashru@gmail.com>
Subject: Re: pg15b2: large objects lost on upgrade
In-reply-to: <c07d096c-a67a-9fb9-2001-7a97b36aa5a7@postgresql.org>
References: <YuCQQtF2p3qWs7t+@momjian.us>
 <CA+Tgmob6_NTj-euMShhcnAB_=CnkRO7-UgXVfWs4fACuDk8uAA@mail.gmail.com>
 <3901843.1659116952@sss.pgh.pa.us>
 <CA+TgmobzCRWG=_Tf0VXvF26pZbTxV-CKPNx6RdoWonKPETLvyQ@mail.gmail.com>
 <CA+TgmoYKVbB9rt2UAvaFLG-qYCgRuhAr7wPLDwTT0VpbPKvj_w@mail.gmail.com>
 <CA+TgmoZiBP2OD9POF0R2L=fib4ueOUusSVzmnO0_+kNzqSpnKw@mail.gmail.com>
 <4152163.1659124804@sss.pgh.pa.us>
 <CA+TgmoY=MfT2uc=N!4sAcHf3_teqYBNtmqVrVYv5oEK=4RfxATw@mail.gmail.com>
 <CA+TgmoZX6Zz4KU2enOYyc+aQWA+S5ZaZRGo6BgxW7mNF4btqaw@mail.gmail.com>
 <125444.1659136594@sss.pgh.pa.us> <20220730054401.GB3644221@rfd.leadboat.com>
 <351616.1659192034@sss.pgh.pa.us>
 <635c8809-3525-7dae-a1a1-0d9069cd86bc@postgresql.org>
 <2657259.1659460333@sss.pgh.pa.us>
 <CA+TgmoastyZUAmJ6t953=yycQxu_S0x6A08QVARsbOVAWW=D2A@mail.gmail.com>
 <c07d096c-a67a-9fb9-2001-7a97b36aa5a7@postgresql.org>
Comments: In-reply-to "Jonathan S. Katz" <jkatz@postgresql.org>
	message dated "Tue, 02 Aug 2022 15:27:49 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2686053.1659469199.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 02 Aug 2022 15:39:59 -0400
Message-ID: <2686054.1659469199@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2686054.1659469199%40sss.pgh.pa.us>
Precedence: bulk

"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 8/2/22 3:23 PM, Robert Haas wrote:
>> I'm not quite sure how to rule that theory in or out, though.

> Without overcomplicating this, are we able to check to see if autovacuum=
 =

> ran during the course of the test?

Looks like we're all thinking along the same lines.

grassquit shows this at the end of the old server's log,
immediately after the query to retrieve the old horizons:

2022-08-01 19:33:41.608 UTC [1487114][postmaster][:0] LOG:  received fast =
shutdown request
2022-08-01 19:33:41.611 UTC [1487114][postmaster][:0] LOG:  aborting any a=
ctive transactions
2022-08-01 19:33:41.643 UTC [1487114][postmaster][:0] LOG:  background wor=
ker "logical replication launcher" (PID 1487132) exited with exit code 1
2022-08-01 19:33:41.643 UTC [1493875][autovacuum worker][5/6398:0] FATAL: =
 terminating autovacuum process due to administrator command
2022-08-01 19:33:41.932 UTC [1487121][checkpointer][:0] LOG:  checkpoint c=
omplete: wrote 1568 buffers (9.6%); 0 WAL file(s) added, 0 removed, 33 rec=
ycled; write=3D31.470 s, sync=3D0.156 s, total=3D31.711 s; sync files=3D89=
3, longest=3D0.002 s, average=3D0.001 s; distance=3D33792 kB, estimate=3D3=
4986 kB
2022-08-01 19:33:41.933 UTC [1487121][checkpointer][:0] LOG:  shutting dow=
n

and wrasse shows this:

2022-08-02 06:35:01.974 CEST [5606:6] LOG:  received fast shutdown request
2022-08-02 06:35:01.974 CEST [5606:7] LOG:  aborting any active transactio=
ns
2022-08-02 06:35:01.975 CEST [6758:1] FATAL:  terminating autovacuum proce=
ss due to administrator command
2022-08-02 06:35:01.975 CEST [6758:2] CONTEXT:  while vacuuming index "spg=
ist_point_idx" of relation "public.spgist_point_tbl"
2022-08-02 06:35:01.981 CEST [5606:8] LOG:  background worker "logical rep=
lication launcher" (PID 5612) exited with exit code 1
2022-08-02 06:35:01.995 CEST [5607:42] LOG:  shutting down

While not smoking guns, these definitely prove that autovac was active.

			regards, tom lane