Re: [HACKERS] Include commit identifier in version() function

2011-11-05 Thread Robert Haas
On Sat, Nov 5, 2011 at 2:46 PM, Jeff Janes wrote: >> Moreover, there's no real guarantee that you're compiling from a git >> tree at all; you could well be compiling from a tarball. >> >> All in all I feel like this is a solution in search of a problem. >> People shouldn't be using anything other

[HACKERS] Measuring relation free space

2011-11-05 Thread Greg Smith
Attached patch adds a new function to the pageinspect extension for measuring total free space, in either tables or indexes. It returns the free space as a percentage, so higher numbers mean more bloat. After trying a couple of ways to quantify it, I've found this particular measure correlate

Re: [HACKERS] [PATCH] optional cleaning queries stored in pg_stat_statements

2011-11-05 Thread Tomas Vondra
Dne 6.11.2011 03:16, Peter Geoghegan napsal(a): > 2011/11/6 Tomas Vondra : >> Hi everyone, > >> The patch implements a simple "cleaning" that replaces the parameter >> values with generic strings - e.g. numbers are turned to ":n", so the >> queries mentioned above are turned to >> >> SELECT abal

Re: [HACKERS] [PATCH] optional cleaning queries stored in pg_stat_statements

2011-11-05 Thread Peter Geoghegan
2011/11/6 Tomas Vondra : > Hi everyone, > The patch implements a simple "cleaning" that replaces the parameter > values with generic strings - e.g. numbers are turned to ":n", so the > queries mentioned above are turned to > >   SELECT abalance FROM pgbench_accounts WHERE aid = :n > > and thus tra

[HACKERS] [PATCH] optional cleaning queries stored in pg_stat_statements

2011-11-05 Thread Tomas Vondra
Hi everyone, I propose a patch that would allow optional "cleaning" of queries tracked in pg_stat_statements, compressing the result and making it more readable. The default behavior is that when the same query is run with different parameter values, it's actually stored as two separate queries (

Re: [HACKERS] Include commit identifier in version() function

2011-11-05 Thread Jeff Janes
2011/10/28 Robert Haas : > 2011/10/28 pasman pasmański : >> I think, it be useful to include in version() function a hexadecimal >> identifier of commit, for fast checkout to it in git. > > It's sort of impossible to make this accurate, though.  You may have > patched your tree but not created a co

[HACKERS] Re: [GENERAL] Strange problem with create table as select * from table;

2011-11-05 Thread Martijn van Oosterhout
On Fri, Nov 04, 2011 at 09:04:02PM -0400, Tom Lane wrote: > Hah ... I have a theory. > > I will bet that you recently added some column(s) to the source table > using ALTER TABLE ADD COLUMN and no default value, so that the added > columns were nulls and no table rewrite happened. And that these

[HACKERS] proposal: psql concise mode

2011-11-05 Thread Josh Kupershmidt
Hi all, The good news is that psql's backslash commands are becoming quite thorough at displaying all information which could conceivably be of interest about an object. The bad news is, psql's backslash commands often produce a lot of noise and wasted output. (There was some grumbling along these

Re: [HACKERS] [GENERAL] Strange problem with create table as select * from table;

2011-11-05 Thread Tom Lane
I wrote: > A different line of thought is that there's something about these > specific source rows, and only these rows, that makes them vulnerable to > corruption during INSERT/SELECT. Do they by any chance contain any > values that are unusual elsewhere in your table? One thing I'm > wondering

Re: [HACKERS] pg_upgrade automatic testing

2011-11-05 Thread Peter Eisentraut
On mån, 2011-09-19 at 07:06 +0300, Peter Eisentraut wrote: > I found a simpler way to get this working. Just hack up the catalogs > for the new path directly. So I can now run this test suite against > older versions as well, like this: > > contrib/pg_upgrade$ make installcheck oldsrc=somewhere

Re: [HACKERS] psql expanded auto

2011-11-05 Thread Noah Misch
On Sat, Nov 05, 2011 at 04:53:56PM +0200, Peter Eisentraut wrote: > On fre, 2011-11-04 at 07:34 -0400, Noah Misch wrote: > > For "\pset format wrapped", we only use $COLUMNS when the output is a > > tty. I'm thinking it's best, although not terribly important, to > > apply the same rule to this fe

Re: [HACKERS] IDLE in transaction introspection

2011-11-05 Thread Greg Smith
On 11/04/2011 05:01 PM, Tom Lane wrote: Scott Mead writes: I leave the waiting flag in place for posterity. With this in mind, is the consensus: RUNNING or ACTIVE Personally, I'd go for lower case. I was thinking it would be nice if this state looked like the

Re: [HACKERS] [GENERAL] Strange problem with create table as select * from table;

2011-11-05 Thread Adrian Klaver
On Friday, November 04, 2011 6:04:02 pm Tom Lane wrote: > I wrote: > > A different line of thought is that there's something about these > > specific source rows, and only these rows, that makes them vulnerable to > > corruption during INSERT/SELECT. Do they by any chance contain any > > values th

Re: [HACKERS] psql expanded auto

2011-11-05 Thread Peter Eisentraut
On fre, 2011-11-04 at 07:34 -0400, Noah Misch wrote: > For "\pset format wrapped", we only use $COLUMNS when the output is a > tty. I'm thinking it's best, although not terribly important, to > apply the same rule to this feature. I think it does work that way. There is only one place where the

[HACKERS] plpython extension control files installation

2011-11-05 Thread Peter Eisentraut
We only build the language plpython2u or plpython3u, not both, in any build, but we always install the extension control files for all variants. Is there a reason for this, or just an oversight? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subsc

[HACKERS] type privileges and default privileges

2011-11-05 Thread Peter Eisentraut
During the closing days of the 9.1 release, we had discussed that we should add privileges on types (and domains), so that owners can prevent others from using their types because that would prevent the owners from changing them in certain ways. (Collations have similar issues and work quite simil

Re: [HACKERS] Proposal: casts row to array and array to row

2011-11-05 Thread Noah Misch
On Tue, Oct 11, 2011 at 10:40:26AM +0200, Pavel Stehule wrote: > What do you think about this idea? +1, belatedly. Having inherent casts to/from text since version 8.3 has smoothed out some aggravating corner cases. If the patch isn't invasive and the casts are all explicit-only, I anticipate a

Re: [HACKERS] Show statistics target in \d+

2011-11-05 Thread Magnus Hagander
On Fri, Nov 4, 2011 at 16:13, Tom Lane wrote: > Magnus Hagander writes: >> Would you find it better if we showed blank (NULL) when it was -1? > > Yeah, I would.  Seems less confusing. Adjusted per this, renamed to "Stats target", and applied. --  Magnus Hagander  Me: http://www.hagander.net/

Re: [HACKERS] Show sequences owned by

2011-11-05 Thread Magnus Hagander
On Fri, Nov 4, 2011 at 16:04, Tom Lane wrote: > Magnus Hagander writes: >> Updated patch attached that does this, and the proper schema qualifications. > > I'd schema-qualify the quote_ident and regclass names too. > > Also, just as a matter of style, I think it'd be better to assign short > alia