Re: [HACKERS] PATCH: Compiling PostgreSQL using ActiveState Python 3.2

On Thu, Aug 18, 2011 at 1:25 AM, Tom Lane wrote: > Peter Eisentraut writes: > > On ons, 2011-08-17 at 13:20 -0400, Tom Lane wrote: > >> It's not immediately apparent to me why we should think that > >> get_python_lib is less trustworthy than LIBPL; but if someone > >> can make that case, I don't

Re: [HACKERS] FATAL: ReleaseSavepoint: unexpected state STARTED

On Wed, Aug 17, 2011 at 11:30 PM, Tom Lane wrote: > =?UTF-8?B?TWFyY2luIE1hxYRr?= writes: >>  psql -c 'release q; prepare q(int) as select 1' >> FATAL:  ReleaseSavepoint: unexpected state STARTED > > Can't get terribly excited about that, seeing that the statement is > surely going to draw an erro

Re: [HACKERS] PATCH: Compiling PostgreSQL using ActiveState Python 3.2

Please ignore the previous patch. Please find the updated patch. -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company *http://www.linkedin.com/in/asheshvashi* On Thu, Aug 18, 2011 at 12:57 P

Re: [HACKERS] Displaying accumulated autovacuum cost

Magnus Hagander 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) select * from pg_at

Re: [HACKERS] Displaying accumulated autovacuum cost

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 you

[HACKERS] vacuum rusage fix

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 http://www.timbira.com

Re: [HACKERS] plpython crash

On 17/08/11 23:10, Tom Lane wrote: > =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 was >> unmaski

Re: [HACKERS] PATCH: Compiling PostgreSQL using ActiveState Python 3.2

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

Re: [HACKERS] PATCH: Compiling PostgreSQL using ActiveState Python 3.2

On Thu, Aug 18, 2011 at 5:25 PM, Peter Eisentraut 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 Windows

Re: [HACKERS] Displaying accumulated autovacuum cost

Magnus Hagander writes: > On Thu, Aug 18, 2011 at 03:23, Greg Smith 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 enough to work. > By only putt

Re: [HACKERS] SSI 2PC coverage

On 07.07.2011 18:43, Kevin Grittner wrote: Heikki Linnakangas 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 very interesting, since all the PREP

Re: [HACKERS] vacuum rusage fix

On Thu, Aug 18, 2011 at 7:02 AM, Euler Taveira de Oliveira 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 function). Looks

Re: [HACKERS] SSI 2PC coverage

Heikki Linnakangas 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" instead. That > way if max_

Re: [HACKERS] SSI 2PC coverage

On 18.08.2011 17:07, Tom Lane wrote: Heikki Linnakangas 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 "ign

Re: [HACKERS] Displaying accumulated autovacuum cost

On Wed, Aug 17, 2011 at 9:23 PM, Greg Smith 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 is restric

Re: [HACKERS] Change format of FDW options used in \d* commands

2011/8/18 Shigeru Hanada : > 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 when it was not NULL

Re: [HACKERS] Displaying accumulated autovacuum cost

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 percentag

Re: [HACKERS] Displaying accumulated autovacuum cost

On Thu, Aug 18, 2011 at 10:54 AM, Peter Eisentraut 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 reporting, and

Re: [HACKERS] Displaying accumulated autovacuum cost

On Thu, Aug 18, 2011 at 17:13, Robert Haas wrote: > On Thu, Aug 18, 2011 at 10:54 AM, Peter Eisentraut 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

Re: [HACKERS] Displaying accumulated autovacuum cost

On Thu, Aug 18, 2011 at 11:14 AM, Magnus Hagander wrote: > On Thu, Aug 18, 2011 at 17:13, Robert Haas wrote: >> On Thu, Aug 18, 2011 at 10:54 AM, Peter Eisentraut wrote: >>> On tor, 2011-08-18 at 08:39 +0200, Magnus Hagander wrote: Also, unrelated to that, wouldn't this information be inter

Re: [HACKERS] Displaying accumulated autovacuum cost

On Thu, Aug 18, 2011 at 17:23, Robert Haas wrote: > On Thu, Aug 18, 2011 at 11:14 AM, Magnus Hagander wrote: >> On Thu, Aug 18, 2011 at 17:13, Robert Haas wrote: >>> On Thu, Aug 18, 2011 at 10:54 AM, Peter Eisentraut wrote: On tor, 2011-08-18 at 08:39 +0200, Magnus Hagander wrote: > Al

Re: [HACKERS] Displaying accumulated autovacuum cost

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 upon).

Re: [HACKERS] Displaying accumulated autovacuum cost

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.

Re: [HACKERS] Displaying accumulated autovacuum cost

On Thu, Aug 18, 2011 at 17:54, Greg Smith 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 "progress") and

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai 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 static variables > -

Re: [HACKERS] Displaying accumulated autovacuum cost

On Thu, Aug 18, 2011 at 11:41 AM, Greg Smith 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 info

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas wrote: > On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai > 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 t

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

On Thu, Aug 18, 2011 at 12:52 PM, Robert Haas wrote: > On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas wrote: >> On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai >> wrote: >>> The attached patch is revised userspace-avc patch. >>> >>> List of updates: >>> - The GUC of sepgsql.avc_threshold was remov

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

> 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/Makefil

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

On Thu, Aug 18, 2011 at 1:00 PM, Robert Haas 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 a way to eliminat

Re: [HACKERS] Full GUID support

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 > th

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

> 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

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

On Thu, Aug 18, 2011 at 1:17 PM, Kohei Kaigai 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 > $(with_selinux

Re: [HACKERS] Displaying accumulated autovacuum cost

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 to

Re: [HACKERS] the big picture for index-only scans

On Tue, May 10, 2011 at 8:19 PM, Bruce Momjian 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. ?I'm

[HACKERS] mb_regress.sh gripes

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:

[HACKERS] "make -j4 world" falls over

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: ../../src/include/util