Re: [HACKERS] Hot standby and removing VACUUM FULL

On Wed, 2009-11-25 at 03:12 +, Greg Stark wrote: > On Wed, Nov 25, 2009 at 2:10 AM, Tom Lane wrote: > > As long as there's not anything the master actually does differently > > then I can't see where there'd be any performance testing to do. What's > > bothering me about this is that it seems

Re: [HACKERS] Listen / Notify - what to do when the queue is full

On Mon, 2009-11-30 at 14:14 +0100, Joachim Wieland wrote: > I have a new version that deals with this problem but I need to clean > it up a bit. I am planning to post it this week. Are planning to send a new version soon? As it is, we're 12 days from the end of this commitfest, so we don't have m

Re: [HACKERS] [GENERAL] Installing PL/pgSQL by default

Andrew Dunstan writes: > Before we go too far with this, I'd like to know how we will handle the > problems outlined here: > Hm, I think that's only a problem if we define it to be a problem, and I'm not sure it's necessary to

Re: [HACKERS] operator exclusion constraints

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Dec 03, 2009 at 08:38:06PM -0800, David E. Wheeler wrote: [...] > "Whatever constraints"? "Operator Whatevers"? "WhatEVER"s? I like it. drigting serioulsy off-topic: there's precedent for that in the most venerable piece of free software; Te

[HACKERS] [PATCH] Largeobject Access Controls (r2460)

The attached patch is an updated revision of Largeobject Access Controls. List of updates: * rebased to the latest CVS HEAD * SGML documentation fixes: - The future version number was replaced as: "In the 8.4.x series and earlier release, ..." - Other strange English representations and t

Re: [HACKERS] operator exclusion constraints

On Dec 3, 2009, at 6:26 PM, Robert Haas wrote: > Yeah, I don't remember any such consensus either, but it's not a dumb > name. I have been idly wondering throughout this process whether we > should try to pick a name that conveys the fact that these constraints > are inextricably tied to the opcl

Re: [HACKERS] Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a

On Wed, Dec 2, 2009 at 10:53 PM, Tom Lane wrote: > Robert Haas writes: >> Well, when I was testing, I believe I observed that an n-way join with >> 1 cross join was slower to plan than an n-way join with no cross >> joins.  ISTM that it should actually be faster, because you should >> plan it lik

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

Itagaki Takahiro wrote: > KaiGai Kohei wrote: > >>> creating template1 database in >>> /home/postgres/pg_releases/pgsql/src/test/regress/./tmp_check/data/base/1 >>> ... TRAP: FailedAssertion("!(reln->md_fd[forkNum] == ((void *)0))", >>> File: "md.c", Line: 254) >>> child process was terminated by

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

KaiGai Kohei wrote: > > creating template1 database in > > /home/postgres/pg_releases/pgsql/src/test/regress/./tmp_check/data/base/1 > > ... TRAP: FailedAssertion("!(reln->md_fd[forkNum] == ((void *)0))", > > File: "md.c", Line: 254) > > child process was terminated by signal 6: Aborted > > I c

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

Jaime Casanova wrote: > 2009/11/12 KaiGai Kohei : >> The attached patch is a revised version of large object privileges >> based on the feedbacks at the last commit fest. >> > > please update the patch, it's giving an error when 'make check' is > trying to "create template1" in initdb: > > creati

Re: [HACKERS] operator exclusion constraints

On Thu, Dec 3, 2009 at 7:42 PM, Jeff Davis wrote: > On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote: >> I'm starting to go through this patch now.  I thought the consensus >> was to refer to them as just "exclusion constraints"?  I'm not seeing >> that the word "operator" really adds anything. >

[HACKERS] Format Typmod?

Hey Hackers, I just had reason to want the way that format_type converts type names (e.g., varchar => character varying) in pgTAP, but didn't want the namespace qualification (used by format_type() when the type in question is not visible). I figured out that I could get that conversion by simp

Re: [HACKERS] First feature patch for plperl - draft [PATCH]

