Re: Monitoring for long running transactions

From: Samuel Smith <pgsql(at)net153(dot)net>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Monitoring for long running transactions
Date: 2020-06-04 19:59:51
Message-ID: 920bb4ce-6ba8-2888-6239-52a15474fc58@net153.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 6/4/20 2:29 PM, Adrian Klaver wrote:
> On 6/4/20 10:00 AM, Samuel Smith wrote:
>> We had a customer complaining of random data loss for the last 6
>> months or so. We eventually tracked it down to a combination of bad
>> coding and a couple of bugs with the ORM. Basically, 'BEGIN' was being
>> emitted by the web app when viewing a certain page and 'COMMIT' was
>> never emitted after that. So once the app would get restarted, all
>> data changes would be lost. Definitely worst case scenario.
>>
>> So the question is, what is the best way to monitor for this scenario
>> going forward? Are there any plugins or community recommended scripts
>> already made?
>
> https://www.postgresql.org/docs/12/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW
>
>
> "
> state     text     Current overall state of this backend. Possible
> values are:
>
>     active: The backend is executing a query.
>
>     idle: The backend is waiting for a new client command.
>
>     idle in transaction: The backend is in a transaction, but is not
> currently executing a query.
>
>     idle in transaction (aborted): This state is similar to idle in
> transaction, except one of the statements in the transaction caused an
> error.
>
>     fastpath function call: The backend is executing a fast-path function.
>
>     disabled: This state is reported if track_activities is disabled in
> this backend.
> "
>
>>
>> Regards,
>>
>>
>>
>>
>
>

Sorry, I should have clarified that I was aware of the pg_stat_activity
table. That is how we found the problem in the first place. And yes I
could just write a bash script and run it in cron. I just didn't know if
there was a more "official" way to go about this since it is probably a
common monitoring point and/or if something like this was already made.

Regards,

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Munro 2020-06-04 20:16:09 Re: Shared memory error
Previous Message Tanja Savic 2020-06-04 19:52:19 Move configuration files with pg_upgrade