Re: [HACKERS] [BUGS] BUG #4961: pg_standby.exe crashes with no args

Hi, On Thu, Aug 13, 2009 at 2:24 AM, Magnus Hagander wrote: > Not sure. Potentially pure luck. SIGINT has never *worked*, though, it > just hasn't crashed. OK. > We could implement the same type of check in pg_standby, but it > requires something like CHECK_FOR_INTERRUPTS. And these interrupts >

[HACKERS] release notes - issue

Hello "PL/pgSQL functions using RETURNS QUERY or RECORD types no longer always need to be rebuilt after adding or dropping a column for the related tables." I thing, so this isn't correct. When you dropped column, then you had to rebuild table - rebuild related function had no effect. Regards P

Re: [HACKERS] Idea about estimating selectivity for single-column expressions

On Tue, Aug 18, 2009 at 10:53 PM, Tom Lane wrote: > There were two different complaints today about the planner's inability > to make good estimates for WHERE conditions involving bit AND tests, > such as >        (field & 8) = 0 >        (field & 8) <> 0 >        (field & 127) = field > > I'm not

[HACKERS] Idea about estimating selectivity for single-column expressions

There were two different complaints today about the planner's inability to make good estimates for WHERE conditions involving bit AND tests, such as (field & 8) = 0 (field & 8) <> 0 (field & 127) = field I'm not particularly eager to try to put in special-case knowledge for

Re: [HACKERS] pg_hba.conf: samehost and samenet

