From: | daveg <daveg(at)sonic(dot)net> |
---|---|
To: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 8.5 release timetable, again |
Date: | 2009-08-28 09:35:50 |
Message-ID: | 20090828093550.GE13836@sonic.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 27, 2009 at 09:38:15PM +0200, Dimitri Fontaine wrote:
> Exactly, and I think that what we're missing here is a simple tool for
> our users to check a new PostgreSQL release against their existing
> application.
>
> We already know how to either log all queries and analyze the log files
> (CSV makes it easier, pgfouine parses them too) or to have a fe/be
> protocol proxy to record application SQL traffic (tsung recorder does
> that).
>
> What we miss is a tool to run the captured queries through both versions
> of PG and report any resultset mismatch, of course with a way to account
> for ordering issues (but we've seen people rely on the ordering when
> they don't give an order by clause, then bug the lists about it if a new
> release changes it).
This would be very useful. I often am asked "how much better will the new
release run our apps" as part of convincing a client to upgrade to a
more current postgresql release. Being able to replay a days workload in a
somewhat realistic manner would be a great help.
-dg
--
David Gould daveg(at)sonic(dot)net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-08-28 11:26:43 | Re: 8.5 release timetable, again |
Previous Message | Paul Matthews | 2009-08-28 08:53:24 | phypot - Pygmy Hippotause ? |