On Dec 3, 2009, at 3:30 PM, Tim Bunce wrote: > - New GUC plperl.on_perl_init='...perl...' for admin use. > - New GUC plperl.on_trusted_init='...perl...' for plperl user use. > - New GUC plperl.on_untrusted_init='...perl...' for plperlu user use. Since there is no documentation yet, how do these w

Re: [HACKERS] operator exclusion constraints

On Thu, 2009-12-03 at 19:00 -0500, Tom Lane wrote: > I'm starting to go through this patch now. I thought the consensus > was to refer to them as just "exclusion constraints"? I'm not seeing > that the word "operator" really adds anything. I assume you're referring to the name used in documentat

Re: [HACKERS] pgbench: new feature allowing to launch shell commands

I didn't send the good patch yesterday. => --; Here is the latest version. Regards, -- Michael Paquier NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c index 8a6437f..0bc6bfe 100644 --- a/contrib/pgbench/

Re: [HACKERS] Installing PL/pgSQL by default

Andrew Dunstan wrote: > > > Tom Lane wrote: > > Bruce Momjian writes: > > > >> One problem is that because system oids are used, it isn't possible to > >> drop the language: > >> I assume we still want to allow the language to be uninstalled, for > >> security purposes. > >> > > > > Yes.

Re: [HACKERS] Installing PL/pgSQL by default

Tom Lane wrote: Bruce Momjian writes: One problem is that because system oids are used, it isn't possible to drop the language: I assume we still want to allow the language to be uninstalled, for security purposes. Yes. That behavior is not acceptable. Why aren't you just adding a

Re: [HACKERS] Installing PL/pgSQL by default

Tom Lane wrote: > Bruce Momjian writes: > > One problem is that because system oids are used, it isn't possible to > > drop the language: > > I assume we still want to allow the language to be uninstalled, for > > security purposes. > > Yes. That behavior is not acceptable. Why aren't you just

Re: [HACKERS] Installing PL/pgSQL by default

Bruce Momjian writes: > One problem is that because system oids are used, it isn't possible to > drop the language: > I assume we still want to allow the language to be uninstalled, for > security purposes. Yes. That behavior is not acceptable. Why aren't you just adding a CREATE LANGUAGE call

[HACKERS] Installing PL/pgSQL by default

Tom Lane wrote: > But actually I thought we had more or less concluded that CREATE OR > REPLACE LANGUAGE would be acceptable (perhaps only if it's given > without any extra args?). Or for that matter there seems to be enough > opinion on the side of just installing plpgsql by default. CINE is > a

Re: [HACKERS] operator exclusion constraints

Jeff Davis writes: > On Tue, 2009-12-01 at 23:19 -0500, Robert Haas wrote: >> For parity with unique constraints, I think that the message: >> >> operator exclusion constraint violation detected: %s >> >> should be changed to: >> >> conflicting key value violates operator exclusion constraint "

Re: [HACKERS] Initial refactoring of plperl.c - rebased [PATCH]

Tim, Since there's a commitfest on right now, meaningful feedback on your patch could be delayed. Just so you know. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] First feature patch for plperl - draft [PATCH]

Building on my earlier plperl refactoring patch, here's a draft of my first plperl feature patch. Significant changes in this patch: - New GUC plperl.on_perl_init='...perl...' for admin use. - New GUC plperl.on_trusted_init='...perl...' for plperl user use. - New GUC plperl.on_untrusted_init='...

Re: [HACKERS] Ragged CSV import

Douglas, > 1. Copy to non-existent table - create it from the data type using most > generic datatypes Yes, that would be nice. Types chosen would pretty much have to be TEXT, NUMERIC, and TIMESTAMP for everything though; anything else is too variable. > 2. provide column mapping function - f

Re: [HACKERS] Adding support for SE-Linux security

> In words of one syllable: I do not care at all whether the NSA would use > Postgres, if they're not willing to come and help us build it. There's several 2-syllable words there. ;-) If we > tried to build it without their input, we'd probably not produce what > they want anyway. Yeah, the

Re: [HACKERS] Adding support for SE-Linux security

