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.
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? |