Re: [HACKERS] ProcessUtility_hook

Tom Lane wrote: > ... and now that I have, I find at least four highly questionable > things about it: > > 1. The placement of the hook. Why is it three lines down in > ProcessUtility? It's probably reasonable to have the Assert first, > but I don't see why the hook function should have the a

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

2009/12/1 Laurent Laborde : > The problem is in the order by, of course. > If i remove the "order by" the LIMIT 5 is faster (0.044 ms) and do an > index scan. > At limit 500 (without order) it still use an index scan and it is > slightly slower. > At limit 5000 (without order) it switch to a Bitmap

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

Hi, Sorry if you receive this email a second time, Greg, i didn't notice it has not been sent to the hackers ML Thanks for your first review. I tried to work on most of the issues you noticed > 1) Needs tab/space formatting cleaned up This one is done, I adapted my environment to the Postgresql fo

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

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 like an (n-1)-way join and then do the cross join at the en

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

On Wed, Dec 2, 2009 at 10:32 PM, Tom Lane wrote: > Robert Haas writes: >> Not sure what you mean.  There's already a special-case code path for >> cross joins; but I think it's probably considering a lot of silly >> paths.  Is there a case where it makes sense to do cross joins at some >> stage o

Re: [HACKERS] CommitFest status/management

Robert Haas wrote: I'm happy with Andrew's interpretation --- I just want a separate text field for inserting a committer's name. I don't want any magic behavior of that field. OK, I'll add a separate text field for the committer's name, but for now it won't display on the summary page

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

Robert Haas writes: > Not sure what you mean. There's already a special-case code path for > cross joins; but I think it's probably considering a lot of silly > paths. Is there a case where it makes sense to do cross joins at some > stage of the process other than last? They *are* done last, as

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

On Wed, Dec 2, 2009 at 9:55 PM, Tom Lane wrote: >> One other thing I'm noticing about the current implementation is that >> it seems to spend an entirely excessive amount of brain power >> considering the best order in which to execute cross-joins.  If I do >> X, A JOIN B ON Pab JOIN C ON Pac JOIN

Re: [HACKERS] CommitFest status/management

On Tue, Dec 1, 2009 at 9:43 AM, Robert Haas wrote: > On Tue, Dec 1, 2009 at 9:42 AM, Tom Lane wrote: >> Robert Haas writes: >>> If we went with Bruce's interpretation, we could have a "committer" >>> field that only appears when the status is "Claimed by Committer" or >>> "Committed" and the con

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

Robert Haas writes: > Actually, I think Tom made some changes for 8.5 that should eliminate > the randomness, if not the badness. Or am I misremembering? It was mostly Andres' work, see http://archives.postgresql.org/pgsql-committers/2009-07/msg00148.php > One other thing I'm noticing about the

[HACKERS] Proposing new logline_prefix escape...

So... Came across a situation today where I would have liked to know the effective role of a query because of a permission error. When I went to add that to the logline_prefix, I realized that right now all we have is %u which gives you the equivalent of session_user...I think it would be useful

Re: [HACKERS] SE-PgSQL patch review

Ron Mayer wrote: > Joshua D. Drake wrote: >> On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote: >>> "Joshua D. Drake" writes: On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: > This is totally separate from the really important question of whether > SE-Linux has a future, and an

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

On Mon, Nov 30, 2009 at 11:53 AM, 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... I thought for sure

[HACKERS] Proposing new logline_prefix escape...

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So... Came across a situation today where I would have liked to know the effective role of a query because of a permission error. When I went to add that to the logline_prefix, I realized that right now all we have is %u which gives you the equivalen

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

On Wed, Dec 2, 2009 at 5:08 PM, Greg Sabino Mullane wrote: >>> What about 14? Could we at least raise it to 14? 1/2 :) > >> I doubt we can raise it at all without lying to ourselves about the >> likely results of so doing.  The GEQO planning times are in the low >> double digits of milliseconds.  

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