Andrew Dunstan wrote: > I think you have been remarkably good about our caution in accepting > this. You certainly have my admiration for your patience. Agreed. > What would probably help us a lot would be to know some names of large > users who want and will support this. NEC's name is a good st

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

Robert Haas wrote: I agree that search and replace isn't that hard, but I don't find the proposed construction awkward, and we have various uses of it in the docs already. Actually the COPY one is not quite clear whether it means <= 7.3 or < 7.3. Yeah, I wouldn't have suggested it if it made

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

On Thu, Dec 3, 2009 at 3:33 PM, Tom Lane wrote: > Robert Haas writes: >> I agree that search and replace isn't that hard, but I don't find the >> proposed construction awkward, and we have various uses of it in the >> docs already.  Actually the COPY one is not quite clear whether it >> means <=

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

Robert Haas writes: > I agree that search and replace isn't that hard, but I don't find the > proposed construction awkward, and we have various uses of it in the > docs already. Actually the COPY one is not quite clear whether it > means <= 7.3 or < 7.3. I think we're just aiming for consistenc

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

On Thu, Dec 3, 2009 at 2:25 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Dec 3, 2009 at 1:23 PM, Greg Smith wrote: >>> In this particular example, it's bad form because it's even possible that >>> 8.5 will actually be 9.0.  You don't want to refer to a version number that >>> doesn't eve

Re: [HACKERS] Block-level CRC checks

