| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, Greg Stark <gsstark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Re: Hot Standby query cancellation and Streaming Replication integration |
| Date: | 2010-03-10 06:29:19 |
| Message-ID: | 4B973C3F.9070501@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
All,
I've been playing with vacuum_defer_cleanup_age in reference to the
query cancel problem. It really seems to me that this is the way
forward in terms of dealing with query cancel for normal operation
rather than wal_standby_delay, or maybe in combination with it.
As a first test, I set up a deliberately pathological situation with
pgbench and a wal_standby_delay of 1 second. This allowed me to trigger
query cancel on a relatively simple reporting query; in fact, to make it
impossible to complete.
Then I increased vacuum_defer_cleanup_age to 100000, which represents
about 5 minutes of transactions on the test system. This eliminated all
query cancels for the reporting query, which takes an average of 10s.
Next is a database bloat test, but I'll need to do that on a system with
more free space than my laptop.
--Josh Berkus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2010-03-10 07:39:00 | Re: patch (for 9.1) string functions |
| Previous Message | Josh Berkus | 2010-03-10 06:02:09 | PD_ALL_VISIBLE flag error on 9.0 alpha 4 |