Re: [HACKERS] PL/Perl: spi_prepare() and RETURNING
On 8/27/06, Tom Lane <[EMAIL PROTECTED]> wrote: I've applied a patch along these lines. David's plperl example now does what (I think) he expected. Kewl. Thanks Tom. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] jabber.postgresql.org is up
On Sun, Aug 27, 2006 at 08:49:21PM -0700, Joshua D. Drake wrote: > AgentM wrote: > >Sorry, but I don't get it. Why offer a closed forum for an open project? Open source developers already send private emails, private instant messages, or join private chat rooms. > Because jabber is a live medium, unlike email. I don't want people > pinging me, out of the blue. It is the whole reason I don't use any of > the public networks. The point is for the people who are actually part > of the project infrastructure to be able to communicate. > In the end it will likely be opened up more, but for now we are taking > baby steps. Assuming the conversations are not secret, and they are being used for an official purpose, should they not be displayed as a public log, accessible from a www.postgresl.org? Baby steps that are away from an open model would serve to discourage public knowledge or public contribution. I find myself already surprised about features finding their way into PostgreSQL. Most often the surprise is pleasant, however, it seems there is a disconnect in the communication if somebody monitoring the mailing lists cannot determine what will be included in, say, PostgreSQL 8.2, without asking "what will be in PostgreSQL 8.2?" Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
Tom Lane wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: I just detected another problem with building ecpg in a VPATH environment. This patch fixes it for me. Can't we get some of the buildfarm machines exercising VPATH? This kinda stuff really ought to be found immediately. I will set one up tomorrow. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] jabber.postgresql.org is up
AgentM wrote: Sorry, but I don't get it. Why offer a closed forum for an open project? Because jabber is a live medium, unlike email. I don't want people pinging me, out of the blue. It is the whole reason I don't use any of the public networks. The point is for the people who are actually part of the project infrastructure to be able to communicate. In the end it will likely be opened up more, but for now we are taking baby steps. SIncerely, Joshua D. Drake -M On Aug 27, 2006, at 24:48 , Joshua D. Drake wrote: Hello, The community jabber server is now up. We are using the Wildfire server from Jive Software, backed to a PostgreSQL database (of course). -- The idea behind this server is to allow active project members to communicate without having to use public channels. If you are a project member (Gforge admin, Web team member, commiter etc...) please let me know if you would like an account. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I just detected another problem with building ecpg in a VPATH > environment. This patch fixes it for me. Can't we get some of the buildfarm machines exercising VPATH? This kinda stuff really ought to be found immediately. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg
Alvaro Herrera wrote: > I just detected another problem with building ecpg in a VPATH > environment. This patch fixes it for me. I think you will find that $(top_builddir)/$(subdir) is equivalent to "." -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] jabber.postgresql.org is up
Sorry, but I don't get it. Why offer a closed forum for an open project? -M On Aug 27, 2006, at 24:48 , Joshua D. Drake wrote: Hello, The community jabber server is now up. We are using the Wildfire server from Jive Software, backed to a PostgreSQL database (of course). -- The idea behind this server is to allow active project members to communicate without having to use public channels. If you are a project member (Gforge admin, Web team member, commiter etc...) please let me know if you would like an account. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] integration of pgcluster into postgresql
The idea of hooks sounds quite good to me indeed. The issue is not PR, it's indeed pgcluster benefiting from the maintenance of postgresql and avoiding the hassle of having to resync its code at each postgresql change. I will propose something along those lines once I get a more stable pgcluster and have a better grasp at all details of its code. I could send a mail to the slony and gorda people at that point to see if they're interested in coordinating efforts. --- Tom Lane <[EMAIL PROTECTED]> wrote: > "Jonah H. Harris" <[EMAIL PROTECTED]> writes: > > On 8/27/06, Alvaro Herrera > <[EMAIL PROTECTED]> wrote: > >> ... or the pgcluster group could check the hook > list posted by the GORDA > >> project guys. In fact IIRC that patch was > committed already, without > >> much discussion? > > > I thought the GORDA patch got turned down because > there was no > > communication between replication providers. > > Exactly; we asked for some evidence that these > particular hook > definitions were generally useful. So it seems like > a joint > pgcluster/GORDA/Slony proposal would go over a lot > better. > > regards, tom lane > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PL/Perl: spi_prepare() and RETURNING
"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > On 8/24/06, Tom Lane <[EMAIL PROTECTED]> wrote: >> This reminds me of a consideration I had been intending to bring up on >> the mailing lists: what exactly do we want to do with the SPI API for >> RETURNING queries? > I like adding RETURNING-specific return codes. >> Another issue I noted in that same area is that spi.c does not set >> SPI_processed for a utility statement, even if the utility statement >> returns tuples. Is this a bug, or should we leave it alone? > I think it's a bug. I've applied a patch along these lines. David's plperl example now does what (I think) he expected. Does anyone want to extend the plperl, pltcl, plpython regression tests to check behavior with INSERT RETURNING etc? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] integration of pgcluster into postgresql
"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > On 8/27/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: >> ... or the pgcluster group could check the hook list posted by the GORDA >> project guys. In fact IIRC that patch was committed already, without >> much discussion? > I thought the GORDA patch got turned down because there was no > communication between replication providers. Exactly; we asked for some evidence that these particular hook definitions were generally useful. So it seems like a joint pgcluster/GORDA/Slony proposal would go over a lot better. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Tricky bugs in concurrent index build
I wrote: > I'm toying with the idea of adding a lock manager call defined as > "give me a list of XIDs that currently hold locks conflicting with > lockmode X on object Y" --- but not including XIDs merely waiting > for such a lock. Then we could get the list of XIDs currently blocking > ExclusiveLock, and do XactLockTableWait on each one. I've committed a patch along these lines. I also reduced the strength of the lock we check for from ExclusiveLock to ShareLock, which seems sufficient --- did you have a reason for selecting ExclusiveLock in the original coding? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] integration of pgcluster into postgresql
On 8/27/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: ... or the pgcluster group could check the hook list posted by the GORDA project guys. In fact IIRC that patch was committed already, without much discussion? I thought the GORDA patch got turned down because there was no communication between replication providers. Although, I do like the trigger hooks GORDA provides. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] integration of pgcluster into postgresql
Peter Eisentraut wrote: > Tom Lane wrote: > > So I'd want to see some kind of joint proposal by multiple > > replication projects about what hooks to add. Anybody out there want > > to organize such a thing? > > Well, at least the pgcluster group could come up with a rough list of > required hooks, and then the other groups can judge whether that list > can be shaped into something universally useful or whether it's > completely useless to them. ... or the pgcluster group could check the hook list posted by the GORDA project guys. In fact IIRC that patch was committed already, without much discussion? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Trivial patch to double vacuum speed on tables with no indexes
Gregory Stark <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> How often does that case come up in the real world, for tables that are >> large enough that you'd care about vacuum performance? > I would have had the same objection if it resulted in substantially more > complex code but it was so simple that it doesn't seem like a concern. The reason the patch is so short is that it's a kluge. If we really cared about supporting this case, more wide-ranging changes would be needed (eg, there's no need to eat maintenance_work_mem worth of RAM for the dead-TIDs array); and a decent respect to the opinions of mankind would require some attention to updating the header comments and function descriptions, too. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] integration of pgcluster into postgresql
Tom Lane wrote: > So I'd want to see some kind of joint proposal by multiple > replication projects about what hooks to add. Anybody out there want > to organize such a thing? Well, at least the pgcluster group could come up with a rough list of required hooks, and then the other groups can judge whether that list can be shaped into something universally useful or whether it's completely useless to them. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Trivial patch to double vacuum speed on tables with no indexes
Tom Lane <[EMAIL PROTECTED]> writes: > stark <[EMAIL PROTECTED]> writes: >> There isn't really any need for the second pass in lazy vacuum if the table >> has no indexes. > > How often does that case come up in the real world, for tables that are > large enough that you'd care about vacuum performance? Admittedly it's not the most common scenario. But it does come up. ETL applications for example that load data, then perform some manipulation of the data before loading the data. If they have many updates to do they'll probably have to do vacuums between some of them. Arguably if you don't have any indexes on a large table it's quite likely to be *because* you're planning on doing some big updates such that it'll be faster to simply rebuild the indexes when you're done anyways. I would have had the same objection if it resulted in substantially more complex code but it was so simple that it doesn't seem like a concern. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] integration of pgcluster into postgresql
Andreas Pflug <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> My take on all this is that there's no one-size-fits-all replication >> solution, and therefore the right approach is to have multiple active >> subprojects. > Anybody knowing a little about the world of replication needs will > agree with you here. Unfortunately, AFAICS pgcluster can't be added as > module as e.g. Slony-I, since it's rather a not-so-small patch to the > pgsql sources. So I wonder if it's possible to provide some > not-too-intrusive hooks in core pgsql, enabling pgcluster to do most of > the work in modules, to have the best of both worlds: core with as few > modifications as possible, and modules extending the operation, > profiting from backend development immediately. I don't have any objection in principle to adding hooks that're needed by replication projects. But again, I don't want the core project to be seen as favoring some replication projects over others. So I'd want to see some kind of joint proposal by multiple replication projects about what hooks to add. Anybody out there want to organize such a thing? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Trivial patch to double vacuum speed on tables with no indexes
stark <[EMAIL PROTECTED]> writes: > There isn't really any need for the second pass in lazy vacuum if the table > has no indexes. How often does that case come up in the real world, for tables that are large enough that you'd care about vacuum performance? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [Open Item] Re: [HACKERS] Autovacuum on by default?
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > If we've got command stats turned on by default now, I'll have a hard > time buying performance as any reason to turn the others off. That's a mistaken argument, because the reason stats_command_string is now on is that it was reimplemented in a way that has basically nothing to do with the stats subsystem ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] integration of pgcluster into postgresql
Tom Lane wrote: > > My take on all this is that there's no one-size-fits-all replication > solution, and therefore the right approach is to have multiple active > subprojects. Anybody knowing a little about the world of replication needs will agree with you here. Unfortunately, AFAICS pgcluster can't be added as module as e.g. Slony-I, since it's rather a not-so-small patch to the pgsql sources. So I wonder if it's possible to provide some not-too-intrusive hooks in core pgsql, enabling pgcluster to do most of the work in modules, to have the best of both worlds: core with as few modifications as possible, and modules extending the operation, profiting from backend development immediately. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Adding fulldisjunctions to the contrib
On 8/27/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote: Well, make a list and tell the admins to delete those projects. Alright. When I come across one, I'll forward it on. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Adding fulldisjunctions to the contrib
Jonah H. Harris wrote: > I'm not saying that *everything* on pgfoundry is junk... but I can > start naming dead projects if you'd like. Well, make a list and tell the admins to delete those projects. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] integration of pgcluster into postgresql
On 8/27/06, Gregory Stark <[EMAIL PROTECTED]> wrote: I'm beginning to wonder whether it would be better from a PR perspective to rename pgfoundry to something like modules.postgresql.org. While "modules" isn't necessarily technically right in postgresql vocabulary it's right in the more general sense And it doesn't imply the pieces of code are still in progress like "projects.postgresql.org" might and doesn't give the impression that they're living on their own without support from other postgres people like having a separate domain does. I don't know what the name should be but we should at least be consistent between pgFoundry and websites hosted on pgFoundry. Currently we have http://pgcluster.projects.postgresql.org/ for the website hosted on pgFoundry and http://pgfoundry.org/projects/pgcluster for the project itself (yes, Jonah, they are both pgFoundry stuff, it's just that the website is probably not maintained by pgcluster staff currently). I agree with Gregory that renaming pgfoundry.org to [whatever].postgresql.org could be a good idea to make it more "official". And project sites should keep their projectname.[whatever].postgresql.org address. -- Guillaume ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] [HACKERS] New XML section for documentation
David Fetter wrote: > I think it's useful to mention what's arriving, what's being worked > on, and what's not even being contemplated in the long term. We don't even have a roadmap of any kind, so the last thing we can do is put claims of that sort in the documentation. > Similar troubles apply--on a smaller scale--to the information > schema, SQL/OLB, SQL/JRT, etc. The information schema is quite extensively documentated. If you have something to add on OLB and JRT, then let's hear your suggestions. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] integration of pgcluster into postgresql
Tom Lane <[EMAIL PROTECTED]> writes: >> That said, my company would feel more confortable with the idea that it's >> part of the postgresql mainstream distro for many obvious reasons - or we >> might drop postgresql altogether - which is why I'm proposing myself to do >> the necessary work to integrate it in postgresql if there's interest. > > The core development team has only a very finite number of cycles available. > Would you rather we spend our time on fixing pgcluster than on fixing the > core Postgres database? I'm beginning to wonder whether it would be better from a PR perspective to rename pgfoundry to something like modules.postgresql.org. While "modules" isn't necessarily technically right in postgresql vocabulary it's right in the more general sense And it doesn't imply the pieces of code are still in progress like "projects.postgresql.org" might and doesn't give the impression that they're living on their own without support from other postgres people like having a separate domain does. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