On Tue, Aug 18, 2009 at 10:11 PM, Tom Lane wrote: > Stef Walter writes: >> Magnus Hagander wrote: >>> Please add it to the open commitfest >>> (https://commitfest.postgresql.org/action/commitfest_view/open). This >>> will cause it to be reviewed during the next commitfest, and then you >>> just ne

Re: [HACKERS] pg_hba.conf: samehost and samenet

Stef Walter writes: > Magnus Hagander wrote: >> Please add it to the open commitfest >> (https://commitfest.postgresql.org/action/commitfest_view/open). This >> will cause it to be reviewed during the next commitfest, and then you >> just need to be around to answer any questions that reviewers co

Re: [HACKERS] pg_hba.conf: samehost and samenet

Attached is a new patch, which I hope addresses all the concerns raised. Magnus Hagander wrote: >> I've attached an initial patch which implements "samehost" and >> "samenet". The patch looks more invasive than it really is, due to >> necessary indentation change (ie: a if block), and moving some

Re: [HACKERS] REGRESS_OPTS versus MSVC build scripts

Andrew Dunstan writes: > David Fetter wrote: >> This section is probably better done with Tie::File. > You keep pushing that barrow. I ripped Tie::File OUT of the buildfarm - > it is not universally available. Besides, as the perl world says, TIMTOWTDI. Also, there's some value in having the co

Re: [HACKERS] REGRESS_OPTS versus MSVC build scripts

Alvaro Herrera wrote: Andrew Dunstan wrote: + sub fetchRegressOpts + { + my $handle; + open($handle," I think you should try GNUmakefile first, Makefile second. That's what gmake does. Hmm, ok. It doesn't matter much in the present case - none of the contrib modules a

Re: [HACKERS] REGRESS_OPTS versus MSVC build scripts

David Fetter wrote: + my $handle; + open($handle," This section is probably better done with Tie::File. You keep pushing that barrow. I ripped Tie::File OUT of the buildfarm - it is not universally available. Besides, as the perl world says, TIMTOWTDI. cheers andrew --

Re: [HACKERS] Lazy Snapshots

Simon, > Another way of doing this is to utilize lazy snapshots: do not take a > snapshot when a statement starts and only take one at the point that we > need one. No other changes to the MVCC mechanisms are proposed. I like your general thinking here, even if this specific idea proves unworkabl

Re: [HACKERS] REGRESS_OPTS versus MSVC build scripts

Andrew Dunstan wrote: > + sub fetchRegressOpts > + { > + my $handle; > + open($handle," + || open($handle," + || die "Could not open Makefile"; I think you should try GNUmakefile first, Makefile second. That's what gmake does. -- Alvaro Herrera

Re: [HACKERS] "make install" now tries to build the documentation

Peter Eisentraut writes: > On tis, 2009-08-18 at 15:13 -0400, Tom Lane wrote: >> Well, having "make install" behave in a history-dependent fashion is just >> as much a hazard for users as it is for developers. > That's kind of a built-in feature of make. Otherwise we could write the > build rule

Re: [HACKERS] "make install" now tries to build the documentation

On tis, 2009-08-18 at 15:13 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On tis, 2009-08-18 at 14:32 -0400, Tom Lane wrote: > >> I'm leaning more towards the "make install-docs" solution after further > >> thought. One thing that's always been a bit bogus about make install > >> is that

Re: [HACKERS] "make install" now tries to build the documentation

Peter Eisentraut writes: > On tis, 2009-08-18 at 14:32 -0400, Tom Lane wrote: >> I'm leaning more towards the "make install-docs" solution after further >> thought. One thing that's always been a bit bogus about make install >> is that it installs the docs only if they're there. With a separate

Re: [HACKERS] "make install" now tries to build the documentation

On tis, 2009-08-18 at 14:32 -0400, Tom Lane wrote: > I'm leaning more towards the "make install-docs" solution after further > thought. One thing that's always been a bit bogus about make install > is that it installs the docs only if they're there. With a separate > top-level target, it would be

Re: [HACKERS] "make install" now tries to build the documentation

Peter Eisentraut writes: > On tis, 2009-08-18 at 13:43 -0400, Tom Lane wrote: >> but now that you mention it, I might have built the docs in that >> tree yesterday, and "make distclean" no longer cleans them out. >> [ checks overnight backups ... ] Yup, that's it: html/ and html-stamp >> were pres

Re: [HACKERS] REGRESS_OPTS versus MSVC build scripts

On Tue, Aug 18, 2009 at 02:15:48PM -0400, Andrew Dunstan wrote: > > > Andrew Dunstan wrote: >> >> >> Tom Lane wrote: >>> I believe (but won't be able to prove for another few hours) that the >>> reason the MSVC buildfarm members are failing on contrib/unaccent, >>> as seen here: >>> http://www.pg

Re: [HACKERS] Another try at reducing repeated detoast work for PostGIS

Tom Lane wrote: Mark Cave-Ayland writes: Thanks for the patch. Fortunately enough I was able to find the dataset from the original report above, and so I've tested your patch against PostgreSQL 8.4. Unfortunately in the original test case, it doesn't seem to give the same performance improvem

Re: [HACKERS] "make install" now tries to build the documentation

On tis, 2009-08-18 at 10:50 -0700, Josh Berkus wrote: > On 8/18/09 10:43 AM, Tom Lane wrote: > > Is it sensible to split out docs installation to a separate target > > "make install-docs"? Or is there some other solution? > > I'd like to have this. There are times I want to *only* build the docs

Re: [HACKERS] "make install" now tries to build the documentation

On tis, 2009-08-18 at 13:43 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On tis, 2009-08-18 at 12:17 -0400, Tom Lane wrote: > >> It happens for me on my Fedora box, but not on my HPUX box. > > > Assuming no tool bugs, the only way I can see this happening is if you > > already have built

Re: [HACKERS] REGRESS_OPTS versus MSVC build scripts

Andrew Dunstan wrote: Tom Lane wrote: I believe (but won't be able to prove for another few hours) that the reason the MSVC buildfarm members are failing on contrib/unaccent, as seen here: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=2009-08-18%2013:00:00 is that they are

Re: [HACKERS] "make install" now tries to build the documentation

On 8/18/09 10:43 AM, Tom Lane wrote: > Is it sensible to split out docs installation to a separate target > "make install-docs"? Or is there some other solution? I'd like to have this. There are times I want to *only* build the docs. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com --

Re: [HACKERS] "make install" now tries to build the documentation

Peter Eisentraut writes: > On tis, 2009-08-18 at 12:17 -0400, Tom Lane wrote: >> It happens for me on my Fedora box, but not on my HPUX box. > Assuming no tool bugs, the only way I can see this happening is if you > already have built the documentation. Then, make install might cause it > to be

Re: [HACKERS] Another try at reducing repeated detoast work for PostGIS

Mark Cave-Ayland writes: > Thanks for the patch. Fortunately enough I was able to find the dataset > from the original report above, and so I've tested your patch against > PostgreSQL 8.4. Unfortunately in the original test case, it doesn't seem > to give the same performance improvement for me

Re: [HACKERS] "make install" now tries to build the documentation

On tis, 2009-08-18 at 12:17 -0400, Tom Lane wrote: > Andrew Dunstan writes: > > Tom Lane wrote: > >> Please fix. Maybe installing the docs could be conditional on having > >> done "make distprep", instead? > > > Doesn't seem to be happening for me: > >

Re: [HACKERS] Index Selection Tool For PostgreSQL

Mahendra, > I wish to contribute my code to PostgreSQL. I am not sure if such a tool > already exists for PostgreSQL.The details of the tool are in the > attached specification. This really should be a separate tool from the Postgres executable itself, since users would want it only at design tim

Re: [HACKERS] REGRESS_OPTS versus MSVC build scripts

Tom Lane wrote: I believe (but won't be able to prove for another few hours) that the reason the MSVC buildfarm members are failing on contrib/unaccent, as seen here: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=2009-08-18%2013:00:00 is that they are not running the test in a U

[HACKERS] REGRESS_OPTS versus MSVC build scripts

I believe (but won't be able to prove for another few hours) that the reason the MSVC buildfarm members are failing on contrib/unaccent, as seen here: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=2009-08-18%2013:00:00 is that they are not running the test in a UTF8-encoded database

Re: [HACKERS] "make install" now tries to build the documentation

Andrew Dunstan writes: > Tom Lane wrote: >> Please fix. Maybe installing the docs could be conditional on having >> done "make distprep", instead? > Doesn't seem to be happening for me: >

Re: [HACKERS] PQgetlength vs. octet_length()

On Tue, Aug 18, 2009 at 4:04 PM, Michael Clark wrote: > Hello - am I in the wrong mailing list for this sort of problem? :- Probably but it's also a pretty technical point and you're programming in C so it's kind of borderline. If you're using text-mode then your datum that you're getting from li

Re: [HACKERS] "make install" now tries to build the documentation

Tom Lane wrote: Sometime since Friday, somebody (probably Peter) "fixed" things so that "make install" at the top level of the tree insists on building the SGML documentation first. I regard this as utterly unacceptable; if I'm just trying to build a new test installation (which I often do mul

Re: [HACKERS] "make install" now tries to build the documentation

Peter Eisentraut writes: > On tis, 2009-08-18 at 11:30 -0400, Tom Lane wrote: >> Sometime since Friday, somebody (probably Peter) "fixed" things so that >> "make install" at the top level of the tree insists on building the SGML >> documentation first. I regard this as utterly unacceptable; if I'

Re: [HACKERS] "make install" now tries to build the documentation

On tis, 2009-08-18 at 11:30 -0400, Tom Lane wrote: > Sometime since Friday, somebody (probably Peter) "fixed" things so that > "make install" at the top level of the tree insists on building the SGML > documentation first. I regard this as utterly unacceptable; if I'm just > trying to build a new

[HACKERS] "make install" now tries to build the documentation

Sometime since Friday, somebody (probably Peter) "fixed" things so that "make install" at the top level of the tree insists on building the SGML documentation first. I regard this as utterly unacceptable; if I'm just trying to build a new test installation (which I often do multiple times per day)

Re: [HACKERS] PQgetlength vs. octet_length()

Michael Clark wrote: > Hello - am I in the wrong mailing list for this sort of problem? :-/ Probably. If you check here: http://www.postgresql.org/community/lists/ You'll find this description for the list: "The PostgreSQL developers team lives here. Discussion of current development issu

Re: [HACKERS] PQgetlength vs. octet_length()

Hello - am I in the wrong mailing list for this sort of problem? :-/ Thanks, Michael. On Mon, Aug 17, 2009 at 6:28 PM, Michael Clark wrote: > Hello everyone. > Having a weird issue. > > I have a value inserted into a bytea column, which is about 137megs in > size. > > If I use octet_length() to

Re: [HACKERS] Lazy Snapshots

"si...@2ndquadrant.com" writes: > Currently, we take eager snapshots, meaning we take a snapshot at the start of > each statement whether or not it is necessary. Snapshots exist to disambiguate > the running state of recent transactions, so if a statement never sees data > written by recent transa

Re: [HACKERS] Determining client_encoding from client locale

(I finally got a chance to get back to this...) Jaime Casanova wrote: > ok, attached a version that modifies src/interfaces/libpq/Makefile to > push chklocale.o and eliminate the dependency on libpgport, this > change also fixes the compile problem on windows Thanks! > still, i'm not sure this p

Re: [HACKERS] COPY speedup

AFAIK you need to run app with LD_LIBRARY_PATH=/usr/lib/debug, otherwise the debug packages won't be used. I had stupidly put the LD_LIBRARY_PATH on make rather than on postgres, ahem. OK, it works, thanks. I'm very carefully benchmarking everything everytime I make a modificatio

Re: [HACKERS] COPY speedup

On 8/18/09, Pierre Frédéric Caillaud wrote: > I'm doing some more exploration with oprofile... > > I've got the glibc-debug package installed (on kubuntu), but oprofile > doesn't seem to know about it. I wonder what part of glibc gets 60% of the > run time... do I have to set a magic option in t

Re: [HACKERS] Lazy Snapshots

si...@2ndquadrant.com wrote: > * Scan begins, no snapshot set. Ahead of scan a row that would have been > visible > at start of scan is deleted, commits and removed by VACUUM/HOT. The scan has > no > evidence that a removal has taken place, never sees contention and thus never > takes a snapshot.

[HACKERS] Lazy Snapshots

One of the problems with Hot Standby is that a long running query on the standby can conflict with VACUUMed rows on the primary, causing queries to be cancelled. I've been looking at this problem for about a year now from various angles. Jeff Jane's recent thoughts on procarray scalability hav

Re: [HACKERS] Another try at reducing repeated detoast work for PostGIS

Tom Lane wrote: There was recently another go-round on the postgis-devel list about the same problem Mark Cave-Ayland complained about last year: http://archives.postgresql.org/pgsql-hackers/2008-06/msg00384.php Basically, what is happening is a nestloop join where the inner indexscan gets a com

Re: [HACKERS] explain root element for auto-explain

On Tue, Aug 18, 2009 at 02:11, Andrew Dunstan wrote: > > Tom Lane wrote: >> >> Andrew Dunstan writes: >> >>> >>> The attached tiny patch sets the root element for auto-explain >>> XML output, so it looks something like this: >>> >> >> This looks reasonable in itself, but it sort of begs the quest