Ron Mayer wrote: > KaiGai Kohei wrote: >> Needless to say, NEC is also a supporter to develop and maintain >> SE-PgSQL feature. We believe it is a necessity feature to construct >> secure platform for SaaS/Cloud computing, so my corporation has funded >> to develop SE-PgSQL for more than two years.

Re: [HACKERS] SE-PgSQL patch review

Greg Stark wrote: > So I'm unclear what advantage this has for Redhat and sysadmins over > just setting up the database directly but then I'm unclear what the > advantage is for SELinux in the first place so I'm probably just not > in the target audience for it. But this seems like it would be > di

Re: [HACKERS] SE-PgSQL patch review

Joshua D. Drake wrote: > On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote: >> "Joshua D. Drake" writes: >>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote: This is totally separate from the really important question of whether SE-Linux has a future, and another about whether, if

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

KaiGai Kohei wrote: > Needless to say, NEC is also a supporter to develop and maintain > SE-PgSQL feature. We believe it is a necessity feature to construct > secure platform for SaaS/Cloud computing, so my corporation has funded > to develop SE-PgSQL for more than two years. Rather than "needless

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

KaiGai Kohei wrote:. > Needless to say, NEC is also a supporter to develop and maintain > SE-PgSQL feature. We believe it is a necessity feature to construct > secure platform for SaaS/Cloud computing, so my corporation has funded > to develop SE-PgSQL for more than two years. > > As I noted befo

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

Tom Lane wrote: > Josh Berkus writes: >> When GIS was introduced to this list ten years ago it was criticized as >> a marginal feature and huge and intrusive. But today it's probably 40% >> of our user base, and growing far more rapidly than anything else with >> Postgres. Maybe SE will be more

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

Josh Berkus wrote: > Bruce, > >> If we decide not to support SE-Linux, it is unlikely we will be adding >> support for any other external security systems because SE-Linux has the >> widest adoption. >> >> I think the big question is whether we are ready to extend Postgres to >> support additional

Re: [HACKERS] [PATCH] Windows x64

Stefan Kaltenbrunner escribió: > Tsutomu Yamada wrote: > >However, archive.postgresql.org has deleted the attachment. > >(Why? Email sent to the individual, the attachment is included.) > > > >Is it too large ? > >Should I resend them separately or compressing ? > >wrong mail format ? > >Should I

Re: [HACKERS] SE-PgSQL patch review

On Wed, Dec 2, 2009 at 3:30 AM, Tom Lane wrote: >  Red Hat's > policy has been trying to cope with cases like "which directories should > Apache be allowed to read, *given that it's running a Red-Hat-standard > configuration*?"  That's far more circumscribed than any useful database > policy would

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

"Greg Sabino Mullane" writes: >> The reason this is a configurable parameter is so that >> people can tune it to their own needs. I think the current >> default fits all right with our usual policy of being >> conservative about hardware requirements. > That only makes sense if you adjust it acc

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

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >> What about 14? Could we at least raise it to 14? 1/2 :) > I doubt we can raise it at all without lying to ourselves about the > likely results of so doing. The G

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

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > The reason this is a configurable parameter is so that > people can tune it to their own needs. I think the current > default fits all right with our usual policy of being > conservative about hardware requirement

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

On Wed, Dec 2, 2009 at 3:48 PM, Tom Lane wrote: > Greg Stark writes: >> This whole discussion is based on assumptions which do not match my >> recollection of the old discussion. I would suggest people go back and >> read the emails but it's clear at least some people have so it seems >> people g

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

On 12/2/09, James Mansion wrote: > Marko Kreen wrote: > > > Note - my proposal would be to get rid of HAVE_INLINE, which > > means we are already using inline functions unconditionally > > on platforms that matter (gcc). Keeping duplicate code > > for obsolete compilers is pointless. > > > > > M

Re: [HACKERS] YAML Was: CommitFest status/management

Ron Mayer writes: > Tom Lane wrote: >> Hmm. So the argument for it is "let's make a machine-readable format >> more human-readable"? I'm not getting the point. People should look >> at the regular text output. > IMHO YAML beats the regular text format for human-readability - > at least for peo

