Re: Hung Query with No Locking Issues - Mailing list pgsql-general

From Michael P. McDonnell
Subject Re: Hung Query with No Locking Issues
Date
Msg-id CAHmCLHrsd81NLtOD9zpGjQc+Csn94bjxsXSmK1UBsLcFPkSA7Q@mail.gmail.com
Whole thread Raw
In response to Re: Hung Query with No Locking Issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Okay - that worked.
How did you know that would work? That's incredible.

On Sun, May 7, 2023 at 4:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Michael P. McDonnell" <bzaks1424@gmail.com> writes:
> I have 2 stored procedures that need to run back to back. It could
> convert to a single one - but it's easier from a maintenance perspective to
> keep them separated.

> The first procedure effectively is
> INSERT INTO table_b () SELECT ____ FROM _table_a_;
> COMMIT;

> Total execution time - about 180s. Nothing in the pg_locks table and
> nothing in the pg_stat_activity table suggests anything is hung over.

> The second procedure mutates table_b data into table_b_collapsed
> INSERT INTO table_c () SELECT _____ FROM _table_b_ JOIN _table_b as b1_
> JOIN _table_b as b2_ JOIN _table_b as b3_, etc...;
> COMMIT;

> The first time I run my second stored procedure - it hangs for up to 8
> hours.
> If I immediately cancel and re-run the second stored procedure it runs in 2
> seconds.

Perhaps an "ANALYZE table_b" in between would help.

                        regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Hung Query with No Locking Issues
Next
From: Tom Lane
Date:
Subject: Re: Hung Query with No Locking Issues