On Tue, Dec 1, 2009 at 1:27 PM, Joshua D. Drake wrote: > On Tue, 2009-12-01 at 13:20 -0500, Robert Haas wrote: > > Does $COMPETITOR offer this feature? > > > > My understanding is that MSSQL does. I am not sure about Oracle. Those > are the only two I run into (I don't run into MySQL at all). I kn

Re: [HACKERS] Aggregate ORDER BY patch

Hitoshi Harada escribió: > I found only trivial favors such like that a blank line is added > around line 595 in the patch, and "proj" in peraggstate sounds a > little weird to me because of surrounding "evaldesc" and "evalslot" > ("evalproj" seems better to me). Also catversion update doesn't mea

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

Robert Haas writes: > On Thu, Dec 3, 2009 at 1:23 PM, Greg Smith wrote: >> In this particular example, it's bad form because it's even possible that >> 8.5 will actually be 9.0.  You don't want to refer to a version number that >> doesn't even exist for sure yet, lest it leave a loose end that ne

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

On Thu, Dec 3, 2009 at 1:23 PM, Greg Smith wrote: > Robert Haas wrote: > On Thu, Dec 3, 2009 at 12:49 PM, Jaime Casanova > wrote: > > This manual will be specific for 8.5 so i think all mentions to the > version should be removed > > Not sure I agree on this point. We have similar mentions elsew

Re: [HACKERS] Catastrophic changes to PostgreSQL 8.4

> On Wed, Dec 2, 2009 at 10:49 PM, Adrian Klaver wrote: >> When I tried the above Postgres did not ignore the command, instead it gave >> me >> the following error and did not create the database: >> CREATE DATABASE bacula ENCODING 'SQL_ASCII'; >> ERROR: new encoding (SQL_ASCII) is incompatible

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

Robert Haas wrote: On Thu, Dec 3, 2009 at 12:49 PM, Jaime Casanova wrote: This manual will be specific for 8.5 so i think all mentions to the version should be removed Not sure I agree on this point. We have similar mentions elsewhere. In this particular example, it's bad form bec

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

On Thu, Dec 3, 2009 at 12:49 PM, Jaime Casanova wrote: > This manual will be specific for 8.5 so i think all mentions to the > version should be removed Not sure I agree on this point. We have similar mentions elsewhere. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: [HACKERS] [PATCH] Largeobject Access Controls (r2432)

2009/11/12 KaiGai Kohei : > The attached patch is a revised version of large object privileges > based on the feedbacks at the last commit fest. > please update the patch, it's giving an error when 'make check' is trying to "create template1" in initdb: creating template1 database in /home/postgr

Re: [HACKERS] Deleted WAL files held open by backends in Linux

"Kevin Grittner" wrote: > Any objections to my putting it on the TODO list? Hearing none, added. (Apologies for missing the box where I should have commented on the what the change did.) -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your s

Re: [HACKERS] RFC for adding typmods to functions

2009/12/3 Alvaro Herrera : > Pavel Stehule escribió: >> 2009/11/18 Peter Eisentraut : >> > On ons, 2009-11-18 at 11:46 +0100, Pavel Stehule wrote: >> >> I am not sure if SQL standard is good inspiration in this case. >> > >> > I'm not sure either, but I think it's premature to make a conclusion >>

Re: [HACKERS] patch - per-tablespace random_page_cost/seq_page_cost

On Sat, Nov 28, 2009 at 9:54 PM, David Rowley wrote: > Robert Haas Wrote: >> Hmm.  I'm not able to reliably detect a performance difference between >> unpatched CVS HEAD (er... git master branch) and same with spcoptions- >> v2.patch applied.  I figured that if there were going to be an impact, >>

Re: [HACKERS] Catastrophic changes to PostgreSQL 8.4

Greg Stark writes: >> CREATE DATABASE bacula ENCODING 'SQL_ASCII'; >> ERROR:  new encoding (SQL_ASCII) is incompatible with the encoding of the >> template database (UTF8) >> HINT:  Use the same encoding as in the template database, or use template0 as >> template. > Actually I'm kind of surprise

Re: [HACKERS] [GENERAL] pg_attribute.attnum - wrong column ordinal?

Alvaro Herrera writes: > Should we recast the attributes and columns views in information_schema? > I notice they still use attnum. I'd vote against it, at least until we have something better than a row_number solution. That would create another huge performance penalty on views that are alread

[HACKERS] I need some help from you

I sow that you have knoladge about advance programing softwere ,  I need an EBAY program ...     Please reply me back so I can give you more info about  what I need   Thank you

Re: [HACKERS] RFC for adding typmods to functions

Pavel Stehule escribió: > 2009/11/18 Peter Eisentraut : > > On ons, 2009-11-18 at 11:46 +0100, Pavel Stehule wrote: > >> I am not sure if SQL standard is good inspiration in this case. > > > > I'm not sure either, but I think it's premature to make a conclusion > > about that without having checked

Re: [HACKERS] Catastrophic changes to PostgreSQL 8.4

[moving this point to -hackers] On Wed, Dec 2, 2009 at 10:49 PM, Adrian Klaver wrote: > When I tried the above Postgres did not ignore the command, instead it gave me > the following error and did not create the database: > CREATE DATABASE bacula ENCODING 'SQL_ASCII'; > ERROR:  new encoding (SQL_

Re: [HACKERS] [GENERAL] pg_attribute.attnum - wrong column ordinal?

Greg Stark escribió: > On Wed, Nov 25, 2009 at 1:03 AM, Konstantin Izmailov wrote: > > > My question: can pg_attribute.attnum be used to determine the sequential > > ordinal positions of columns in a table? What is a right way to get the > > ordinal numbers? > > You could use something like: >

Re: [HACKERS] set the cost of an aggregate function

On Mon, 2009-11-30 at 11:53 -0500, Jaime Casanova wrote: > 2009/11/30 Jaime Casanova : > > Hi, > > > > why we can't do $subject? it could have any benefit on the planner? > > > > seems like while we can set the cost of the state transition function, > that cost is not propagated... The cost of co

Re: [HACKERS] Cost of sort/order by not estimated by the query planner

The table is clustered by by blog_id. So, for testing purpose, i tried an ORDER BY blog_id. limit 500 : - explain analyze SELECT * FROM _article WHERE (_article.bitfield && getbit(0)) ORDER BY _article.blog_id ASC LIMIT 500; Limit (cost=66229.90..66231.15 rows=500 width=1099) (act

Re: [HACKERS] Cost of sort/order by not estimated by the query planner

'morning ! And here is the query plan for : --- explain analyze SELECT * FROM _article WHERE (_article.bitfield && getbit(0)) ORDER BY _article.id ASC LIMIT 5; Limit (cost=0.00..2238.33 rows=5 width=1099) (actual time=17548636.326..17548837.082 rows=5 loops