Re: [HACKERS] YAML Was: CommitFest status/management

2009/12/3 Ron Mayer : > Tom Lane wrote: >> Hmm.  So the argument for it is "let's make a machine-readable format >> more human-readable"?  I'm not getting the point.  People should look >> at the regular text output. > > IMHO YAML beats the regular text format for human-readability - > at least for

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

Greg Stark writes: > This whole discussion is based on assumptions which do not match my > recollection of the old discussion. I would suggest people go back and > read the emails but it's clear at least some people have so it seems > people get different things out of those old emails. My recolle

Re: [HACKERS] [CORE] EOL for 7.4?

On Wed, Dec 2, 2009 at 7:53 PM, Bruce Momjian wrote: >> At the moment it doesn't seem likely that pg_migrator is *ever* going >> to support upgrading from 7.4 or 8.0 or 8.1 to any later version. > > Agreed. The problem is that the development effort to migrate data that was never designed to be m

Re: [CORE] [HACKERS] EOL for 7.4?

Robert Haas wrote: Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because they necessarily want to, but they can't easily afford the downtime to upgrade. Cutting them off arbitrarily early won't win us any friends. Once pg_migrator (or better, in-place upgrades) is working

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

Josh Berkus writes: > When GIS was introduced to this list ten years ago it was criticized as > a marginal feature and huge and intrusive. But today it's probably 40% > of our user base, and growing far more rapidly than anything else with > Postgres. Maybe SE will be more like Rules than like G

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

On Wed, Dec 2, 2009 at 6:34 PM, Robert Haas wrote: >> Also, your logic seems to presume that no backports are possible to the old >> server. > > The problem on the table at the moment is that the proposed CRC > feature will expand every page by a uniform amount - so in this case a > fixed-space-pe

[HACKERS] Ragged CSV import

Hi, In sept 2009 there was a discussion of ragged csv import and import requirements. I thought I'd add my requirements to the heap. I'm working a QA solution for a dbms migration project that will import query output from a non PG database into PG, so we can compare query results between PG

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

On Wed, Dec 2, 2009 at 2:27 PM, Greg Smith wrote: > Robert Haas wrote: > > On Wed, Dec 2, 2009 at 1:56 PM, Greg Smith wrote: > > > There's no reason the associated catalog support had to ship with the old > version.  You can always modify the catalog after initdb, but before running > the pre-upg

Re: [HACKERS] [PATCH] bugfix for int2vectorin

