| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Richard Huxton <dev(at)archonet(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Hot Standby query cancellation and Streaming Replication integration |
| Date: | 2010-02-26 17:45:33 |
| Message-ID: | 603c8f071002260945t82f6f3dt67ceca34ba9f9287@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Feb 26, 2010 at 10:21 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Richard Huxton wrote:
>> Can we not wait to cancel the transaction until *any* new lock is
>> attempted though? That should protect all the single-statement
>> long-running transactions that are already underway. Aggregates etc.
>
> Hmm, that's an interesting thought. You'll still need to somehow tell
> the victim backend "you have to fail if you try to acquire any more
> locks", but a single per-backend flag in the procarray would suffice.
>
> You could also clear the flag whenever you free the last snapshot in the
> transaction (ie. between each query in read committed mode).
Wow, that seems like it would help a lot. Although I'm not 100% sure
I follow all the details of how this works.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2010-02-26 17:46:15 | Re: Hot Standby query cancellation and Streaming Replication integration |
| Previous Message | Jaime Casanova | 2010-02-26 17:39:31 | Re: pgbouncer + psql 9.0a4 |