Re: pg_prepared_statements

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: rob stone <floriparob(at)gmail(dot)com>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_prepared_statements
Date: 2020-01-21 03:18:02
Message-ID: CAKFQuwb_wjhWQb87mA_QPhvO0g8+OHHpy5=rCJOW3FhsVgRg7A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Jan 20, 2020 at 8:00 PM rob stone <floriparob(at)gmail(dot)com> wrote:

> Hello,
>
> PostgreSQL 11.6 (Debian 11.6-2~sid1) on x86_64-pc-linux-gnu, compiled
> by gcc (Debian 9.2.1-21) 9.2.1 20191130, 64-bit
>
> Is there something awry with the pg_prepared_statements view?
> This is the only row found and it is NOT created by the application.
>
> name statement prepare_time parameter_types from_sql
> S_1 ROLLBACK 2020-01-21 12:35:35.031257 {} false
>
>
> In the development environment every statement is logged, however for
> some reason the DEALLOCATE's never appear in the logs. This could be
> caused by the view not recording the prepared statement, as the
> DEALLOCATE is only made if the prepared statement name exists in the
> view.
>
> max_prepared_transactions = 6 is the value set in postgresql.conf.
>

I don't know why that particular record exists but your comment about the
application not creating it and DEALLOCATE's never appearing in the log
suggests to me a misunderstanding of what this view shows.

https://www.postgresql.org/docs/12/view-pg-prepared-statements.html

Specifically it is not a "log" in the transaction sense and its only shows
current session data.

David J.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2020-01-21 03:22:32 Re: pg_prepared_statements
Previous Message rob stone 2020-01-21 03:00:28 pg_prepared_statements