New patch attached: 1. Does not add a new error message (though the pg_atoi's error message is a little goofy looking). 2. Handles int2 overflow cases. 3. oidvectorin does NOT suffer from the same problems as int2vectorin, someone already fixed it. As for the use-case I'm not completely sure...

Re: [HACKERS] YAML Was: CommitFest status/management

On Wed, 2009-12-02 at 10:45 -0800, Josh Berkus wrote: > All, > > If some people want it, and there's no significant maintenance burden > associated with YAML output, then why not? > > Mind you, if it was practical, I'd suggest that YAML ... and all > additional Explain formats ... should be a con

Re: [CORE] [HACKERS] EOL for 7.4?

Robert Haas wrote: > > Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because > > they necessarily want to, but they can't easily afford the downtime to > > upgrade. Cutting them off arbitrarily early won't win us any friends. Once > > pg_migrator (or better, in-place upgrades)

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

James Mansion writes: > Marko Kreen wrote: >> Note - my proposal would be to get rid of HAVE_INLINE, which >> means we are already using inline functions unconditionally >> on platforms that matter (gcc). Keeping duplicate code >> for obsolete compilers is pointless. > Microsoft C doesn't matter

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

Marko Kreen wrote: Note - my proposal would be to get rid of HAVE_INLINE, which means we are already using inline functions unconditionally on platforms that matter (gcc). Keeping duplicate code for obsolete compilers is pointless. Microsoft C doesn't matter? I seem to remember that when th

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

Robert Haas wrote: On Wed, Dec 2, 2009 at 1:56 PM, Greg Smith wrote: There's no reason the associated catalog support had to ship with the old version. You can always modify the catalog after initdb, but before running the pre-upgrade utility. pg_migrator might make that change for you.

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

On Wed, Dec 2, 2009 at 1:56 PM, Greg Smith wrote: > Robert Haas wrote: >>> Some additional catalog support was suggested to mark what the >>> pre-upgrade >>> utility had processed.   I'm sure I could find the messages about again >>> if I >>> had to. >> And that's a perfectly sensible solution, ex

Re: [CORE] [HACKERS] EOL for 7.4?

Dave Page wrote: > On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane wrote: >> >> ... 8.1 in RHEL5 ... +1 for letting 7.* and 8.0 die whenever no-one's motivated to bother supporting it anymore. > Presumably you'll be on the hook until 2014 for 8.1 security patches > I can't see the community wanting to

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

Robert Haas wrote: Some additional catalog support was suggested to mark what the pre-upgrade utility had processed. I'm sure I could find the messages about again if I had to. And that's a perfectly sensible solution, except that adding a catalog column to 8.4 at this point would force i

Re: [HACKERS] Aggregate ORDER BY patch

2009/11/30 Andrew Gierth : > Updated version of the aggregate order by patch. > > Includes docs + regression tests all in the same patch. > > Changes: > >  - removed SortGroupClause.implicit as per review comments, >    replacing it with separate lists for Aggref.aggorder and >    Aggref.aggdistinc

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

Bruce, > If we decide not to support SE-Linux, it is unlikely we will be adding > support for any other external security systems because SE-Linux has the > widest adoption. > > I think the big question is whether we are ready to extend Postgres to > support additional security infrastructures.

Re: [HACKERS] Block-level CRC checks

On tis, 2009-12-01 at 17:47 -0500, Tom Lane wrote: > Bruce Momjian writes: > > I also like the idea that we don't need to CRC check the line pointers > > because any corruption there is going to appear immediately. However, > > the bad news is that we wouldn't find the corruption until we try to

Re: [HACKERS] YAML Was: CommitFest status/management

All, If some people want it, and there's no significant maintenance burden associated with YAML output, then why not? Mind you, if it was practical, I'd suggest that YAML ... and all additional Explain formats ... should be a contrib module. Anything other than XML and JSON will be fairly margin

Re: [HACKERS] Block-level CRC checks

On tis, 2009-12-01 at 19:41 +, Greg Stark wrote: > > Also, it would > > require reading back each page as it's written to disk, which is OK > for > > a bunch of single-row writes, but for bulk data loads a significant > problem. > > Not sure what that really means for Postgres. It would just m

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

On Wed, Dec 2, 2009 at 1:08 PM, Greg Smith wrote: > Robert Haas wrote: >> >> The problem I'm referring to is that there is no guarantee that you >> would be able predict how much space to reserve.  In a case like CRCs, >> it may be as simple as "4 bytes".  But what if, say, we switch to a >> diffe

Re: [HACKERS] YAML Was: CommitFest status/management

Tom Lane wrote: > Andrew Dunstan writes: >> YAML... > > Hmm. So the argument for it is "let's make a machine-readable format > more human-readable"? I'm not getting the point. People should look > at the regular text output. IMHO YAML beats the regular text format for human-readability - at l

Re: [HACKERS] Hot Standby remaining issues

Simon Riggs wrote: > Hmm, what happens if someone enables wal_standby_info in postgresql.conf > while the server is shutdown. It would still be a valid starting point > in that case. Yeah, true. > I'll just make a note, I think. Yeah, a manual (or automatic, if you just wait) checkpoint will pro

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

Robert Haas wrote: The problem I'm referring to is that there is no guarantee that you would be able predict how much space to reserve. In a case like CRCs, it may be as simple as "4 bytes". But what if, say, we switch to a different compression algorithm for inline toast? Upthread, you made a

Re: [CORE] [HACKERS] EOL for 7.4?

On Wed, Dec 2, 2009 at 12:22 PM, Greg Sabino Mullane wrote: > Mark wrote: >> Doesn't mean that packagers have to make new packages ... I personally >> think new packages shouldn't be made for anything older then *maybe* 3 >> releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit >> e

Re: [CORE] [HACKERS] EOL for 7.4?

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Mark wrote: > Doesn't mean that packagers have to make new packages ... I personally > think new packages shouldn't be made for anything older then *maybe* 3 > re

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

On Wed, Dec 2, 2009 at 11:08 AM, Simon Riggs wrote: > On Wed, 2009-12-02 at 10:48 -0500, Robert Haas wrote: >> Well, that's sort of a circular argument.  If you're going to reserve >> space with a pre-upgrade utility, you're going to need to put the >> pre-upgrade utility into the version you want

Re: [HACKERS] Hot Standby remaining issues

On Wed, 2009-12-02 at 16:41 +, Simon Riggs wrote: > On Tue, 2009-12-01 at 20:26 +0200, Heikki Linnakangas wrote: > > Simon Riggs wrote: > > > commit 02c3eadb766201db084b668daa271db4a900adc9 > > > Author: Simon Riggs > > > Date: Sat Nov 28 06:23:33 2009 + > > > > > > Added wal_standb

Re: [HACKERS] Hot Standby remaining issues

On Tue, 2009-12-01 at 20:26 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > commit 02c3eadb766201db084b668daa271db4a900adc9 > > Author: Simon Riggs > > Date: Sat Nov 28 06:23:33 2009 + > > > > Added wal_standby_info GUC to turn RM_STANDBY_ID messages on/off. > > Various co

Re: [HACKERS] Re: [Pg-migrator-general] Composite types break pg_migrated tables

On Wed, Dec 2, 2009 at 11:28 AM, Bruce Momjian wrote: >> > >> > set next_pg_class_oid = 12345; >> > set next_pg_type_oid = 12346; >> > set next_toast_table_oid = ... >> > set next_toast_index_oid = ... >> > >> > and finally it could do CREATE TABLE. ?CREATE TYPE would only need >> > next_pg_type_o

Re: [HACKERS] Re: [Pg-migrator-general] Composite types break pg_migrated tables

Merlin Moncure wrote: > On Thu, Aug 6, 2009 at 9:28 AM, Tom Lane wrote: > > The half-formed idea I had was a set of GUC variables: > > > > set next_pg_class_oid = 12345; > > set next_pg_type_oid = 12346; > > set next_toast_table_oid = ... > > set next_toast_index_oid = ... > > > > and finally it c

Re: [HACKERS] Re: [Pg-migrator-general] Composite types break pg_migrated tables

Merlin Moncure writes: > Is this idea still on the table for 8.5? I've forgotten what the problem was? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-

Re: [HACKERS] Re: [Pg-migrator-general] Composite types break pg_migrated tables

On Thu, Aug 6, 2009 at 9:28 AM, Tom Lane wrote: > The half-formed idea I had was a set of GUC variables: > > set next_pg_class_oid = 12345; > set next_pg_type_oid = 12346; > set next_toast_table_oid = ... > set next_toast_index_oid = ... > > and finally it could do CREATE TABLE.  CREATE TYPE would

[HACKERS] Adding support for SE-Linux security

[ Updated subject ] We have been discussing support for SE-Linux for over a year and now have a minimal patch submitted that maps SE-Linux permissions to existing Postgres permissions: patch: http://momjian.us/tmp/sepgsql-01-lite-8.5devel-r2451.patch email: http://archives.postgresql.org/messag

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

On Wed, 2009-12-02 at 10:48 -0500, Robert Haas wrote: > Well, that's sort of a circular argument. If you're going to reserve > space with a pre-upgrade utility, you're going to need to put the > pre-upgrade utility into the version you want to upgrade FROM. If we > wanted to be able to use a pre-

Re: [HACKERS] YAML Was: CommitFest status/management

Andrew Dunstan writes: > YAML and JSON are pretty much interchangeable for our purposes. > According to Wikipedia, "Both functionally and syntactically, JSON is > effectively a subset of YAML." See > So the YAML parsers should be > able to handle the JS

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

On Tue, Dec 1, 2009 at 11:45 PM, Bruce Momjian wrote: > Robert Haas wrote: >> >> The key issue, as I think Heikki identified at the time, is to figure >> >> out how you're eventually going to get rid of the old pages. ?He >> >> proposed running a pre-upgrade utility on each page to reserve the >>

Re: [HACKERS] Application name patch - v4

Magnus Hagander writes: > 2009/12/2 Tom Lane : >> BTW, it strikes me that it would only be a matter of a couple of lines >> to persuade older servers to ignore application_name in the startup >> packet, instead of throwing a tantrum.  Obviously we must make libpq >> work against unpatched older se

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

I've attached an update of my previous refactoring of plperl.c. It's been rebased over the current (git) HEAD and has a few very minor additions. Background: I've started work on the enhancements to plperl I outlined on pg-general (in the "Wishlist of PL/Perl Enhancements for 8.5" thread). I have

Re: [HACKERS] compile error with -DOPTIMIZER_DEBUG

Tom Lane wrote: > Heikki Linnakangas writes: > > Jan Urbański wrote: > >> ISTM that there's a superfluous curly brace in print_path (which only > >> gets compiled with -DOPTIMIZER_DEBUG. > > > Thanks, committed. > > You know, the last couple of times I've touched that code, I've been > wondering

Re: [HACKERS] YAML Was: CommitFest status/management

Josh Berkus wrote: On 11/30/09 8:17 PM, Andrew Dunstan wrote: Do we have consensus yet that we want YAML? It seemed, well, yet another format without all that much advantage over what's there. Well, what's the code count? What dependencies, if any, does it add? The patch its

Re: [HACKERS] Page-level version upgrade

Greg Stark writes: > On Wed, Dec 2, 2009 at 11:26 AM, Dimitri Fontaine > wrote: >> We already have had demand for read only tables (some on-disk format >> optimisation would then be possible). What about having page level >> read-only restriction, thus allowing the newer server version to operate

Re: [HACKERS] enable-thread-safety defaults?

Bruce Momjian wrote: > > It would seem like we ought to try the one-liner patch Magnus proposed > > (ie flip the default) and see what the effects are, before we go with > > the much larger patch Bruce wrote. > > OK, done --- let the breakage begin. (I will be monitoring the build > farm and will

Re: [HACKERS] Page-level version upgrade (was: Block-level CRC checks)

David Fetter wrote: > > Right. There were two basic approaches to handling a patch that > > would expand when upgraded to the new version --- either allow the > > system to write the old format, or have a pre-upgrade script that > > moved tuples so there was guaranteed enough free space in every p

Re: [HACKERS] Page-level version upgrade

On Wed, Dec 2, 2009 at 11:26 AM, Dimitri Fontaine wrote: > We already have had demand for read only tables (some on-disk format > optimisation would then be possible). What about having page level > read-only restriction, thus allowing the newer server version to operate > in read-only mode on the

Re: [HACKERS] operator exclusion constraints

On Wed, Dec 2, 2009 at 12:18 AM, Jeff Davis wrote: > 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 op

Re: [HACKERS] PL/Python array support

On Fri, Nov 20, 2009 at 12:00:24AM +0200, Peter Eisentraut wrote: > On fre, 2009-11-13 at 18:46 +0300, Teodor Sigaev wrote: > > CREATE OR REPLACE FUNCTION incr(stuff int[]) RETURNS int[] AS $$ > > for x in stuff: > > yield x+1 > > $$ > > LANGUAGE 'plpythonu'; > > > > # select incr(ARRAY[1,2,3

Re: [HACKERS] Page-level version upgrade

Hi, As we're talking about crazy ideas... Bruce Momjian writes: > Well, yea, the idea would be that the 8.5 server would either convert > the page to the new format on read (assuming there is enough free space, > perhaps requiring a pre-upgrade script), or have the server write the > page in the

Re: [HACKERS] Hot Standby remaining issues

Simon Riggs wrote: > On Wed, 2009-12-02 at 12:49 +0200, Heikki Linnakangas wrote: > >> If a read-only transaction holds a lot of locks, consuming so much >> lock space that there's none left for the startup process to hold the >> lock it wants, it will abort and bring down postmaster. The patch >>

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

hummm Adding pgsql-perf :) On Mon, Nov 30, 2009 at 5:54 PM, Laurent Laborde wrote: > Friendly greetings ! > I use postgresql 8.3.6. > > here is a few info about the table i'm querying : > - > - select count(*) from _article : 1730161

Re: [HACKERS] Hot Standby remaining issues

On Wed, 2009-12-02 at 12:49 +0200, Heikki Linnakangas wrote: > If a read-only transaction holds a lot of locks, consuming so much > lock space that there's none left for the startup process to hold the > lock it wants, it will abort and bring down postmaster. The patch > attempts to kill any confl

Re: [HACKERS] Hot Standby remaining issues

Heikki Linnakangas wrote: > Simon Riggs wrote: >> @@ -654,10 +656,13 @@ LockAcquire(const LOCKTAG *locktag, >> elog(PANIC, "lock table corrupted"); >> } >> LWLockRelease(partitionLock); >> -ereport(ERROR, >> -

Re: [HACKERS] cannot compile CVS HEAD

2009/12/2 Heikki Linnakangas : > Pavel Stehule wrote: >> I have a problem with compilation: >> >> make[4]: Entering directory `/home/pavel/src/pgsql/src/backend/utils/adt' >> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith >> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing >> -

Re: [HACKERS] cannot compile CVS HEAD

Pavel Stehule wrote: > I have a problem with compilation: > > make[4]: Entering directory `/home/pavel/src/pgsql/src/backend/utils/adt' > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing > -fwrapv -I../../../../src/include -D_GN

Re: [HACKERS] [PATCH] Windows x64

Tsutomu Yamada wrote: Robert Haas wrote: > On Tue, Dec 1, 2009 at 6:25 AM, Tsutomu Yamada wrote: > > Hello. > > > > The following patches support Windows x64. > > > > 1) use intptr_t for Datum and pointer macros. (to support Windows LLP64) > > almost the same as that post before. > >

Re: [HACKERS] [PATCH] Windows x64

Robert Haas wrote: > On Tue, Dec 1, 2009 at 6:25 AM, Tsutomu Yamada wrote: > > Hello. > > > > The following patches support Windows x64. > > > > 1) use intptr_t for Datum and pointer macros. (to support Windows LLP64) > > almost the same as that post before. > > http://archives.postgr

[HACKERS] cannot compile CVS HEAD

Hello I have a problem with compilation: make[4]: Entering directory `/home/pavel/src/pgsql/src/backend/utils/adt' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -I../../../../src/include -D_GNU_SOURCE -c -o int.o int

Re: [HACKERS] Application name patch - v4

On Wed, Dec 2, 2009 at 8:14 AM, Magnus Hagander wrote: >> If we patch the back branches like that, anyone who's annoyed by the >> extra connection cycle just has to update to latest minor release >> of their server to make it work more smoothly.  Comments? >> >>                        regards, to

Re: [HACKERS] add more frame types in window functions (ROWS)

> "Hitoshi" == Hitoshi Harada writes: Hitoshi> As earlier mail, I added aggcontext to WindowAggState. This issue (as detailed in this post): http://archives.postgresql.org/pgsql-hackers/2009-11/msg01871.php is currently the only significant outstanding issue in my review of this patch. I t

Re: [HACKERS] Application name patch - v4

2009/12/2 Tom Lane : > Dave Page writes: >> On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane wrote: >>> I don't think that we need to bump the protocol version.  The real >>> alternative here would be that libpq sends a startup packet that >>> includes application_name, and if it gets an error back from