Re: Change pg_cancel_*() to ignore current backend

From: Eric Ridge <eebbrr(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Eric Ridge <e_ridge(at)tcdi(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Change pg_cancel_*() to ignore current backend
Date: 2015-05-23 02:24:56
Message-ID: CANcm6wb_yAqaHTwoz66+dfPmj1gu6hS__mDns8fVzPo+ajSx8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 22, 2015 at 4:51 PM Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> Interesting idea. I suspect that would be even more invasive than
> modifying the functions though...
>

Here's the solution. I can't see how anyone could possibly disagree with
this... ;)

Change the sort order for pg_stat_activity so the current session sorts
last. That way all the other sessions get killed first when doing select
pg_terminate_backend(pid) from pg_stat_activity.

When I get bitten by this, I don't really care that my session gets killed,
I care that it gets killed before all the others. Personally, I only do
this sort of thing interactively via psql, and typically ^D as soon as the
query finishes (which means the second time I run psql and add a WHERE
clause to the query).

Alternatively, queue up pg_cancel/terminate_backend calls and process them
only on successful transaction commit, in such an order that the current
session is processed last. They'd be consistent with NOTIFY too, which
might be an added bonus.

eric

ps, sorry my last message was from corporate email w/ the stupid "legal"
disclaimer.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message CharSyam 2015-05-23 02:40:36 patch: change magic constants to DEFINE value for readability.
Previous Message Andrew Dunstan 2015-05-23 02:22:14 jsonb_set: update or upsert default?