situation you have described should be termed a
> "deadlock". Do you see any transaction getting rolled back?
>
>
> Regards,
> Ninad Shah
>
> On Fri, 23 Jul 2021 at 11:39, Marcin Barczynski <
> mbarczyn...@starfishstorage.com> wrote:
>
>> On Thu, Jul 22,
On Thu, Jul 22, 2021 at 5:08 PM Marcin Barczynski <
mbarczyn...@starfishstorage.com> wrote:
> On Thu, Jul 22, 2021 at 3:51 PM Laurenz Albe
> wrote:
> >
> > On Thu, 2021-07-22 at 12:55 +0200, Marcin Barczynski wrote:
> > > There was a long-running tran
On Thu, Jul 22, 2021 at 3:51 PM Laurenz Albe
wrote:
>
> On Thu, 2021-07-22 at 12:55 +0200, Marcin Barczynski wrote:
> > There was a long-running transaction consisting of two queries:
> >
> > CREATE TEMPORARY TABLE abc AS SELECT * FROM def_view;
> > INSERT IN
TABLE abc AS SELECT * FROM demo_view;
SELECT 1000
q=*# INSERT INTO result SELECT * FROM abc;
INSERT 0 1000
q=*#
psql #2:
q=# VACUUM FULL pg_class;
VACUUM
--
Regards,
Marcin Barczynski
Thanks for the immediate reply.
It turned out to be pg_attribute. It was bloated probably due to the large
number of temp tables created.
Are there any recommendations on how to prevent such a bloat from happening?
On Wed, Jun 16, 2021 at 4:10 PM Tom Lane wrote:
> Marcin Barczynski wri
In a heavily used production database prod, running a `psql prod` takes
seconds. Once the connection is established, performance of queries is
fine. There are ~2 new usually short-lived connections / second, and a
couple of long-running analytical queries. Connecting to other databases on
the same
I noticed that each query in plpython3 is executed in its own
subtransaction (
https://github.com/postgres/postgres/blob/257ee34e733aba0fc371177f1a7fd97f3cb98d74/src/pl/plpython/plpy_spi.c#L226)
which increases txid.
For example:
CREATE EXTENSION IF NOT EXISTS plpython3u;
DROP TABLE IF EXISTS de
