Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 1:16 AM, Josh Berkusj...@agliodbs.com wrote: Hmmm ... actually, I think Andrew's right that we don't need a specific last commitfest rule which is special. Really, any patch which gets submitted to any commitfest gets returned if it's not ready to be committed immediately after review. The only way the last CF is special is that anything bounced goes to the next version. We forgot that with the November CF, which is why it dragged on for 3.5 months and burned a lot of people out. Let's just stick to that this time and we don't need any new rules. Ugh, I disagree. I agree that we were too generous with letting people rework patches while the CommitFest was in progress (mostly, we let people drop off the map for 3 weeks and then come back and say, oh, here's my revised version). But you have to allow a certain amount of reworking as the CommitFest progresses, I think. Otherwise, it just takes way too long to get anything done. Suppose someone submits a patch that has minor issues to the first CommitFest. The reviewer points the issues he sees, so the author fixes the patch up and resubmits to the second CommitFest. The patch is now assigned for review again (possibly to a different reviewer), and one more minor issue is discovered, so the author fixes up the patch again and resubmits to the third CommitFest. Upon third review, it's discovered that one of the comments is poorly written, so the author fixes it up again and resubmits to the final CommitFest, whereupon it is committed. That's about 7 months to get that patch committed, and it would be twice that if the initial commitfest was to the SECOND commitfest rather than the first, since the release cycle would intervene. What should actually happen is that the whole thing should be handled by a single reviewer during one CommitFest. It's much easier to re-review a patch that you've read through just a few days prior than it is to review a whole new patch from scratch, so I don't think it's imposing an undue burden on the reviewers; in fact it should produce a net REDUCTION in work by concentrating all the work for a particular patch into a relatively compact period of time. What WAS a big problem during the last CommitFest, at least for me, was resubmits that didn't happen promptly. I couldn't decide whether I should continue starting to review new patches, or whether that would lead to chaos when all the resubmits from the ones I'd previously reviewed came back around, leaving me with 4 or 5 patches that all needed to be reviewed at the same time. So I'm strongly in favor of a very firm deadline for resubmits: except for very large patches like HS, resubmits should be required within, say, 96 hours of the time the review hits the list; otherwise, we bump it. Basically, if we're too quick to bump patches to the next CommitFest, there will be only moderate resistance for the first N-1 CommitFests, but then for the last CommitFest people won't want to be bumped by a whole major release for what are basically minor issues. So we'll be back in a situation where the last CommitFest is the pits. We have to find a middle ground where we're bumping things that are truly holding things up (tying up reviewer resources or unduly lengthening the CommitFest) but at the same time avoid bumping things so quickly that we don't really provide a patch authors with a fair shake at getting something committed in a reasonable period of time. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, 2009-06-30 at 21:04 +0300, Heikki Linnakangas wrote: Merlin Moncure wrote: Given that there is also a lot of work on synchronous replication, is it better to get the HS in so the SR stuff can use that as a baseline, or to triage in both patches together? Whichever finishes first. Although they're very useful together, there is little if any code-level dependency between them. It would be dangerous to have one wait for the other, as one or the other could well be delayed for some reason. We can't even be sure that both are finished in time for 8.5. Code dependency is not the main worry. Developer and committer time and attention is our scarcest resource and I expect it to remain so. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, 2009-06-30 at 09:35 -0400, Robert Haas wrote: In any case, we probably need some weigh-in from Heikki and Simon on their plans for Hot Standby before we make any decisions... We discussed this at the developer meeting in May. I gave a clear commitment to getting Hot Standby into Postgres, and a wish to see it in 8.5. I'm going to attempt to get Sync Rep into core first, then Hot Standby. There are not too many people that have good insight in these areas and I think we need them all working together to successfully commit anything to Postgres core that we all agree with. I believe its possible that individuals may produce working solutions on their own, though I also believe that constructive teamwork can produce better solutions. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
Hi, While backporting UUID stuff to 8.2 where I'll need it (I wish I could have more impact on PostgreSQL upgrade schedules... who doesn't), I faced a problem I didn't foresee, and that we maybe should think about. http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/backports/ The idea in this backport is to have UUID as an extension to 8.2, which was plain easy to do once you remember about adding the PG_FUNCTION_INFO_V1() macro calls where they fit. Then there's the uuid-ossp contrib stuff, already packaged as an extension, but with code dependancy to the UUID provided functions (uuid_in, uuid_out). What I ended up doing was duplicating code in order not to have to tweak local_preload_libraries, so that uuid-ossp.so is self-contained. Any advice or missing knowledge about loading modules which depends on code from another module not already loaded in the backend is welcome :) Josh Berkus j...@agliodbs.com writes: - dependancy graph solving and automatic installation, with depends, recommends and suggest sections and with rules/setup to choose what to pull in by default... Uh-huh. That'll be the day ... So it seems we will have to teach the extension facility about loading dependant extensions first when calling a function, which I guess we can do as soon as we have the dependancies information in there? (calling a function from 'MODULE_PATHNAME' will have the .so loaded, so I guess than knowing it depends on another 'MODULE_PATHNAME' will enable us to load those first) Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, 2009-06-30 at 08:33 +0300, Peter Eisentraut wrote: Now that 8.4.0 is out the door, development for 8.5devel will be opened any day now. But we haven't discussed the development timeline so far. This is a wonderful thing. Development opening quickly and the idea of a discussed and explicit dev schedule are both good news. The differences between proposed schedules seems fairly small, so I have no comment on them other than expressing happiness that they exist. Thanks. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, 2009-07-01 at 02:14 -0400, Robert Haas wrote: Basically, if we're too quick to bump patches to the next CommitFest, there will be only moderate resistance for the first N-1 CommitFests, but then for the last CommitFest people won't want to be bumped by a whole major release for what are basically minor issues. That is an important point. Remember we are talking about non-committers here. Each commitfest needs to be about wrangling in the patches that are exact or nearly there. Nothing is perfect, especially when the definition of perfection is not controlled by the patch author. How can anybody know what will or will not be objected to until the patch is reviewed? Committers don't submit perfect patches, they apply them piece by piece, with comments about I'll get back to that or still thinking of best way to do it.. Look at the way FOREIGN DATA WRAPPERS got in. Half a feature, piece by piece (I have zero objection to that, just an example). Saying that non-committers need to submit perfect patches or we reject them just ends up with a pile up. Expecting people that haven't passed a the bar exam to provide a higher standard of code than those that have passed the test is obviously not going to work. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
and...@dunslane.net (Andrew Dunstan) writes: Jeff Davis wrote: On Mon, 2009-06-29 at 12:55 -0400, Tom Lane wrote: I think it has to be looked at in comparison to more general prospective-permissions schemes; When I searched google for prospective permissions, all I found were links to messages in this thread ;) Can you refer me to a general prospective-permissions scheme that is more widely accepted? Being more widely accepted also has the benefit that users will feel more comfortable with the behavior. Think of MySQL's wildcard permissions. They apply to any object whether that object is created before or after the rule is set, AIUI. That means the wildcard pattern is applied at the time the permission rule is referenced, rather than when the rule is created, thus applying it prospectively. It's a feature many users would like to have, although, as Tom rightly points out, it can be a bit of a footgun if used carelessly. I'll point out, for posterity, that way back in yesteryear, TOPS-10 (introduced in 1967) had a declarative permissioning system for file access that resembles this. The best description I'm aware of is the following: http://lkml.org/lkml/1999/2/5/2 A FILDAE config file for a particular user might look like the following: # anything in a directory named private is off limits */private/*:*:*:*: # people in group foo get full (create, delete, read, write, # execute) access to everything in the foo project directory ~/projects/foo/*:*:foo:*:cdrwx # people playing mygame can update the high score file ~/mygame/score.dat:*:*: ~/mygame/bin/mygame:rw # some friends have access to the RCS files for mygame ~/mygame/src/RCS/*:dennis,kevin,josh:*: /usr/bin/ci:rw ~/mygame/src/RCS/*:dennis,kevin,josh:*: /usr/bin/co:rw # I'll put stuff I want everyone to read in my ~/public directory # I'll make the public directory 744, so no one will actually have # to check .access_list, but I'll still put in this entry for completeness ~/public/*:*:*:*:r# anything left over gets no access*:*:*:*: This obviously isn't notably SQL-like, but that's not the point :-). -- cbbrowne,@,cbbrowne.com http://www3.sympatico.ca/cbbrowne/lisp.html Ubuntu is an ancient African word, meaning can't configure Debian -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] gin--a rule for function parameter
version: PG8.2.2 MY Question: Why must take the same number of parameters ? We can check that all the referenced instances of the same support routine number take the same number of parameters ? 1 there is no results by running regress test as follow: plsql/src/test/regress/sql/opr_sanity.sql .. -- Unfortunately, we can't check the amproc link very well because the -- signature of the function may be different for different support routines -- or different base data types. -- We can check that all the referenced instances of the same support -- routine number take the same number of parameters, but that's about it -- for a general check... SELECT p1.amopclaid, p1.amprocnum, p2.oid, p2.proname, p3.opcname, p4.amopclaid, p4.amprocnum, p5.oid, p5.proname, p6.opcname FROM sys_amproc AS p1, sys_proc AS p2, sys_opclass AS p3, sys_amproc AS p4, sys_proc AS p5, sys_opclass AS p6 WHERE p1.amopclaid = p3.oid AND p4.amopclaid = p6.oid AND p3.opcamid = p6.opcamid AND p1.amprocnum = p4.amprocnum AND p1.amproc = p2.oid AND p4.amproc = p5.oid AND (p2.proretset OR p5.proretset OR p2.pronargs != p5.pronargs); But, contrib\tsearch2\tsearch.sql.in: ... CREATE OPERATOR CLASS gin_tsvector_ops DEFAULT FOR TYPE tsvector USING gin AS OPERATOR1 @@ (tsvector, tsquery), OPERATOR2 @@@ (tsvector, tsquery) RECHECK, FUNCTION1 bttextcmp(text, text), FUNCTION2 gin_extract_tsvector(tsvector,internal), FUNCTION3 gin_extract_tsquery(tsquery,internal,internal), FUNCTION4 gin_ts_consistent(internal,internal,tsquery), STORAGE text; When I use tsearch2, I found that gin_extract_tsquery() has 3 parameters, it break the rule take the same number of parameters. So, who can tell me whether the rule is right? Grateful, Fly.Li for example, ginarrayextract function has two parameters -- amopclaid | amprocnum | oid | proname | opcname | amopclaid | amprocnum | oid | proname | opcname ---+---+--+-+--+---+---+--+-+-- 2771 | 3 | 2743 | ginarrayextract | _oidvector_ops -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
Dimitri Fontaine dfonta...@hi-media.com writes: Any advice or missing knowledge about loading modules which depends on code from another module not already loaded in the backend is welcome :) You should be able to configure the dynamic loader to do that, although in the case of uuid I strongly doubt it's worth the trouble. Duplicated code would be a lot simpler to manage ... 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-hackers
Re: [HACKERS] gin--a rule for function parameter
Fly.Li fly...@126.com writes: version: PG8.2.2 MY Question: Why must take the same number of parameters ? Because the GIN code will call it with a particular number of arguments. When I use tsearch2, I found that gin_extract_tsquery() has 3 parameters, it break the rule take the same number of parameters. 3 is the correct number of parameters for an extractQuery function (before 8.4 anyway), so I'm not clear what you are complaining about. 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-hackers
Re: [HACKERS] Extensions User Design
Tom Lane t...@sss.pgh.pa.us writes: You should be able to configure the dynamic loader to do that, although in the case of uuid I strongly doubt it's worth the trouble. In the context of the extensions facility, will we be able to do this configuration automatically from the backend, or to manually load any dependant .so? Duplicated code would be a lot simpler to manage ... Ok, I'll keep it this way then. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us wrote: I realize there is the perception that the large patches that were eventually rejected held up the release, but for all the patches I can think of, they were not rejected immediately _because_ we had other valid patches to work on. Once all valid patches were applied, we were quickly able to reject the large unready patches. So, rejecting the large patches earily would not have significantly moved the release date earlier. Like Robert, I'm extremely skeptical of this claim, for the same reasons. However, even the *possibility* that this could be true is pretty scary. If we need to effectively shut down new development for seven months at the end of a release, in addition to the interim commit fests, we'd better get a handle on why, so that can change. To what do you attribute the extended time needed to handle the final CF? How can that be made better? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
Dimitri Fontaine dfonta...@hi-media.com writes: Tom Lane t...@sss.pgh.pa.us writes: You should be able to configure the dynamic loader to do that, although in the case of uuid I strongly doubt it's worth the trouble. In the context of the extensions facility, will we be able to do this configuration automatically from the backend, or to manually load any dependant .so? I have zero interest in trying to support either. I doubt it's even possible --- the backend code has no way to inform the dynamic loader how to resolve cross-library references. So if the DL doesn't already understand the dependency it's never going to work. 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-hackers
[HACKERS] Did COPY performance regression solve in 8.4rc2?
COPY performance issue is discussed in the following threads, and it seems the conclusion was 8.4rc2 has been improved. http://archives.postgresql.org/pgsql-hackers/2009-06/msg01133.php However, I didn't see difference of COPY performance between 8.4rc1 and 8.4rc2. It seems that a COPY to 8.4rc1 or 8.4rc2 using pgbench takes about 20% longer than it does to 8.3.0. * Test environment - HP Proliant DL145 G3 - CentOS 5 x86_64 (kernel 2.6.18-8.1.8.el5) * Test method $ initdb --no-locale --encoding=UTF8 $ pg_ctl -w start $ time pgbench -i -s 1000 * Changes of postgresql.conf - max_connections = 200 - shared_buffers = 128MB - logging_collector = on - silent_mode = on * results 8.4rc2 real28m42.437s real28m33.411s real28m28.136s 8.4rc1 real28m46.542s real29m10.575s real28m44.006s 8.3.0 real23m39.131s real23m40.655s real23m49.458s Thanks, -- Toshihiro Kitagawa kitag...@sraoss.co.jp SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Did COPY performance regression solve in 8.4rc2?
Toshihiro Kitagawa kitag...@sraoss.co.jp wrote: - shared_buffers = 128MB What happens with a larger value for shared_buffers? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions User Design
Tom Lane t...@sss.pgh.pa.us writes: I have zero interest in trying to support either. I doubt it's even possible --- the backend code has no way to inform the dynamic loader how to resolve cross-library references. So if the DL doesn't already understand the dependency it's never going to work. Ok, that means less work for the extension facility (it was not targetted for it's first incarnation anyway) stuff. FWIW, I had in mind to use the dependancy information in the extension meta-data to issue more than one dlopen() when a plugin function is called. I'm being told that in my case linking uuid-ossp.so against uuid.so should do the trick, though. I'll drop the idea off the scope of the extension facility. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] single bit integer (TINYINT) revisited for 8.5
I'd like to see this topic revisited since as far as I can see it hasn't been seriously discussed in years. I believe the main arguments against are why do we need more more numeric datatypes and increased maintenance. It would seem to me that a tinyint datatype maintenance wise would get all the same updates as the other int types, making it only a slight increase in maintenance. I think there was 1 more reason but I can't find the original thread now. most (if not all?) of posgresql's major competitor's (mysql, sql server, db2, etc) support a single bit integer datatype. it would bring increased compatibility with existing mysql apps esp, making them easier to port. It (in theory?) should also bring a speed enhancement where usable since it would take less disk space. A couple of times I've been told you don't need tinyint, use boolean which is not true, several projects I've worked on I've needed and integer field that supports number within a small range 0-5 1-10 1-100 or something similar. I end up using smallint but it's range is huge for the actual requirements. -- Caleb Cushing http://xenoterracide.blogspot.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Ugh, I disagree. I agree that we were too generous with letting people rework patches while the CommitFest was in progress (mostly, we let people drop off the map for 3 weeks and then come back and say, oh, here's my revised version). But you have to allow a certain amount of reworking as the CommitFest progresses, I think. Otherwise, it just takes way too long to get anything done. Sure. The key is a *certain amount* of reworking. Not failing to respond to review for 3 weeks at a time. Not introducing APIs or syntax extensions which have never been discussed on -hackers before. Not extensive performance testing. Not saying here's 3 parts out of 5 of the patch, I'll have the other two by the 15th. Not sumbitting a patch with no written specification or (for user-facing features) documentation. That is, the *submitter* should at least think the patch is ready to go. If people are submitting stuff they *know* isn't ready to commit, it should be with a WIP flag, which to the reviewers says review this last, or not at all if we run out of time. And, even if the submitter is being responsive, if we've spent 30 days being back-and-forth with the patch, it's just not ready. Dragging that out to 60 days doesn't, according to our history, help. I also believe, although I cannot prove it, that it would have increased the pressure to get the remaining items dealt with. When there are 100 patches, everyone can say oh, well it doesn't matter whether I get this taken care of today, because there will still be 99 other patches. When there are 3 patches, that argument doesn't hold water. I agree. Closing out 11/08 accelerated once we were down to the last 5 patches. If we need to effectively shut down new development for seven months at the end of a release, in addition to the interim commit fests, we'd better get a handle on why, so that can change. To what do you attribute the extended time needed to handle the final CF? How can that be made better? Exactly. What I think we should be moving towards is the idea that *any* commitfest could, with another 30 days of housekeeping, become a final release. The only way to release in a timely fashion is to always be ready to release -- this is not just my opinion, but the experience of the Ubuntu, Parrot, and several other projects. Let me point out a worrisome trend: 7.2: 10 months 7.3: 9 months 7.4: 12 months 8.0: 13 months 8.1: 11 months 8.2: 13 months 8.3: 14 months 8.4: 16 months That's a dangerous-looking progression. What's worse is that the increasing time has always been associated with post feature-freeze; i.e. the not-fun post-development period. Until we embrace the idea that patches will get integrated or rejected in a timely fashion, and that we *can* make a target release date, we won't. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5
Caleb Cushing xenoterrac...@gmail.com wrote: most (if not all?) of posgresql's major competitor's (mysql, sql server, db2, etc) support a single bit integer datatype. A couple of times I've been told you don't need tinyint, use boolean which is not true, several projects I've worked on I've needed and integer field that supports number within a small range 0-5 1-10 1-100 or something similar. I think you mean byte where you've said bit. Boolean would be adequate for a single bit, and I haven't (so far) seen any database which supports both a single-bit type and a boolean. Many databases support a TINYINT type as a single-byte value, although I'm not sure there's consistency on whether that's a signed or unsigned value. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 10:30 AM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: Bruce Momjian br...@momjian.us wrote: I realize there is the perception that the large patches that were eventually rejected held up the release, but for all the patches I can think of, they were not rejected immediately _because_ we had other valid patches to work on. Once all valid patches were applied, we were quickly able to reject the large unready patches. So, rejecting the large patches earily would not have significantly moved the release date earlier. Like Robert, I'm extremely skeptical of this claim, for the same reasons. However, even the *possibility* that this could be true is pretty scary. If we need to effectively shut down new development for seven months at the end of a release, in addition to the interim commit fests, we'd better get a handle on why, so that can change. To what do you attribute the extended time needed to handle the final CF? How can that be made better? Hear, hear! Tom wrote upthread: # If you find yourself with nothing else to do except review a new patch # during beta, then sure, go do it. But is there *really* nothing you # could be doing to help expedite the beta? My honest answer to this question is that I have no idea. It was pretty clear to me what I was supposed to be doing during CommitFest (reviewing patches) but a lot less clear to me what I should be doing during beta. I know that there was an open items list, but it was never really clear to me how I should help with that. A lot of the open items were pretty mushy, subjective issues, or that was how they seemed to me - not so much How are we going to fix this? but Is this worth fixing? and What kind of fix is appropriate?. IOW, what they needed before any useful technical work could be done was consensus. Of course, both committers and non-committers need consensus to make changes, but committers need a lot less consensus. If no one strongly objects, they just apply. Non-committers, on the other hand, need the affirmative support of a committer to actually perform the commit. It's a lot easier to get to no one things this is a really bad idea than it is to get to one of these six people thinks this is a good idea and that person is willing to devote an hour of their day (or more) to making it happen. It seems to me that the solution to this problem is pretty simple. Committers need to say exactly what kind of help they want; they need to affirmatively tell other people what to do. If Tom wants someone to develop a patch for bug XYZ, he should say that he is prepared to apply such a patch and ask for volunteers. That helps path authors in three ways: 1. Prospective patch authors know that Tom thinks this is important and that it could hold up the release. 2. Prospective patch authors know that this isn't something that Tom is already working on. 3. Prospective path authors know that they have a good chance of getting something applied quickly, without waiting 1-7 months for the next CommitFest. I think committers are reluctant to do this for fear of being seen as pushy, or for fear of being seen to use their status as committers as way to throw their weight around. In fact, I've heard more than one committer make statements of the form, well, we don't really have any more weight to throw around than anyone else. The problem with this is that it's blatantly false, and no non-committer who has taken the time to write a patch is under any contrary illusion. If a hamster and an elephant are trying to sit on the same bench, the hamster does not want the elephant to assert that he is a hamster; he wants the elephant to announce his choice of seat prior to putting his bottom in it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Questions regarding PostgreSQL warm backup.
Dear Mr. Masao My name is Damon. I read your comments regarding pg_standby warm backup. New trigger option of pg_standby. I got several questions on this article. 1. I don't know why I have to trigger twice when switching from pg_standby status to normal status? I saw this Patch file, how do I use it? Is it a trigger file? Or something else? ( http://archives.postgresql.org/pgsql-hackers/2009-03/binbkUmMAXWMP.bin pgstandby_new_trigger_0325.patch) Here's the content in the recovery.conf file: restore_command = '/usr/local/pgsql/bin/pg_standby -l -d -s 5 -k 5 -t /tmp/stopstandby.bin /home/wal_log/ %f %p %r 2standby.log' Thanks a lot. Damon Xu
Re: [HACKERS] Mention CITEXT in the FAQ
On Feb 6, 2009, at 10:54 AM, David E. Wheeler wrote: On Feb 6, 2009, at 9:43 AM, Bruce Momjian wrote: Oh. That seems kind of odd?can you hang onto the patch until 8.4 is released, then? This must happen all the time, no? OK, I will hang on to it, but I will have to mention it is only in 8.4 too. Ah, yeah, I didn't put that in the patch… Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is released. Is that supposed to be today? Thanks, David citext_faq.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mention CITEXT in the FAQ
David E. Wheeler da...@kineticode.com writes: Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is released. Is that supposed to be today? The FAQ is on the wiki now ... fix it yourself. 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-hackers
Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5
Caleb. I'd like to see this topic revisited since as far as I can see it hasn't been seriously discussed in years. I believe the main arguments against are why do we need more more numeric datatypes and increased maintenance. It would seem to me that a tinyint datatype maintenance wise would get all the same updates as the other int types, making it only a slight increase in maintenance. I think there was 1 more reason but I can't find the original thread now. The main reason not to have one is that given byte-alignment, 95% of the time using a tinyint would save no actual disk space or memory over just using INT2 (or indeed INT4). I'll point out that the MySQLers are enamored of the 3-byte integer, which even on MySQL saves zero space or memory over using a 4-byte. Just because people like it doesn't mean it works. So the only real point in having an INT1 would be if you had a table with a lot of them in a row; an unusual but not unheard-of design. Still, that makes this feature less-than-critical for most users. But ... the nice thing about PostgreSQL is that data types can be loaded at runtime. Which means that you don't need INT1 in core for it to be useful to you and others; just write the data type and put it on pgFoundry. Then submit it for /contrib for 8.5, and we'll see how popular the idea is. Overall, I'm not keen on it. For the handful of times when peformance-optimization-by-datatype makes sense, there's a large number where it's develpers who have no idea what they're doing. We should be moving in the direction of having the database engine take care of space optimizations, not having the user do it. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mention CITEXT in the FAQ
On Jul 1, 2009, at 9:07 AM, Tom Lane wrote: Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is released. Is that supposed to be today? The FAQ is on the wiki now ... fix it yourself. It is? When did that happen? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5
Josh Berkus j...@agliodbs.com writes: But ... the nice thing about PostgreSQL is that data types can be loaded at runtime. Which means that you don't need INT1 in core for it to be useful to you and others; just write the data type and put it on pgFoundry. Yeah. The argument against that used to be that you couldn't integrate it properly into the numeric type hierarchy, but I think that's no longer the case now that add-on types can define which type category they belong to. At the very least it would be useful to try to do it as an add-on and see if there are still any obstacles to that. Which of course brings up the other argument against doing it, which was that it'd possibly mess up the rather delicate arrangement of implicit promotions among the numeric types. That was based on very old bad experiences, though, so I'm not certain if there's still a problem. Again, if there is a reason why an add-on type couldn't solve the problem while a built-in type could, I'd be more interested in finding and fixing that problem than in the value of INT1 per se. 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-hackers
Re: [HACKERS] Mention CITEXT in the FAQ
On Wed, 2009-07-01 at 09:15 -0700, David E. Wheeler wrote: On Jul 1, 2009, at 9:07 AM, Tom Lane wrote: Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is released. Is that supposed to be today? The FAQ is on the wiki now ... fix it yourself. It is? When did that happen? Quite some time ago. Joshua D. Drake Best, David -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] single bit integer (TINYINT) revisited for 8.5
On Wed, Jul 1, 2009 at 11:41 AM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: I think you mean byte where you've said bit. you're correct. I'm being a nerf. Boolean would be adequate for a single bit, and I haven't (so far) seen any database which supports both a single-bit type and a boolean. wasn't aware of that. I'm admittedly most familiar with sqlite, postgres, and mysql Many databases support a TINYINT type as a single-byte value, although I'm not sure there's consistency on whether that's a signed or unsigned value. wouldn't any implementation in pg support both? -- Caleb Cushing http://xenoterracide.blogspot.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mention CITEXT in the FAQ
David E. Wheeler da...@kineticode.com writes: On Jul 1, 2009, at 9:07 AM, Tom Lane wrote: The FAQ is on the wiki now ... fix it yourself. It is? When did that happen? http://archives.postgresql.org/pgsql-committers/2009-04/msg00111.php 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-hackers
Re: [HACKERS] Mention CITEXT in the FAQ
On Jul 1, 2009, at 9:27 AM, Tom Lane wrote: It is? When did that happen? http://archives.postgresql.org/pgsql-committers/2009-04/msg00111.php Thanks. Change added to the wiki. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5
Caleb Cushing xenoterrac...@gmail.com writes: On Wed, Jul 1, 2009 at 11:41 AM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: Many databases support a TINYINT type as a single-byte value, although I'm not sure there's consistency on whether that's a signed or unsigned value. wouldn't any implementation in pg support both? Introducing unsigned types into PG is a whole different discussion. The problem there is designing reasonable automatic promotion rules. Considering that C's rules still confuse people after nigh 40 years, I'm not enthusiastic about it ... 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-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: Joshua D. Drake j...@commandprompt.com writes: We already push and pull our release dates based are what in the queue, we just do so informally. Why not just make it part of the process? I think we used to do it more or less like that, but people didn't like it because they couldn't do any long-range planning. Does the current system help long-range planning? I could imagine an enterprise plan that says we'll upgrade to the current production release in January [after christmas sales]; or we'll begin to upgrade the January after [feature-x] is in production. But in neither case does it help my long term planning to know if the current version January release is scheduled to be called 8.4 or 8.5 or 9.1 (which is really all that the current system helps me predict). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 01, 2009 at 11:51:28AM -0400, Robert Haas wrote: Tom wrote upthread: # If you find yourself with nothing else to do except review a new patch # during beta, then sure, go do it. But is there *really* nothing you # could be doing to help expedite the beta? My honest answer to this question is that I have no idea. It was pretty clear to me what I was supposed to be doing during CommitFest (reviewing patches) but a lot less clear to me what I should be doing during beta. I know that there was an open items list, but it was never really clear to me how I should help with that. My feelings as well. During beta, there was clearly work for those with experience in the areas with open items, and probably for committers generally, but each time I reviewed the open items list I found little I could do to help. If there's something I should have found, I'd love for someone to point it out; in the meantime I tested betas and release candidates in situtations common to my use of PostgreSQL, and found that it worked to my satisfaction, after which I was left trying to figure out what to do, and started dabbling in a patch or two that interested me. If a hamster and an elephant are trying to sit on the same bench, the hamster does not want the elephant to assert that he is a hamster; he wants the elephant to announce his choice of seat prior to putting his bottom in Thanks, Robert -- this made me giggle :) -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5
On Wed, Jul 1, 2009 at 12:09 PM, Josh Berkusj...@agliodbs.com wrote: The main reason not to have one is that given byte-alignment, 95% of the time using a tinyint would save no actual disk space or memory over just using INT2 (or indeed INT4). I'll point out that the MySQLers are enamored of the 3-byte integer, which even on MySQL saves zero space or memory over using a 4-byte. Just because people like it doesn't mean it works. So the only real point in having an INT1 would be if you had a table with a lot of them in a row; an unusual but not unheard-of design. Still, that makes this feature less-than-critical for most users. The primary type of field that I see it used as involves some sort of statistics collection. like ratings, or maybe strongly agree - strongly disagree (this could be in hundreds of colums), even collecting gender's is appropriate if I recall.. as the iso for genders is an integer with like 4 possible value's. At least this is my thought, and a lot of these things end up in the same table. It's not critical, but I'd suggest the benefits outweigh the costs. But ... the nice thing about PostgreSQL is that data types can be loaded at runtime. Which means that you don't need INT1 in core for it to be useful to you and others; just write the data type and put it on pgFoundry. Then submit it for /contrib for 8.5, and we'll see how popular the idea is. I suppose I can see what I can do to this end (since it seems to be the consensus) although it'll take me a while given I've no idea what I'm doing... I can read C better than I write it, which doesn't say much. On the other hand I'd think this would be on the list of 'easiest things to do' which means I should be able to get it done. Overall, I'm not keen on it. For the handful of times when peformance-optimization-by-datatype makes sense, there's a large number where it's develpers who have no idea what they're doing. We should be moving in the direction of having the database engine take care of space optimizations, not having the user do it. eh... not sure I agree on that 100%... but to some degree that's what sql is for... at the same time that kinda sounds like sqlite's more dynamic like typing. but it is another discussion -- Caleb Cushing http://xenoterracide.blogspot.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Ron Mayer rm...@cheapcomplexdevices.com wrote: I could imagine an enterprise plan that says we'll upgrade to the current production release in January [after christmas sales]; or we'll begin to upgrade the January after [feature-x] is in production. But in neither case does it help my long term planning to know if the current version January release is scheduled to be called 8.4 or 8.5 or 9.1 (which is really all that the current system helps me predict). It would help with that if you didn't plan on features which had not been committed, and the release date didn't slip. It's been a little embarrassing at times to have told people not to try to mitigate performance problems on the application side because I've confirmed that the semijoin / antijoin code already committed to the 8.4 release solves the problem, and the release was expected around the start of the year. Ultimately, I don't know that it makes sense to plan on any feature until its patch is accepted, so the best you can do is try to plan on when the accepted patches will become available. Almost by definition, if you want a guarantee that the feature will be in some release, the date of the release becomes unknowable in advance. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Ron Mayer wrote: But in neither case does it help my long term planning to know if the current version January release is scheduled to be called 8.4 or 8.5 or 9.1 (which is really all that the current system helps me predict). The numbering is typically decided near the end of the devel cycle; it's not set in stone from the beginning. Witness how 8.0 was slated to be called 7.5 until it was almost ready ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: Bruce Momjian br...@momjian.us wrote: I realize there is the perception that the large patches that were eventually rejected held up the release, but for all the patches I can think of, they were not rejected immediately _because_ we had other valid patches to work on. Once all valid patches were applied, we were quickly able to reject the large unready patches. So, rejecting the large patches earily would not have significantly moved the release date earlier. Like Robert, I'm extremely skeptical of this claim, for the same reasons. However, even the *possibility* that this could be true is pretty scary. If we need to effectively shut down new development for seven months at the end of a release, in addition to the interim commit fests, we'd better get a handle on why, so that can change. To what do you attribute the extended time needed to handle the final CF? How can that be made better? We had many patches that had been through previous commit-fests with minor adjustments and we had to finalize them before we could close the final commit-fest. To be clear I am talking about patches that were eventually applied in 8.4, not patches that were rejected for 8.4. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 8.3 PLpgSQL Can't Compare Records?
This code: CREATE OR REPLACE FUNCTION foo() returns boolean as $$ DECLARE have_rec record; want_rec record; BEGIN have_rec := row(1, 2); want_rec := row(3, 5); RETURN have_rec IS DISTINCT FROM want_rec; END; $$ language plpgsql; SELECT ROW(1, 2) IS DISTINCT FROM ROW(3, 5); SELECT foo(); DROP FUNCTION foo(); Works as expected on 8.4, outputting: ?column? -- t (1 row) Time: 48.626 ms foo - t (1 row) On 8.3, however, the row comparisons in the SQL statement works, but fails in the PL/pgSQL function, with this output: ?column? -- t (1 row) psql:huh.sql:14: ERROR: operator does not exist: record = record LINE 1: SELECT $1 IS DISTINCT FROM $2 ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. QUERY: SELECT $1 IS DISTINCT FROM $2 CONTEXT: PL/pgSQL function foo line 7 at RETURN Is this a known issue in 8.3? If so, is there a known workaround? Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us wrote: Kevin Grittner wrote: To what do you attribute the extended time needed to handle the final CF? How can that be made better? We had many patches that had been through previous commit-fests with minor adjustments and we had to finalize them before we could close the final commit-fest. To be clear I am talking about patches that were eventually applied in 8.4, not patches that were rejected for 8.4. Thanks. That answers the first question. I guess it suggests that the second question could be refined to: What could have been done to finalize these patches in earlier commit-fests or bump them to 8.5 before they dragged the process of wrapping the release by half a year? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Ron Mayer rm...@cheapcomplexdevices.com writes: Tom Lane wrote: I think we used to do it more or less like that, but people didn't like it because they couldn't do any long-range planning. Does the current system help long-range planning? I could imagine an enterprise plan that says we'll upgrade to the current production release in January [after christmas sales]; or we'll begin to upgrade the January after [feature-x] is in production. You have forgotten the context. This discussion is not about end-user planning, it is about developer planning. The issue is whether a developer should work on feature A that he thinks will take about X months to finish, or feature B that he thinks will take Y months. For this purpose it is useful to have an idea of how long it will be until the next feature freeze. How long after that the release will actually hit the street is interesting, but not directly relevant to whether he's got a chance to get the feature in. 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-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: Ron Mayer rm...@cheapcomplexdevices.com wrote: I could imagine an enterprise plan that says we'll upgrade to the current production release in January [after christmas sales]; or we'll begin to upgrade the January after [feature-x] is in production. But in neither case does it help my long term planning to know if the current version January release is scheduled to be called 8.4 or 8.5 or 9.1 (which is really all that the current system helps me predict). It would help with that if you didn't plan on features which had not been committed, and the release date didn't slip. It's been a little embarrassing at times to have told people not to try to mitigate performance problems on the application side because I've confirmed that the semijoin / antijoin code already committed to the 8.4 release solves the problem, and the release was expected around the start of the year. Where did you see 8.4 was scheduled to be released around the start of the year? I never never seen that and would have disputed anyone saying it publicly. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, 2009-07-01 at 13:39 -0400, Bruce Momjian wrote: Where did you see 8.4 was scheduled to be released around the start of the year? I never never seen that and would have disputed anyone saying it publicly. As I understood it, 8.4 was supposed to released at the beginning of Q2. I never heard or read beginning of the year either. Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us wrote: Where did you see 8.4 was scheduled to be released around the start of the year? I never never seen that and would have disputed anyone saying it publicly. http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php That showed a January 1 beta release and a March 1 production release. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote: Bruce Momjian br...@momjian.us wrote: Where did you see 8.4 was scheduled to be released around the start of the year? I never never seen that and would have disputed anyone saying it publicly. http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php That showed a January 1 beta release and a March 1 production release. Right that would be the expectation I had. Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Joshua D. Drake j...@commandprompt.com wrote: On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote: http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php That showed a January 1 beta release and a March 1 production release. Right that would be the expectation I had. The first of March is still well into the first quarter; but I was getting confused about beta versus production release schedules when I said the release was six months late; it was four months late -- to the day. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner kevin.gritt...@wicourts.gov writes: Bruce Momjian br...@momjian.us wrote: Where did you see 8.4 was scheduled to be released around the start of the year? http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php That showed a January 1 beta release and a March 1 production release. Terminological problem. Around here, release *always* means production release. We don't expect end users to be very interested in pre-production versions. 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-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: That showed a January 1 beta release and a March 1 production release. Terminological problem. Around here, release *always* means production release. We don't expect end users to be very interested in pre-production versions. Well, I actually phrased it with managers here that 8.4 was scheduled to go to beta on January 1st, but that the actual release date was less predictable because the PostgreSQL community worries more about having a solid release than hitting a release date. Based on discussions on the hackers list, I actually had the impression that there would be a concerted effort to hit the beta date. But, yeah -- on this thread I got the dates confused a bit. I'm happy to see that the slippage was less severe than I had got myself thinking it was. A third of a year, rather than half. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: Joshua D. Drake j...@commandprompt.com wrote: On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote: http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php That showed a January 1 beta release and a March 1 production release. Right that would be the expectation I had. The first of March is still well into the first quarter; but I was getting confused about beta versus production release schedules when I said the release was six months late; it was four months late -- to the day. OK, that is more accurate, but looking at the schedule: 1st November 2008 - final commit fest begins 1st January 2009 - beta 1 1st March 2009 - 8.4.0 release How could we have possibly completed the last commit-fest and gotten ready for beta in two months --- that is just not realistic. I think we anticipated a 2x longer final commit-fest, two months, but there was no time scheduled for actual beta preparation. I think there was some ideal that we wouldn't need any time to prepare for beta and that we would have dealt with all bugs by the time the last commit-fest is complete, but that is illusory. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: That showed a January 1 beta release and a March 1 production release. Terminological problem. Around here, release *always* means production release. We don't expect end users to be very interested in pre-production versions. Well, I actually phrased it with managers here that 8.4 was scheduled to go to beta on January 1st, but that the actual release date was less predictable because the PostgreSQL community worries more about having a solid release than hitting a release date. Based on discussions on the hackers list, I actually had the impression that there would be a concerted effort to hit the beta date. But, yeah -- on this thread I got the dates confused a bit. I'm happy to see that the slippage was less severe than I had got myself thinking it was. A third of a year, rather than half. And I have just posted that a lack of scheduled time for beta preparation was one reason for the slippage. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian wrote: Where did you see 8.4 was scheduled to be released around the start of the year? I never never seen that and would have disputed anyone saying it publicly. I think people carefully avoided the word scheduled, but the press FAQ on www.postgresql.org did say to expect it in Q4 08. http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php http://www.postgresql.org/about/press/faq Q: When will 8.4 come out? A: Historically, PostgreSQL has released approximately every 12 months and there is no desire in the community to change from that pattern. So expect 8.4 sometime in the fourth quarter of 2008. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us writes: OK, that is more accurate, but looking at the schedule: 1st November 2008 - final commit fest begins 1st January 2009 - beta 1 1st March 2009 - 8.4.0 release How could we have possibly completed the last commit-fest and gotten ready for beta in two months --- that is just not realistic. We didn't know that at the time, though. We thought the last CF would take a month plus. And up till November the CFs *were* getting done in about a month. In retrospect, the CF idea took some of the edge off the problem of lots of large patches arriving at the feature freeze deadline, but it is far from having eliminated the problem. 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-hackers
Re: [HACKERS] 8.5 development schedule
Ron Mayer wrote: Bruce Momjian wrote: Where did you see 8.4 was scheduled to be released around the start of the year? I never never seen that and would have disputed anyone saying it publicly. I think people carefully avoided the word scheduled, but the press FAQ on www.postgresql.org did say to expect it in Q4 08. http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php http://www.postgresql.org/about/press/faq Q: When will 8.4 come out? A: Historically, PostgreSQL has released approximately every 12 months and there is no desire in the community to change from that pattern. So expect 8.4 sometime in the fourth quarter of 2008. OK, now that someone has brought it up --- I have been disappointed with the anticipated release dates we broadcast to the press --- without community approval or oversight. This is not the first time, but hopefully it is the last. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us wrote: How could we have possibly completed the last commit-fest and gotten ready for beta in two months --- that is just not realistic. I think we anticipated a 2x longer final commit-fest, two months, but there was no time scheduled for actual beta preparation. For my edification, could you point me at something which identifies the work needed after everything is committed and before the first beta is released? (I can't remember reading anything like that, but it may have fallen through the cracks.) If no such page exists, could you sketch out a brief outline? I think there was some ideal that we wouldn't need any time to prepare for beta and that we would have dealt with all bugs by the time the last commit-fest is complete, but that is illusory. I thought one of the purposes of the two-month beta testing phase on the calendar was to find and fix bugs. That was in addition to the two month final commit-fest. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Ron Mayer rm...@cheapcomplexdevices.com writes: Bruce Momjian wrote: Where did you see 8.4 was scheduled to be released around the start of the year? I never never seen that and would have disputed anyone saying it publicly. I think people carefully avoided the word scheduled, but the press FAQ on www.postgresql.org did say to expect it in Q4 08. http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php http://www.postgresql.org/about/press/faq Q: When will 8.4 come out? A: Historically, PostgreSQL has released approximately every 12 months and there is no desire in the community to change from that pattern. So expect 8.4 sometime in the fourth quarter of 2008. Whoever wrote that certainly didn't ask any of the core hackers about the phrasing. 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-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: OK, that is more accurate, but looking at the schedule: 1st November 2008 - final commit fest begins 1st January 2009 - beta 1 1st March 2009 - 8.4.0 release How could we have possibly completed the last commit-fest and gotten ready for beta in two months --- that is just not realistic. We didn't know that at the time, though. We thought the last CF would take a month plus. And up till November the CFs *were* getting done in about a month. In retrospect, the CF idea took some of the edge off the problem of lots of large patches arriving at the feature freeze deadline, but it is far from having eliminated the problem. The beta preparation is dealing with all open issues, which is different than the focus of the commit-fest. Ideally we would be addressing those open/bug issues during normal development, but for the hard problems seem to linger and then we have to deal with them during beta preparation, which can take 1-2 months. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: In retrospect, the CF idea took some of the edge off the problem of lots of large patches arriving at the feature freeze deadline, but it is far from having eliminated the problem. The beta preparation is dealing with all open issues, which is different than the focus of the commit-fest. Ideally we would be addressing those open/bug issues during normal development, but for the hard problems seem to linger and then we have to deal with them during beta preparation, which can take 1-2 months. We've never scheduled a beta preparation phase like that before, and I don't recall you complaining about the lack of one in the 8.4 schedule. Personally I think the slip is entirely due to the final CF taking five months (we closed it 25-March) where we'd expected something closer to one month. 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-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: Bruce Momjian br...@momjian.us wrote: How could we have possibly completed the last commit-fest and gotten ready for beta in two months --- that is just not realistic. I think we anticipated a 2x longer final commit-fest, two months, but there was no time scheduled for actual beta preparation. For my edification, could you point me at something which identifies the work needed after everything is committed and before the first beta is released? (I can't remember reading anything like that, but it may have fallen through the cracks.) If no such page exists, could you sketch out a brief outline? I just posted on this, but the answer is that commit-fest is for getting patches applied --- it does not address open bugs that have to be addressed before we can go to beta. Those bugs could be new or could be related to previously-applied patches. That process can take 1-2 months. I think there was some ideal that we wouldn't need any time to prepare for beta and that we would have dealt with all bugs by the time the last commit-fest is complete, but that is illusory. I thought one of the purposes of the two-month beta testing phase on the calendar was to find and fix bugs. That was in addition to the two month final commit-fest. But usually by the time we finish the last commit-fest, we already have lots of bugs we know about (usually hard to fix), and it doesn't make sense to go into beta with known bugs. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Tom Lane wrote: In retrospect, the CF idea took some of the edge off the problem of lots of large patches arriving at the feature freeze deadline, but it is far from having eliminated the problem. The beta preparation is dealing with all open issues, which is different than the focus of the commit-fest. Ideally we would be addressing those open/bug issues during normal development, but for the hard problems seem to linger and then we have to deal with them during beta preparation, which can take 1-2 months. We've never scheduled a beta preparation phase like that before, and I don't recall you complaining about the lack of one in the 8.4 schedule. Personally I think the slip is entirely due to the final CF taking five months (we closed it 25-March) where we'd expected something closer to one month. I didn't bring it up because the schedule was kind of a first attempt and it didn't make sense to try and tune it at that point. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us wrote: The beta preparation is dealing with all open issues, which is different than the focus of the commit-fest. Ideally we would be addressing those open/bug issues during normal development, but for the hard problems seem to linger and then we have to deal with them during beta preparation, which can take 1-2 months. Is there any way to move some of that work up into the earlier commit fests? (I'm afraid I still don't have my head around exactly what sorts of issues are addressed in this phase.) By the way, I hope that nobody is taking any of my observations or questions as criticism or complaint. It seems pretty obvious that the process currently involves a fair amount of frustration and pain for all involved, and I'm trying to brainstorm to help. Don't think for a minute that I forget or fail to appreciate the tremendous work you do, along with that done by everyone else. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.3 PLpgSQL Can't Compare Records?
On Wed, Jul 1, 2009 at 1:35 PM, David E. Wheelerda...@kineticode.com wrote: This code: CREATE OR REPLACE FUNCTION foo() returns boolean as $$ DECLARE have_rec record; want_rec record; BEGIN have_rec := row(1, 2); want_rec := row(3, 5); RETURN have_rec IS DISTINCT FROM want_rec; END; $$ language plpgsql; SELECT ROW(1, 2) IS DISTINCT FROM ROW(3, 5); SELECT foo(); DROP FUNCTION foo(); Works as expected on 8.4, outputting: ?column? -- t (1 row) Time: 48.626 ms foo - t (1 row) On 8.3, however, the row comparisons in the SQL statement works, but fails in the PL/pgSQL function, with this output: ?column? -- t (1 row) psql:huh.sql:14: ERROR: operator does not exist: record = record LINE 1: SELECT $1 IS DISTINCT FROM $2 ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. QUERY: SELECT $1 IS DISTINCT FROM $2 CONTEXT: PL/pgSQL function foo line 7 at RETURN Is this a known issue in 8.3? If so, is there a known workaround? fyi: works in 8.4, as part of a broad fix of composite type comparison ops merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.3 PLpgSQL Can't Compare Records?
On Wed, Jul 1, 2009 at 2:45 PM, Merlin Moncuremmonc...@gmail.com wrote: On Wed, Jul 1, 2009 at 1:35 PM, David E. Wheelerda...@kineticode.com wrote: This code: CREATE OR REPLACE FUNCTION foo() returns boolean as $$ DECLARE have_rec record; want_rec record; BEGIN have_rec := row(1, 2); want_rec := row(3, 5); RETURN have_rec IS DISTINCT FROM want_rec; END; $$ language plpgsql; SELECT ROW(1, 2) IS DISTINCT FROM ROW(3, 5); SELECT foo(); DROP FUNCTION foo(); Works as expected on 8.4, outputting: ?column? -- t (1 row) Time: 48.626 ms foo - t (1 row) On 8.3, however, the row comparisons in the SQL statement works, but fails in the PL/pgSQL function, with this output: ?column? -- t (1 row) psql:huh.sql:14: ERROR: operator does not exist: record = record LINE 1: SELECT $1 IS DISTINCT FROM $2 ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. QUERY: SELECT $1 IS DISTINCT FROM $2 CONTEXT: PL/pgSQL function foo line 7 at RETURN Is this a known issue in 8.3? If so, is there a known workaround? fyi: works in 8.4, as part of a broad fix of composite type comparison ops whoops, you knew that already :-). one possible workaround is: select $1::text is distinct from $2::text; merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: Bruce Momjian br...@momjian.us wrote: The beta preparation is dealing with all open issues, which is different than the focus of the commit-fest. Ideally we would be addressing those open/bug issues during normal development, but for the hard problems seem to linger and then we have to deal with them during beta preparation, which can take 1-2 months. Is there any way to move some of that work up into the earlier commit fests? (I'm afraid I still don't have my head around exactly what sorts of issues are addressed in this phase.) Basically when someone reports a bug against CVS HEAD we try to fix it but if the fix is complex, we usually just leave it for later, hence the beta preparation time. I think we assume some ideal fix will occur to us but once we are near beta, we have no more time so we fix it as best we can. By the way, I hope that nobody is taking any of my observations or questions as criticism or complaint. It seems pretty obvious that the process currently involves a fair amount of frustration and pain for all involved, and I'm trying to brainstorm to help. Don't think for a minute that I forget or fail to appreciate the tremendous work you do, along with that done by everyone else. We understand your motivation. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.3 PLpgSQL Can't Compare Records?
On Jul 1, 2009, at 11:47 AM, Merlin Moncure wrote: fyi: works in 8.4, as part of a broad fix of composite type comparison ops whoops, you knew that already :-). one possible workaround is: select $1::text is distinct from $2::text Yes, and that's what I'm doing, although it is significantly less precise, in that: * Columns with different types may successfully compare (e.g., NULL and '') * No (easy) way to tell if two records have different numbers of columns But it's good enough for 8.3 if there is no other workaround. Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] resetxlog bug
Hi, I am currently running PG version 8.3.1. I am working in a test environment. I have a situation where the WAL file needed at startup no longer exists and I really don't care about it, therefore, I just want to reset the logs and go from there. However, after the pg_resetxlog, PG is still looking for the old file in the pg_xlog directory. Has this bug been fixed in a version beyond 8.3.1? Thanks for your help! pg_resetxlog bug? * *From*: Fujii Masao masao(dot)fujii(at)gmail(dot)com * *To*: PostgreSQL-development pgsql-hackers(at)postgresql(dot)org * *Subject*: pg_resetxlog bug? * *Date*: Fri, 1 May 2009 00:07:26 +0900 * *Message-id*: 3f0b79eb0904300807y43a96717ued641f6624c2...@mail.gmail.com http://archives.postgresql.org/message-id/3f0b79eb0904300807y43a96717ued641f6624c2...@mail.gmail.com text/plain http://archives.postgresql.org/msgtxt.php?id=3f0b79eb0904300807y43a96717ued641f6624c2...@mail.gmail.com
Re: [HACKERS] resetxlog bug
Lorraine Mancuso wrote: Hi, I am currently running PG version 8.3.1. I am working in a test environment. I have a situation where the WAL file needed at startup no longer exists and I really don't care about it, This is never true -- if you lose a WAL file, there is potential corruption in the system catalogs. So you always care about it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us writes: Kevin Grittner wrote: However, even the *possibility* that this could be true is pretty scary. If we need to effectively shut down new development for seven months at the end of a release, in addition to the interim commit fests, we'd better get a handle on why, so that can change. To what do you attribute the extended time needed to handle the final CF? How can that be made better? We had many patches that had been through previous commit-fests with minor adjustments and we had to finalize them before we could close the final commit-fest. To be clear I am talking about patches that were eventually applied in 8.4, not patches that were rejected for 8.4. I think this is simply not in agreement with the facts. The patches that caused the greatest amount of delay for 8.4 were the ones that ultimately got rejected --- notably hot standby, sync rep, and sepostgres. Now the fact that everybody knew they would take awhile provided some cover for other patches that weren't quite ready. If we had bounced those three on Nov. 1 the commit fest would've been a lot shorter. Probably some other things that did get in would've gotten bounced too, but on the whole I think the project would have been better off. The long and the short of it is that there is always tremendous pressure to include patches that are on the edge of being ready, because we all know that bouncing them to the next release cycle will mean an extra year before they're available in production. The dynamic in 8.4 was exactly the same as it's been in the prior release cycles: we keep slipping the possible release date and trying to get those patches ready, and we don't give up until everyone agrees the release is just hopelessly late. As long as we keep behaving that way, no amount of schedule-setting or rule-making is going to change anything. It comes down to somebody having the willingness to say no and the authority to make it stick. Robert mentioned upthread that the committers don't want to be seen as throwing their weight around, which is quite true, but I have also noticed in the past that saying no does not convince whoever is arguing that this release will suck if it doesn't have this feature. And there's always somebody arguing that side --- usually several people. 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-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote: It comes down to somebody having the willingness to say no and the authority to make it stick. Robert mentioned upthread that the committers don't want to be seen as throwing their weight around, Is that the purpose of core? To make exactly those decisions? Sincerely, Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Joshua D. Drake j...@commandprompt.com writes: On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote: It comes down to somebody having the willingness to say no and the authority to make it stick. Robert mentioned upthread that the committers don't want to be seen as throwing their weight around, Is that the purpose of core? To make exactly those decisions? Core has never seen itself as intended to make feature-by-feature decisions. People seem to be willing to defer to us on release schedule-setting, but it's not clear to me that the community has delegated us more authority than that. 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-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote: Joshua D. Drake j...@commandprompt.com writes: On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote: It comes down to somebody having the willingness to say no and the authority to make it stick. Robert mentioned upthread that the committers don't want to be seen as throwing their weight around, Is that the purpose of core? To make exactly those decisions? Core has never seen itself as intended to make feature-by-feature decisions. People seem to be willing to defer to us on release schedule-setting, but it's not clear to me that the community has delegated us more authority than that. I would agree that having core decide on specific features is probably a stretch but having core set a cut date to which *all* patches that don't make that date? That seems within purview. Sincerely, Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Joshua D. Drake wrote: On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote: Joshua D. Drake j...@commandprompt.com writes: On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote: It comes down to somebody having the willingness to say no and the authority to make it stick. Robert mentioned upthread that the committers don't want to be seen as throwing their weight around, Is that the purpose of core? To make exactly those decisions? Core has never seen itself as intended to make feature-by-feature decisions. People seem to be willing to defer to us on release schedule-setting, but it's not clear to me that the community has delegated us more authority than that. I would agree that having core decide on specific features is probably a stretch but having core set a cut date to which *all* patches that don't make that date? That seems within purview. Define make that date? That is the problem. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: Joshua D. Drake j...@commandprompt.com writes: On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote: It comes down to somebody having the willingness to say no and the authority to make it stick. Robert mentioned upthread that the committers don't want to be seen as throwing their weight around, Is that the purpose of core? To make exactly those decisions? Core has never seen itself as intended to make feature-by-feature decisions. People seem to be willing to defer to us on release schedule-setting, but it's not clear to me that the community has delegated us more authority than that. You have correctly identified the requirement in the sentence quoted above. I for one am quite prepared to support core or some person designated by core having such authority. I agree with you that without something like that not much will improve. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 5:01 PM, Tom Lanet...@sss.pgh.pa.us wrote: Bruce Momjian br...@momjian.us writes: Kevin Grittner wrote: However, even the *possibility* that this could be true is pretty scary. If we need to effectively shut down new development for seven months at the end of a release, in addition to the interim commit fests, we'd better get a handle on why, so that can change. To what do you attribute the extended time needed to handle the final CF? How can that be made better? We had many patches that had been through previous commit-fests with minor adjustments and we had to finalize them before we could close the final commit-fest. To be clear I am talking about patches that were eventually applied in 8.4, not patches that were rejected for 8.4. I think this is simply not in agreement with the facts. The patches that caused the greatest amount of delay for 8.4 were the ones that ultimately got rejected --- notably hot standby, sync rep, and sepostgres. Now the fact that everybody knew they would take awhile This is also how I remember it. provided some cover for other patches that weren't quite ready. If we had bounced those three on Nov. 1 the commit fest would've been a lot shorter. Probably some other things that did get in would've gotten bounced too, but on the whole I think the project would have been better off. It wasn't just the big patches that dragged on forever: for example, updateable views got submitted literally hours before the start of the CommitFest in a state where it did not even pass regression tests, I reviewed it, there was a lng delay before resubmit, then it got committed, then it got reverted. If we had ejected that patch from the queue (for non-resubmission, if nothing else) early on in the process, it would have freed up at least three people's time (Tom's, mine, Peter's) to work on other patches that were in better shape and submitted sooner. One of the WORST mistakes that we made with the November CommitFest was to only assign reviewers to the small patches, figuring that the committers would look at the big ones. SE-PostgreSQL was not given a reasonable review for a very long time. What we need to do this time is start with the biggest patches and assign the most capable reviewers (committers, preferably) to those patches and then work down the list. This is another example of the uncomfortable dynamic between committers and everyone else: non-committers don't feel comfortable assigning committers to review patches, because who are we to tell the commiters what to do? But when the committers are the only ones competent to do that review, the result is a huge vacuum. We need to put some structure around this that works. I do agree, however, that rejecting more patches sooner (in particular, the ones that had been reviewed and found wanting) would have been the way to go and good for the project. The long and the short of it is that there is always tremendous pressure to include patches that are on the edge of being ready, because we all know that bouncing them to the next release cycle will mean an extra year before they're available in production. The dynamic in 8.4 was exactly the same as it's been in the prior release cycles: we keep slipping the possible release date and trying to get those patches ready, and we don't give up until everyone agrees the release is just hopelessly late. As long as we keep behaving that way, no amount of schedule-setting or rule-making is going to change anything. Yep. It comes down to somebody having the willingness to say no and the authority to make it stick. Robert mentioned upthread that the committers don't want to be seen as throwing their weight around, which is quite true, but I have also noticed in the past that saying no does not convince whoever is arguing that this release will suck if it doesn't have this feature. And there's always somebody arguing that side --- usually several people. Yep. But having a review that clearly enumerates the reasons WHY the patch needs to be rejected is certainly more compelling than a blanket statement that the patch is big and invasive and therefore must have bugs, even if we haven't looked at it enough to find them. The blanket statement may be quite true, but it doesn't provide feedback to the patch author and so fails to accomplish one of the main purposes of the CommitFests, at least IMO. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us wrote: Define make that date? That is the problem. Not committed by that date. I guess that leaves the issue of picking a particular time in a particular time zone, but it doesn't otherwise seem ambiguous. Picture the New York Subway system. You're coming down the stairs and the train is in sight. You either make it through the doors before they close, or you don't. If you don't, you wait for the next train. The system would never work if they held up the train for everyone in sight of the train who hoped to get on to avoid the wait. Nobody is throwing their weight around when those doors close; it's just how the system works. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: Bruce Momjian br...@momjian.us wrote: Define make that date? That is the problem. Not committed by that date. I guess that leaves the issue of picking a particular time in a particular time zone, but it doesn't otherwise seem ambiguous. Picture the New York Subway system. You're coming down the stairs and the train is in sight. You either make it through the doors before they close, or you don't. If you don't, you wait for the next train. The system would never work if they held up the train for everyone in sight of the train who hoped to get on to avoid the wait. Nobody is throwing their weight around when those doors close; it's just how the system works. The problem is that the committers control the commit date, but the one seen as punished for a rejected patch is not the committers but the submitter. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, Jun 30, 2009 at 5:11 PM, Tom Lanet...@sss.pgh.pa.us wrote: I'm also not prepared to push a large and unstable feature into the tree on the hope that it will get fixed. I didn't have the impression it had any known problems, Simon and others spent a lot of time testing it already. The improvements Heikki was asking for were simplifications or cleanup type changes and every time he asked for something Simon had it done within a day or two. The problem is I think this will *always* be a large unstable feature just because it's large. If we aren't happy having it in the tree for alpha releases then there's no circumstance we'll ever be happy having it in a real release. I think it's a *lot* better having it in the alpha releases when if we find problems we can revert it or fix the problems than dropping it at the last second before the betas when it has to be perfect and there's no second chances. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_migrator versus inherited columns
I was testing pg_migrator the other day on the regression database, and found out that it doesn't work: Restoring database schema psql:/home/postgres/pg_migrator_dump_db.sql:4545: ERROR: column pg.dropped.1 of relation dropcolumnchild does not exist Some investigation found out the reason. pg_migrator needs to be able to create tables that exactly match the physical column layout of the old database, including dropped columns if any. The way that it does this is that the --binary-upgrade switch added to pg_dump causes pg_dump to go ahead and include dropped columns in CREATE TABLE commands, and then immediately drop them. That's okay for simple tables, but it's got exactly zero hope of working in inheritance scenarios. A column that was created and later dropped in a parent table might or might not exist (though now dropped) in child tables. More generally, the approach is fatally broken for inheritance children even if they contain no dropped columns. Adding a column to a parent table results in child-table column ordering that is different from what you get after a dump and reload, for example after create table p (f1 int, f2 int); create table c (f3 int) inherits (p); alter table p add column f4 int; the column order in c is f1,f2,f3,f4 ... but after dump and reload it will be f1,f2,f4,f3, because f4 will be part of the initial definition of p rather than getting tacked on later. We understood years ago that pg_dump has to take extra measures to deal with this --- that's why it has to use COPY with a column list. The only solution I can see that has a chance of working without a massive amount of new logic in pg_dump is to change the way that inheritance is managed. Instead of dumping the above situation as create table p (f1 int, f2 int, f4 int); create table c (f3 int) inherits (p); I propose that when --binary-upgrade is active, it should be dumped as create table p (f1 int, f2 int, f4 int); create table c (f1 int, f2 int, f4 int, f3 int); alter table c add inherit p; (It's a good thing we added ADD INHERIT in 8.4, or we'd be completely up the creek here.) In this way we can ensure that the physical order of columns really is what it needs to be in the child table. Dropped columns can then be managed in the same way as the current code does, but it'll actually work. (We have to drop them before doing the ADD INHERIT of course.) Comments? 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-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us wrote: The problem is that the committers control the commit date, but the one seen as punished for a rejected patch is not the committers but the submitter. Well, it would seem odd for anyone to feel punished. If the patch isn't submitted in good form with the issues hashed out in prior discussion, and the reviewer(s) and committer(s) can't resolve the issues prior to the cutoff -- well, try to address those issues for the next release. Maybe submit with a bit more lead time next time around. As is often pointed out here, nothing stops you from using your own patch if you need to. We did so here, for example, with the standard character string literals. Had that patch never been accepted, we'd still be patching new releases. I'm sure that's not always an option, but I'll bet it often is. If the submitter is anxious to make a particular release, they should be motivated to submit early, turn around quickly, and raise a fuss if the patch seems to be wanting for attention. One possible solution would be to have trains leaving the station more often. I know that the idea of more frequent releases has been proposed and rejected before, but that option is sort of screaming to be considered again in all of this. Are the mentions of alpha releases a way to edge into this area -- a feature which misses a major release could be available to the intrepid within a month or two, should it then be finished and committed, in a semi-formal way? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
bruce wrote: I realize there is the perception that the large patches that were eventually rejected held up the release, but for all the patches I can think of, they were not rejected immediately _because_ we had other valid patches to work on. Once all valid patches were applied, we were quickly able to reject the large unready patches. So, rejecting the large patches early would not have significantly moved the release date earlier. I see no one agrees with my analysis --- no matter; if I unreservedly agreed with others, I wouldn't be here. ;-) There has been discussion about how to be more hard-nosed about rejecting patches. I think it has to start with us being more hard-nosed about giving patches feedback --- the very idea we had to create commit-fests reflects that we historically have not done an organized job of processing patches. If we review patches as soon as they appear, and give rapid feedback, we can easily reject patches that take more than a few days for the patch author to resolve, and there would be little slippage; the same goes for dealing with known bugs. I know it can be done, but I don't promise it would be pleasant. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Greg Stark wrote: On Tue, Jun 30, 2009 at 5:11 PM, Tom Lanet...@sss.pgh.pa.us wrote: I'm also not prepared to push a large and unstable feature into the tree on the hope that it will get fixed. I didn't have the impression it had any known problems, Simon and others spent a lot of time testing it already. The improvements Heikki was asking for were simplifications or cleanup type changes and every time he asked for something Simon had it done within a day or two. The problem is I think this will *always* be a large unstable feature just because it's large. If we aren't happy having it in the tree for alpha releases then there's no circumstance we'll ever be happy having it in a real release. I think it's a *lot* better having it in the alpha releases when if we find problems we can revert it or fix the problems than dropping it at the last second before the betas when it has to be perfect and there's no second chances. By that logic we would never have accepted large patches, but we have, often. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Greg Stark gsst...@mit.edu writes: On Tue, Jun 30, 2009 at 5:11 PM, Tom Lanet...@sss.pgh.pa.us wrote: I'm also not prepared to push a large and unstable feature into the tree on the hope that it will get fixed. I didn't have the impression it had any known problems, Simon and others spent a lot of time testing it already. If it didn't have known problems it would have been committed in 8.4. 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-hackers
[HACKERS] HEAD is open for 8.5 development
Let the breakage begin ... 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-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 6:53 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: Bruce Momjian br...@momjian.us wrote: The problem is that the committers control the commit date, but the one seen as punished for a rejected patch is not the committers but the submitter. Well, it would seem odd for anyone to feel punished. Depends on who the patch submitter thinks is at fault. Sometimes, patches legitimately don't get reviewed as much as would be good. Other times, the submitter just thinks the committer is nitpicking. I think Bruce summarized it pretty well. Really, when you get right down to it, you can guarantee that all patches get a certain amount of review, or you can guarantee that the CommitFest ends by a certain date, but not both, because you can't force other people to spend more time on PostgreSQL than they have to spend. At best, you can get them to spend the time that they do have on the right sort of things (e.g. reviewing rather than developing new patches during CommitFest). Of course, since you want both of those things to happen, it's a balancing act. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] [v8.5] Security checks on largeobjects
I could find one more issue when we apply largeobject-style interfaces
on generic toasted varlena data.
When we fetch a toasted datum, it scans the pg_toast_%u with SnapshotToast,
because it assumes any toasted chunks don't have multiple versions, and
visibility of the toast pointer always means visibility of the toast chunks.
However, if we provide largeobject-style interfaces which allow partial
updates on toasted varlena, it seems to me this assumption will get being
incorrect.
Is there any good idea?
KaiGai Kohei wrote:
I concluded that the following issues should be solved when we apply
largeobject-like interfaces on the big toasted data within general
relations, not only pg_largeobject system catalog.
At first, we need to add a new strategy to store the given varlena data
on the external toast relation.
If we try to seek and fetch a certain data chunk, it is necessary to be
computable what chunk stores the required data specified by offset and
length. So, the external chunks should be uncompressed always. It is a
common requirement for both of read and write operations.
If we try to update a part of the toasted data chunks, it should not be
inlined independent from length of the datum, because we need to update
whole the tuple which contains inlined toasted chunks in this case.
If we open the toasted varlena with read-only mode, inlined one does not
prevent anything. It is an issue for only write operation.
I would like to add a new strategy on pg_type.typstorage with the following
characteristics:
1. It always stores the given varlena data without any compression.
So, the given data is stored as a set of fixed-length chunks.
2. It always stores the given varlena data on external toast relation.
I suggest a new built-in type named BLOB which has an identical definition
to BYTEA type, expect for its attstorage.
Next, a different version of lo_open() should be provided to accept
BLOB type as follows:
SELECT pictname, lo_open(pictdata, x'2'::int) FROM my_picture;
It will allocate a largeobject descriptor for the given BLOB data,
and user can read and write using loread() and lowrite() interfaces.
issue:
In this case, should it hold the relation handler and locks on the
my_picture relation, not only its toast relation?
issue:
Should the lo_open() with read-only mode be available on the existing
TEXT or BYTEA types? I could not find any reason to deny them.
Next, pg_largeobject system catalog can be redefined using the BLOB
type as follows:
CATALOG(pg_largeobject,2613)
{
Oid loowner;/* OID of the largeobject owner */
Oid lonsp; /* OID of the largeobject namespace */
aclitem loacl[1]; /* access permissions */
bloblodata; /* contents of the largeobject */
} FormData_pg_largeobject;
The existing largeobject interfaces perform on pg_largeobject.lodata
specified by largeobject identifier.
Rest of metadata can be used for access control purpose.
Thanks,
KaiGai Kohei wrote:
Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
It might be interesting to dig into your proposal deeper in conjunction
with TOAST (you've already mentioned this TODO). Having serial access with
a nice interface into TOAST would be eliminating the need for
pg_largeobject completely (i'm not a big fan of this one-big-system-table
approach the old LO interface currently is).
Yeah, it would be more useful probably to fix that than to add
decoration to the LO facility. Making LO more usable is just going to
encourage people to bump into its other limitations (32-bit OIDs,
32-bit object size, finite maximum size of pg_largeobject, lack of
dead-object cleanup, etc etc).
The reason why I tried to mention the named largeobject feature is
that dac security checks on largeobject require them to belong to
a certain schema, so I thought it is quite natural to have a string
name. However, obviously, it is not a significant theme for me.
I can also agree your opinion that largeobject interfaces should be
redefined to access partial stuff of TOAST'ed verlena data structure,
not only pg_largeobject.
In this case, we will need a new pg_type.typstorage option which
force to put the given verlena data on external relation without
compression, because we cannot estimate the data offset in inlined
or compressed external verlena data.
I'll try to submit a design within a few days.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator versus inherited columns
On Wed, Jul 1, 2009 at 11:36 PM, Tom Lanet...@sss.pgh.pa.us wrote: (It's a good thing we added ADD INHERIT in 8.4, or we'd be completely up the creek here.) In this way we can ensure that the physical order of columns really is what it needs to be in the child table. Dropped columns can then be managed in the same way as the current code does, but it'll actually work. (We have to drop them before doing the ADD INHERIT of course.) Comments? Uhm, we've had ADD INHERIT since 8.2 -- that was my first patch. This will result in all the columns being marked attislocal. Ie, if they're dropped from the parent they won't be dropped automatically from the children any longer. Frankly I never really liked attislocal -- it seems to me the user knows when he's dropping the column whether he wants it dropped from the children and should be able to explicitly request it to cascade or not. I can't imagine many use cases where you want it to cascade to some children but not others based on how they were originally created. -- greg http://mit.edu/~gsstark/resume.pdf -- 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 CommitFest: July 15th
Folks, There's been a lot of discussion/argument around how to handle the last commitfest, but there seems to be a total consensus that we want to have the first CF on July 15th. I'd like Robert Haas to be the CF Manager for that commitfest if he's available. I can help by running RRR or something. Robert, I have not reviewed your software. Do I need a login or something? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_migrator versus inherited columns
Greg Stark gsst...@mit.edu writes: On Wed, Jul 1, 2009 at 11:36 PM, Tom Lanet...@sss.pgh.pa.us wrote: Comments? Uhm, we've had ADD INHERIT since 8.2 -- that was my first patch. Hmm, 8.3 doesn't seem to recognize the syntax: regression=# alter table c add inherit p; ERROR: type p does not exist LINE 1: alter table c add inherit p; ^ This will result in all the columns being marked attislocal. Ie, if they're dropped from the parent they won't be dropped automatically from the children any longer. Good point. We could have pg_dump fix that up, I suppose. On the other hand, I'm not entirely sure that the current dump methodology guarantees to preserve attislocal correctly anyway. Frankly I never really liked attislocal -- it seems to me the user knows when he's dropping the column whether he wants it dropped from the children and should be able to explicitly request it to cascade or not. The original discussions about attislocal/attinhcount came up with some cases that seemed to make it necessary, but I've long forgotten the details. 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-hackers
Re: [HACKERS] pg_migrator versus inherited columns
On Thu, Jul 2, 2009 at 1:25 AM, Tom Lanet...@sss.pgh.pa.us wrote: Hmm, 8.3 doesn't seem to recognize the syntax: regression=# alter table c add inherit p; ERROR: type p does not exist LINE 1: alter table c add inherit p; ^ Oh I remember being caught by this myself. The above is trying to add a new column named inherit. The syntax to add an inheritance parent is just alter table c inherit p -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5
Incidentally there *is* a single-byte integer data type in Postgres, it's called char (the quote marks are necessary in SQL due to the char(n) data type). It's a bit weird though, mainly because its output format is to output ascii characters -- kind of like how C's single-byte integer data type is mainly used to hold ascii characters... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Query progress indication - an implementation
Tom Lane wrote: Joshua Tolley eggyk...@gmail.com writes: On Mon, Jun 29, 2009 at 02:07:23PM -0400, Tom Lane wrote: I think this is pretty much nonsense --- most queries run all their plan nodes concurrently to some extent. You can't usefully say that a query is on some node, nor measure progress by whether some node is done. What about showing the outermost node where work has started? That's always the outermost node; what would it tell you? [ Repost ] I think the only resonable solution would be to consider the estimated cost of each node and then compute what percentage complete each node is. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gin--a rule for function parameter
1 ginarrayextract() has 2 parameters 2 gin_extract_tsquery() has 3 parameters 3 run sql(from plsql/src/test/regress/sql/opr_sanity.sql), it expect no results: - SELECT p1.amopclaid, p1.amprocnum, p2.oid, p2.proname, p3.opcname, p4.amopclaid, p4.amprocnum, p5.oid, p5.proname, p6.opcname FROM pg_amproc AS p1, pg_proc AS p2, pg_opclass AS p3, pg_amproc AS p4, pg_proc AS p5, pg_opclass AS p6 WHERE p1.amopclaid = p3.oid AND p4.amopclaid = p6.oid AND p3.opcamid = p6.opcamid AND p1.amprocnum = p4.amprocnum AND p1.amproc = p2.oid AND p4.amproc = p5.oid AND (p2.proretset OR p5.proretset OR p2.pronargs != p5.pronargs); -- We can get results as follow: amopclaid | amprocnum | oid | proname | opcname | amopclaid | amprocnum | oid | proname | opcname ---+---+--+-+--+---+---+--+-+-- 2771 | 3 | 2743 | ginarrayextract | _oidvector_ops | 3659 | 3 | 3657 | gin_extract_tsquery | tsvector_ops 2759 | 3 | 2743 | ginarrayextract | _cidr_ops| 3659 | 3 | 3657 | gin_extract_tsquery | tsvector_ops 2768 | 3 | 2743 | ginarrayextract | _name_ops| 3659 | 3 | 3657 | gin_extract_tsquery | tsvector_ops .. 4 But, reading plsql/src/test/regress/sql/opr_sanity.sql, there is a sentence said: We can check that all the referenced instances of the same support routine number take the same number of parameters ? 5 So, ginarrayextract() and gin_extract_tsquery() should take the same number of parameters? Or, We can check that all the referenced instances of the same support routine number take the same number of parameters is not a right? 6 Actually, pgsql allow all the referenced instances of the same support routine number do not take the same number of parameters. Thanks. Fly.Li Tom Lane t...@sss.pgh.pa.us дÈëÓʼþÐÂÎÅ:10550.1246457...@sss.pgh.pa.us... Fly.Li fly...@126.com writes: version: PG8.2.2 MY Question: Why must take the same number of parameters ? Because the GIN code will call it with a particular number of arguments. When I use tsearch2, I found that gin_extract_tsquery() has 3 parameters, it break the rule take the same number of parameters. 3 is the correct number of parameters for an extractQuery function (before 8.4 anyway), so I'm not clear what you are complaining about. 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-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 6:55 PM, Bruce Momjianbr...@momjian.us wrote: bruce wrote: I realize there is the perception that the large patches that were eventually rejected held up the release, but for all the patches I can think of, they were not rejected immediately _because_ we had other valid patches to work on. Once all valid patches were applied, we were quickly able to reject the large unready patches. So, rejecting the large patches early would not have significantly moved the release date earlier. I see no one agrees with my analysis --- no matter; if I unreservedly agreed with others, I wouldn't be here. ;-) There has been discussion about how to be more hard-nosed about rejecting patches. I think it has to start with us being more hard-nosed about giving patches feedback --- the very idea we had to create commit-fests reflects that we historically have not done an organized job of processing patches. Agreed. If we review patches as soon as they appear, and give rapid feedback, we can easily reject patches that take more than a few days for the patch author to resolve, and there would be little slippage; the same goes for dealing with known bugs. I know it can be done, but I don't promise it would be pleasant. Also agreed. It's never pleasant to have a patch rejected/postponed, but it's tolerable if you've gotten some feedback and understand the reasons why. Of course there is no guarantee that you will agree with those reasons, but that's life. Some day you may be the committer and have your turn to irritate patch submitters. :-) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gin--a rule for function parameter
Fly.Li fly...@126.com writes: 1 ginarrayextract() has 2 parameters 2 gin_extract_tsquery() has 3 parameters 3 run sql(from plsql/src/test/regress/sql/opr_sanity.sql), it expect no results: Well, actually what's cheating here is ginarrayextract, not tsearch2. That was fixed as of 8.3. 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-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us writes: There has been discussion about how to be more hard-nosed about rejecting patches. I think it has to start with us being more hard-nosed about giving patches feedback --- the very idea we had to create commit-fests reflects that we historically have not done an organized job of processing patches. If we review patches as soon as they appear, and give rapid feedback, we can easily reject patches that take more than a few days for the patch author to resolve, and there would be little slippage; the same goes for dealing with known bugs. I know it can be done, but I don't promise it would be pleasant. In other words, you propose dropping the idea of commitfests, and expecting committers to spend *all* their time reviewing? Tain't happening. 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-hackers
Re: [HACKERS] HEAD is open for 8.5 development
On Wed, Jul 1, 2009 at 7:30 PM, Tom Lanet...@sss.pgh.pa.us wrote: Let the breakage begin ... regards, tom lane Tom - and all other committers - In order to avoid duplication of effort, we should avoid assigning round-robin reviewers to any patches which the committers feel that they already have adequately covered. In order to do that, we need to make sure we know which ones they are. If you are taking a look at any of the patches submitted for this CommitFest, please put your name next to them on the wiki. Please ALSO add a comment saying something like tgl says: I am reviewing this, no need to assign a round-robin reviewer. During the last CommitFest, we had occasional shenanigans where someone would stick the name of a committer or other community member next to a patch just because they had made some comments on it. But the person whose name got stuck there didn't necessarily know about it or feel any responsibility to conduct a complete review. So it would be helpful if everyone could make sure to add a comment when claiming patches. Thanks, ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Robert Haas wrote: If we review patches as soon as they appear, and give rapid feedback, we can easily reject patches that take more than a few days for the patch author to resolve, and there would be little slippage; ?the same goes for dealing with known bugs. ?I know it can be done, but I don't promise it would be pleasant. Also agreed. It's never pleasant to have a patch rejected/postponed, but it's tolerable if you've gotten some feedback and understand the reasons why. Of course there is no guarantee that you will agree with those reasons, but that's life. Some day you may be the committer and have your turn to irritate patch submitters. :-) Our only limitation is our own sense that we have been fair to patch authors, i.e. there is no external restriction on how we handle things. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: There has been discussion about how to be more hard-nosed about rejecting patches. I think it has to start with us being more hard-nosed about giving patches feedback --- the very idea we had to create commit-fests reflects that we historically have not done an organized job of processing patches. If we review patches as soon as they appear, and give rapid feedback, we can easily reject patches that take more than a few days for the patch author to resolve, and there would be little slippage; the same goes for dealing with known bugs. I know it can be done, but I don't promise it would be pleasant. In other words, you propose dropping the idea of commitfests, and expecting committers to spend *all* their time reviewing? Tain't happening. I don't promise it would be pleasant. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 7:00 PM, Tom Lanet...@sss.pgh.pa.us wrote: Greg Stark gsst...@mit.edu writes: On Tue, Jun 30, 2009 at 5:11 PM, Tom Lanet...@sss.pgh.pa.us wrote: I'm also not prepared to push a large and unstable feature into the tree on the hope that it will get fixed. I didn't have the impression it had any known problems, Simon and others spent a lot of time testing it already. If it didn't have known problems it would have been committed in 8.4. What I've seen of Heikki's work thus far has led me to believe that his reasons for rejecting the patch were good ones, but I don't specifically what they were. It would be helpful, I think, to reiterate them or repost links to the relevant messages in the archives; it would also be great if we could get an estimate of how close the patch is to being committable. Does it still need massive work, or is it getting fairly close, or what? Are the issues code cleanliness/maintainability, bugs, missing functionality? From our conversations at the PGcon development meeting it seems as though there are a lot of people for whom this is a high-priority feature. Perhaps some of them will be willing to help if we give them enough information to work with. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: Bruce Momjian br...@momjian.us writes: If we review patches as soon as they appear, and give rapid feedback, we can easily reject patches that take more than a few days for the patch author to resolve, and there would be little slippage; the same goes for dealing with known bugs. I know it can be done, but I don't promise it would be pleasant. In other words, you propose dropping the idea of commitfests, and expecting committers to spend *all* their time reviewing? Tain't happening. I don't promise it would be pleasant. I'm not sure which part of no you didn't understand, but this committer is not buying into that proposal. 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-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Tom Lane wrote: Bruce Momjian br...@momjian.us writes: If we review patches as soon as they appear, and give rapid feedback, we can easily reject patches that take more than a few days for the patch author to resolve, and there would be little slippage; the same goes for dealing with known bugs. I know it can be done, but I don't promise it would be pleasant. In other words, you propose dropping the idea of commitfests, and expecting committers to spend *all* their time reviewing? Tain't happening. I don't promise it would be pleasant. I'm not sure which part of no you didn't understand, but this committer is not buying into that proposal. Again, I am pointing out it could be done, but it would be unpleasant, as you mentioned. We can't move make progress unless we understand the underlying causes of our delays. I am not suggesting we adopt it for reasons you mentioned. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] First CommitFest: July 15th
On Wed, Jul 1, 2009 at 8:21 PM, Josh Berkusj...@agliodbs.com wrote: There's been a lot of discussion/argument around how to handle the last commitfest, but there seems to be a total consensus that we want to have the first CF on July 15th. I'd like Robert Haas to be the CF Manager for that commitfest if he's available. I can help by running RRR or something. Sounds great. How do we go about putting together a list of available reviewers? Should we create a wikitable to which people can add themselves? Robert, I have not reviewed your software. Do I need a login or something? Just your community login @ http://coridan.postgresql.org/ - but if you send me your community login name I'll give you admin privs, which will allow you to create/modify/delete commitfests and delete comments that you yourself did not create. The main problem is that my fine software only contains test data at this point. If we have any volunteers who are available to migrate the information from the Wiki to my app (which will involve a fair amount of legwork), then I recommend that we accept their help as it will make things easier for the CommitFest management team... which I am all in favor of, especially now that I'm on that team. On the other hand, if we don't have any volunteers, then I recommend that we continue to use the Wiki for this CommitFest but make sure that all patches for the next CommitFest, and any that follow, get added via the app. So, any volunteers? Thanks, ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
