On Thu, Aug 18, 2011 at 03:23, Greg Smith g...@2ndquadrant.com wrote:
On 08/17/2011 07:42 PM, Euler Taveira de Oliveira wrote:
I don't like exposing this information only on title processes. It would
be difficult for client apps (for example, PGAdmin) to track this kind of
information and it
Please ignore the previous patch.
Please find the updated patch.
--
Thanks Regards,
Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Companyhttp://www.enterprisedb.com
*http://www.linkedin.com/in/asheshvashi*http://www.linkedin.com/in/asheshvashi
On Thu, Aug 18, 2011 at 12:57 PM,
Magnus Hagander mag...@hagander.net writes:
Also, unrelated to that, wouldn't this information be interesting for
non-autovacuum queries as well?
I was about to say that I would like to see it for normal queries too,
but I guess we already have it:
= explain (analyze, buffers, costs off)
Em 18-08-2011 03:39, Magnus Hagander escreveu:
Also, unrelated to that, wouldn't this information be interesting for
non-autovacuum queries as well?
Yes, it would. AFAICS, the patch will display that message in process titles.
However, analyze code also uses the vacuum_delay_point(). How do
Hi,
While looking at Greg's patch I spotted that resource usage code for vacuum is
initialized even if we won't use it. Attached is a small patch that moves it
to the right place (this code mimics do_analyze_rel function).
--
Euler Taveira de Oliveira - Timbira
On 17/08/11 23:10, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
Here are two patches that fix two separate bugs that you found
simultaneously. Because they're actually separate issues, it turned out
fixing them was a bit more tricky than I expected (fixing one
On tor, 2011-08-18 at 14:51 +0530, Ashesh Vashi wrote:
Please ignore the previous patch.
Please find the updated patch.
Committed more or less like that.
In passing I also fixed the build with Python 3 on Windows, which
apparently never worked before. But I suppose you have been referring
to
On Thu, Aug 18, 2011 at 5:25 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-08-18 at 14:51 +0530, Ashesh Vashi wrote:
Please ignore the previous patch.
Please find the updated patch.
Committed more or less like that.
Thanks
In passing I also fixed the build with Python 3 on
Magnus Hagander mag...@hagander.net writes:
On Thu, Aug 18, 2011 at 03:23, Greg Smith g...@2ndquadrant.com wrote:
On 08/17/2011 07:42 PM, Euler Taveira de Oliveira wrote:
I don't like exposing this information only on title processes.
I tend to build the simplest possible thing that is useful
On 07.07.2011 18:43, Kevin Grittner wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote:
On 05.07.2011 20:06, Kevin Grittner wrote:
There's two expected output files for this, one for
max_prepared_xacts=0 and another for the normal case. The
max_prepared_xacts=0 case isn't
On Thu, Aug 18, 2011 at 7:02 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
While looking at Greg's patch I spotted that resource usage code for vacuum
is initialized even if we won't use it. Attached is a small patch that moves
it to the right place (this code mimics do_analyze_rel
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 07.07.2011 18:43, Kevin Grittner wrote:
OK. I'll work on this tonight unless Dan jumps in to claim it.
Committed. I removed the second expected output file, and marked the
prepared-transactions tests in the schedule as ignore
On 18.08.2011 17:07, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 07.07.2011 18:43, Kevin Grittner wrote:
OK. I'll work on this tonight unless Dan jumps in to claim it.
Committed. I removed the second expected output file, and marked the
On Wed, Aug 17, 2011 at 9:23 PM, Greg Smith g...@2ndquadrant.com wrote:
On 08/17/2011 07:42 PM, Euler Taveira de Oliveira wrote:
I don't like exposing this information only on title processes. It would
be difficult for client apps (for example, PGAdmin) to track this kind of
information and
2011/8/18 Shigeru Hanada shigeru.han...@gmail.com:
Thanks for the review.
(2011/08/13 3:59), Robert Haas wrote:
IMHO, the new format should put parentheses around the options list.
Agreed. Revised version of patch has been attached. This version puts
parentheses around FDW option only
On tor, 2011-08-18 at 08:39 +0200, Magnus Hagander wrote:
Also, unrelated to that, wouldn't this information be interesting for
non-autovacuum queries as well?
Last year we were discussing some details on progress reporting, and
some people suggested that instead of printing a single
On Thu, Aug 18, 2011 at 10:54 AM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-08-18 at 08:39 +0200, Magnus Hagander wrote:
Also, unrelated to that, wouldn't this information be interesting for
non-autovacuum queries as well?
Last year we were discussing some details on progress
On Thu, Aug 18, 2011 at 17:13, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 18, 2011 at 10:54 AM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-08-18 at 08:39 +0200, Magnus Hagander wrote:
Also, unrelated to that, wouldn't this information be interesting for
non-autovacuum
On Thu, Aug 18, 2011 at 11:14 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Aug 18, 2011 at 17:13, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 18, 2011 at 10:54 AM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-08-18 at 08:39 +0200, Magnus Hagander wrote:
Also,
On Thu, Aug 18, 2011 at 17:23, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 18, 2011 at 11:14 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Aug 18, 2011 at 17:13, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 18, 2011 at 10:54 AM, Peter Eisentraut pete...@gmx.net wrote:
On 08/18/2011 10:12 AM, Robert Haas wrote:
Perhaps a reasonable way to break up the patch would be:
- Part 1: Gather the information and display it in the
log_autovacuum_min_duration output.
- Part 2: Add the ability to see the information incrementally (via
some mechanism yet to be agreed
On 08/18/2011 10:54 AM, Peter Eisentraut wrote:
So how about adding a column to pg_stat_activity, progress_metrics or
something like that, and add that information there.
Adding a field here (I'd go for the simpler progress) and updating it
regularly would be a reasonable way to go here.
On Thu, Aug 18, 2011 at 17:54, Greg Smith g...@2ndquadrant.com wrote:
On 08/18/2011 10:54 AM, Peter Eisentraut wrote:
So how about adding a column to pg_stat_activity, progress_metrics or
something like that, and add that information there.
Adding a field here (I'd go for the simpler
On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
The attached patch is revised userspace-avc patch.
List of updates:
- The GUC of sepgsql.avc_threshold was removed.
- char *ucontext of avc_cache was replaced by bool tcontext_is_valid.
- Comments added onto
On Thu, Aug 18, 2011 at 11:41 AM, Greg Smith g...@2ndquadrant.com wrote:
On 08/18/2011 10:12 AM, Robert Haas wrote:
Perhaps a reasonable way to break up the patch would be:
- Part 1: Gather the information and display it in the
log_autovacuum_min_duration output.
- Part 2: Add the ability to
On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai kohei.kai...@emea.nec.com
wrote:
The attached patch is revised userspace-avc patch.
List of updates:
- The GUC of sepgsql.avc_threshold was removed.
- char *ucontext of
On Thu, Aug 18, 2011 at 12:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai kohei.kai...@emea.nec.com
wrote:
The attached patch is revised userspace-avc patch.
List of
That's lame. I think we need to patch contrib/sepgsql so that it
fails to build in that case, rather than building and then not
working.
It might be the following fix, but I have no idea to generate an error when
$(with_selinux) != yes on makefile.
diff --git a/contrib/sepgsql/Makefile
On Thu, Aug 18, 2011 at 1:00 PM, Robert Haas robertmh...@gmail.com wrote:
[more problems]
OK, I'm giving up for now. I hit two more snags:
1. chkselinuxenv uses which, and a Fedora 15 minimal install doesn't
include that. I fixed that by installing which, but maybe we ought
to be looking for
On Jul 14, 2011, at 9:53 AM, David E. Wheeler wrote:
(2011/07/14 3:49), Thomas Lotterer wrote:
Thanks for the hint.
Our ftp daemon is dumping core.
We are debugging ...
Ah, good news, thanks.
Where should I report stuff like this in the future? I sent a message about
this to
OK, I'm giving up for now. I hit two more snags:
1. chkselinuxenv uses which, and a Fedora 15 minimal install doesn't
include that. I fixed that by installing which, but maybe we ought
to be looking for a way to eliminate that dependency, like testing for
the commands you need by running
On Thu, Aug 18, 2011 at 1:17 PM, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
That's lame. I think we need to patch contrib/sepgsql so that it
fails to build in that case, rather than building and then not
working.
It might be the following fix, but I have no idea to generate an error when
Em 18-08-2011 12:54, Greg Smith escreveu:
I was hoping to eventually take the useful summary bits at the end, the
totals, and save those into statistics somewhere each time a VACUUM of
either sort finishes. It would fit with the information shown in
pg_stat_tables, but that's obviously getting
On Tue, May 10, 2011 at 8:19 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Any thoughts welcome. ?Incidentally, if anyone else feels like working
on this, feel free to let me know and I'm happy to step away, from all
of it or from whatever part someone else wants to tackle.
Hi all,
A few gripes about mb_regress.sh:
1. No exit code is specified, so even if there are differences
between results/ and expected/ the script will still return 0.
2. The 'dropdb' command is used to wipe out the utf8 database
before the run. This generates an error message like:
dropdb:
I ran into $SUBJECT whilst doing trial RPM packaging of 9.1. The problem
is that make starts building contrib modules before errcodes.h has been
made, leading to failures such as
In file included from ../../src/include/postgres.h:48:0,
from auth_delay.c:12:
36 matches
Mail list logo
