Re: [HACKERS] Segfault in PL/Python
On Sat, 2009-10-31 at 14:24 +0200, Peter Eisentraut wrote: I have discovered an obscure segfault condition in PL/Python. In PLy_output(), when the elog() call in the TRY branch throws an exception (this can happen when a statement timeout kicks in, for example), the PyErr_SetString() call in the CATCH branch can cause a segfault, because the Py_XDECREF(so) call before it releases memory that is still used by the sv variable that PyErr_SetString() uses as argument, because sv points into memory owned by so. Patch is attached. This should be backpatched back to 8.0, where this code was introduced. I also threw in a couple of volatile declarations for variables that are used before and after the TRY. I don't think they caused the crash that I observed, but they could become issues. This patch has been applied to 8.0 - 8.5. -- 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] backup_label in a crash recovery
Tom Lane wrote: I wonder why backup_label isn't automatically removed in normal crash recovery case. Removing it automatically could be catastrophic if done incorrectly, no? It would be no less catastrophic if done incorrectly from outside the postmaster; see for example the problems people have had historically with startup scripts that think they should remove postmaster.pid. I beg to differ. Removing postmaster.pid can lead to a corrupt database. Removing backup_label means that one of your backups will go wrong, and a subsequent pg_stop_backup() will throw an error. If you have a cluster failover during an online backup, I think any reasonable person would suspect that the backup went wrong. And if nothing else does, the error on pg_stop_backup() will tell you. Given a choice, I expect that everybody who is intent enough on availibility to implement such a solution will want the database to come up if it can be done without data loss. Is there a flaw in my reasoning? Yours, Laurenz Albe -- 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] per-tablespace random_page_cost/seq_page_cost
Robert Haas escribió: On Mon, Nov 2, 2009 at 12:40 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Robert Haas escribió: I don't see anything in this code that is very rel-specific, so I think it would be possible to implement spcoptions by just defining RELOPT_KIND_TABLESPACE and ignoring the irony, but that has enough of an unsavory feeling that I'm sure someone is going to complain about it... I suppose we could go through and systematically rename all instances of reloptions to ent(ity)options or storageoptions or gen(eric)options or somesuch... Maybe I missed part of the discussion, but do these really need to be handled like reloptions instead of like datoptions? Perhaps the deciding factor is that we want to parse them once and store them in a cache, so like reloptions; the others are used once per connection and then thrown away. This may be a stupid question, but what are datoptions? $ git grep datoptions datoptions are gone now, replaced by pg_db_role_settings, but you could find them in 8.4. They were an array of options much like reloptions, except that they didn't go through the reloptions.c code for parsing. If this is the case, then I think we could just decide that their name is reloptions due to hysterical reasons and be done with it. Yeah. It's particularly unfortunate that we call them reloptions in the code but storage parameters in the documentation. Neither is a particularly good name, and having two different ones is extra-poor. But I'm fine with leaving the names as they are and moving on, if no one objects too much. Speak now or don't complain about it after I write the patch! Maybe after we move to Git we can rename them in the code? -- 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] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)
On Sun, 2009-09-27 at 21:49 -0400, Robert Haas wrote: On Wed, Sep 23, 2009 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jaime Casanova jcasa...@systemguards.com.ec writes: i extracted the functions to connect that Heikki put on psql in his patch for determining client_encoding from client locale and put it in libpq so i follow the PQconnectdbParams(* params[]) approach. I got around to looking at the actual patch a bit. I hadn't understood why it was so small, but now I do: it's implemented as a wrapper around PQconnectdb. That is, it takes the given keywords and values, and builds a conninfo string, which PQconnectdb then has to pull apart again. Based on this review, it sounds like this patch will need a major rewrite before it can be seriously reviewed. Given that, I think it makes sense to postpone this to the next CommitFest, so I am going to mark it as Returned with Feedback. Is anyone planning to do further work on this? This appears to be blocking the client_encoding=auto feature. -- 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] per-tablespace random_page_cost/seq_page_cost
On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: If this is the case, then I think we could just decide that their name is reloptions due to hysterical reasons and be done with it. Yeah. It's particularly unfortunate that we call them reloptions in the code but storage parameters in the documentation. Neither is a particularly good name, and having two different ones is extra-poor. But I'm fine with leaving the names as they are and moving on, if no one objects too much. Speak now or don't complain about it after I write the patch! Maybe after we move to Git we can rename them in the code? I'm OK with renaming it before I start working on the main patch, or after it's committed, or never. I just don't want to have to rebase it in the middle. ...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] per-tablespace random_page_cost/seq_page_cost
Robert Haas robertmh...@gmail.com writes: Le 1 nov. 2009 à 13:43, Greg Stark gsst...@mit.edu a écrit : We could have a column for all booleans, a column for all integers, etc. but that's not really any more normalized than having a single column for all the types with a rule for how to marshal each value type. Thé other day, on IRC, someone wanted a dynamic table accepting value in whichever column you name. That would probably mean having a special INSERT INTO which ALTER TABLE ... ADD COLUMN ... for you. Maybe INSERT INTO ... WITH ADD COLUMN OPTION; This sure looks suspicious, but the asking came from another product and it seems that could help here too. Oh and you get text columns I guess, by default... If you want to start a discussion about a topic that is completely unrelated to this one, then please start a new thread. Auto adding a column on INSERT when it does not exists would help tools to add columns in there, to avoid having to follow EAV model. Maybe this property would be tied to the table rather than the INSERT, though, or maybe we'd be better without it at all. But it's related to the case at hand, yes. -- Dimitri Fontaine PostgreSQL DBA, Architecte -- 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] per-tablespace random_page_cost/seq_page_cost
Robert Haas escribió: On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: If this is the case, then I think we could just decide that their name is reloptions due to hysterical reasons and be done with it. Yeah. It's particularly unfortunate that we call them reloptions in the code but storage parameters in the documentation. Neither is a particularly good name, and having two different ones is extra-poor. But I'm fine with leaving the names as they are and moving on, if no one objects too much. Speak now or don't complain about it after I write the patch! Maybe after we move to Git we can rename them in the code? I'm OK with renaming it before I start working on the main patch, or after it's committed, or never. I just don't want to have to rebase it in the middle. I think after we move to Git goes well after after your patch is committed, so we're OK. -- 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] per-tablespace random_page_cost/seq_page_cost
On Tue, Nov 3, 2009 at 7:44 AM, Dimitri Fontaine dfonta...@hi-media.com wrote: Robert Haas robertmh...@gmail.com writes: Le 1 nov. 2009 à 13:43, Greg Stark gsst...@mit.edu a écrit : We could have a column for all booleans, a column for all integers, etc. but that's not really any more normalized than having a single column for all the types with a rule for how to marshal each value type. Thé other day, on IRC, someone wanted a dynamic table accepting value in whichever column you name. That would probably mean having a special INSERT INTO which ALTER TABLE ... ADD COLUMN ... for you. Maybe INSERT INTO ... WITH ADD COLUMN OPTION; This sure looks suspicious, but the asking came from another product and it seems that could help here too. Oh and you get text columns I guess, by default... If you want to start a discussion about a topic that is completely unrelated to this one, then please start a new thread. Auto adding a column on INSERT when it does not exists would help tools to add columns in there, to avoid having to follow EAV model. Maybe this property would be tied to the table rather than the INSERT, though, or maybe we'd be better without it at all. But it's related to the case at hand, yes. I fail to see how. Even if such a feature were accepted, which frankly I doubt it would be since I think you could code it up yourself by using a function that takes an hstore and performs the column additions for you as need be, I seriously doubt that it could be made to work for system tables. And even if it could, it wouldn't address my original point, which is that it would be faster to access these properties by pulling them out of Form_pg_tablespace rather than needing some more complicated system for extracting them - because you certainly can't dynamically change the definition of a C struct that is compiled into the executable dynamically at runtime. Besides all that, what you are talking about here is a SQL-level feature with SQL syntax. For possibly-obvious reasons, we don't implement commands like ALTER TABLE by transforming them into SQL queries that update the system catalogs. So even if someone did implement this and it were accepted and it worked on system catalogs, it still wouldn't be of any assistance to me in implementing ALTER TABLESPACE ... SET. Can we stop now? ...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] per-tablespace random_page_cost/seq_page_cost
On Tue, Nov 3, 2009 at 7:51 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: Robert Haas escribió: On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera alvhe...@commandprompt.com wrote: If this is the case, then I think we could just decide that their name is reloptions due to hysterical reasons and be done with it. Yeah. It's particularly unfortunate that we call them reloptions in the code but storage parameters in the documentation. Neither is a particularly good name, and having two different ones is extra-poor. But I'm fine with leaving the names as they are and moving on, if no one objects too much. Speak now or don't complain about it after I write the patch! Maybe after we move to Git we can rename them in the code? I'm OK with renaming it before I start working on the main patch, or after it's committed, or never. I just don't want to have to rebase it in the middle. I think after we move to Git goes well after after your patch is committed, so we're OK. Or if not, then it's my own fault. :-) ...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] EOL for 7.4?
We had a discussion back in July about our maintenance policy and the upshot of that discussion was that there were relatively few objections to dropping support for 7.4 - I believe Andrew Dunstan was the only one who spoke against it, and it wasn't clear how strenuous his objections were - but there were objections even to setting an end-of-life date for any subsequent release. However, we never really took any action based on that conversation. Maybe it's time? Part of the reason I suggest this is because it seems that not much gets patched back that far any more. AFAICT, committers basically stop back-patching at the point where it becomes an inconvenience, and most of the time that happens before you get that far back. As a result, while 7.4 is technically supported, it's not really all that supported. We are also very close to six years from the original release, if that's a magic number for anyone. ...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] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)
Peter Eisentraut pete...@gmx.net writes: Is anyone planning to do further work on this? This appears to be blocking the client_encoding=auto feature. Huh? Why would there be any linkage? This is just offering an alternative way to set connection options, it has nothing to do with what the set of options is. 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] A small bug in gram.y
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Here's an example that exercises those paths: postgres=# SELECT 'aa' NOT SIMILAR TO 123; ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist LINE 1: SELECT 'aa' NOT SIMILAR TO 123; ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. postgres=# SELECT 'aa' SIMILAR TO 123; ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist LINE 1: SELECT 'aa' SIMILAR TO 123; ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. postgres=# I think the former error location is better. FWIW, I like the second one better, and if you check around you'll find that it matches most other similar stuff, eg regression=# select 12 like 34; ERROR: operator does not exist: integer ~~ integer LINE 1: select 12 like 34; ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. I think the current coding probably is just a typo, but hadn't gotten around to doing anything 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] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)
On Tue, 2009-11-03 at 09:32 -0500, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: Is anyone planning to do further work on this? This appears to be blocking the client_encoding=auto feature. Huh? Why would there be any linkage? This is just offering an alternative way to set connection options, it has nothing to do with what the set of options is. Right, but we got stuck when we realized that we would need to switch psql's connection handling from PQsetdb to PQconnectdb, which would be annoying. And at the moment everyone involved appears to be waiting on this hypothetical newer version of PQconnectdb to make the original patch easier. -- 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] EOL for 7.4?
Robert Haas wrote: We had a discussion back in July about our maintenance policy and the upshot of that discussion was that there were relatively few objections to dropping support for 7.4 - I believe Andrew Dunstan was the only one who spoke against it, and it wasn't clear how strenuous his objections were - but there were objections even to setting an end-of-life date for any subsequent release. However, we never really took any action based on that conversation. Maybe it's time? I don't object to EOLing 7.4, although I have a certain nostalgia for it ... it's the first release that contains anything of mine in it ;-) What I want is a proper process for declaring an EOL, though. In particular, we should announce it loudly and well in advance (by which I mean several months). The PR team should swing into action with a press release along the lines of PostgreSQL release version n.n. will reach the end of its maintenance life on -mm-dd. No patches of any kind will be made after that date. Users of this version are advised to start planning now to upgrade to a more modern version. I think the objections to declaring a hard and fast release lifetime in advance were well taken, though. And they aren't really relevant to a discussion of whether it is now appropriate to EOL 7.4. Part of the reason I suggest this is because it seems that not much gets patched back that far any more. AFAICT, committers basically stop back-patching at the point where it becomes an inconvenience, and most of the time that happens before you get that far back. As a result, while 7.4 is technically supported, it's not really all that supported. Tom just backpatched something to 7.4 the other day. It's not a matter of convenience, but many things that get backpatched relate to features introduced in relatively recent releases, not surprisingly. e.g. see Peter's commit message from today, Backpatched back to 8.0, where this code was introduced. Very occasionally things are seriously hard to backpatch. But that's the exception, not the rule. We are also very close to six years from the original release, if that's a magic number for anyone. Actually, I think it's a pretty good lifetime for a release. Many users don't want to migrate as soon as a new version comes out, they want to let it settle down. And they also don't want to have to go through the pain of migrating more than once every few years - five would be a good number here. (This has nothing to do with whether or not we have in place upgrade. It's more to do with the effort involved in revalidating a large application against a new release.) So allowing for those two things, six years is an excellent lifetime. And 7.4 has been pretty darn robust, it should be noted. The fact that we have quite long release lifetimes and outstanding release stability is a major plus for us. I have had users tell me over and over that that's one of the reasons they use Postgres. 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] backup_label in a crash recovery
Albe == Albe Laurenz laurenz.a...@wien.gv.at writes: Albe Removing postmaster.pid can lead to a corrupt database. Albe Removing backup_label means that one of your backups will go Albe wrong, and a subsequent pg_stop_backup() will throw an error. Albe If you have a cluster failover during an online backup, I think Albe any reasonable person would suspect that the backup went wrong. Albe And if nothing else does, the error on pg_stop_backup() will Albe tell you. [...] Albe Is there a flaw in my reasoning? Yes. Imagine the following scenario: the system crashed while pg_start_backup was in effect (so backup_label exists), and the postmaster is about to start up. i.e. you're at the point where you might naively imagine that you can delete the backup_label. How do you distinguish between these two scenarios: 1) you're starting up in a data dir where you crashed in the middle of a backup 2) you're starting up in a data dir that is a restore of a base backup, but no recovery.conf has been created (hint: you can't) If in scenario 2, you remove the backup_label and proceed with recovery, there is a significant chance (depending on the timing, and if you didn't exclude pg_xlog from the backup) that recovery will _think_ it succeeds but actually leaves you with a corrupt data directory. -- Andrew (irc:RhodiumToad) -- 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] new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)
Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: Is anyone planning to do further work on this? This appears to be blocking the client_encoding=auto feature. Huh? Why would there be any linkage? This is just offering an alternative way to set connection options, it has nothing to do with what the set of options is. The client_encoding=auto feature would use the new function in psql to set the client_encoding to 'auto'. Otherwise it needs to construct a properly quoted connection string and pass it to the existing PQconnectdb, which is a bit laborious. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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] EOL for 7.4?
2009/11/3 Andrew Dunstan and...@dunslane.net: Robert Haas wrote: We had a discussion back in July about our maintenance policy and the upshot of that discussion was that there were relatively few objections to dropping support for 7.4 - I believe Andrew Dunstan was the only one who spoke against it, and it wasn't clear how strenuous his objections were - but there were objections even to setting an end-of-life date for any subsequent release. However, we never really took any action based on that conversation. Maybe it's time? I don't object to EOLing 7.4, although I have a certain nostalgia for it ... it's the first release that contains anything of mine in it ;-) What I want is a proper process for declaring an EOL, though. In particular, we should announce it loudly and well in advance (by which I mean several months). The PR team should swing into action with a press release along the lines of PostgreSQL release version n.n. will reach the end of its maintenance life on -mm-dd. No patches of any kind will be made after that date. Users of this version are advised to start planning now to upgrade to a more modern version. Didn't we discuss EOLing based on number of previous versions? As in if we now announced that 7.4 would EOL when we release 8.5? (Though based on previous track record, that means it really should've been EOLed when we released 8.4, I guess) We are also very close to six years from the original release, if that's a magic number for anyone. Actually, I think it's a pretty good lifetime for a release. Many users don't want to migrate as soon as a new version comes out, they want to let it settle down. And they also don't want to have to go through the pain of migrating more than once every few years - five would be a good number here. (This has nothing to do with whether or not we have in place upgrade. It's more to do with the effort involved in revalidating a large application against a new release.) So allowing for those two things, six years is an excellent lifetime. And 7.4 has been pretty darn robust, it should be noted. Yeah, if one version has to stick around for a long time, 7.4 was a good choice for it :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] EOL for 7.4?
Andrew Dunstan and...@dunslane.net writes: Robert Haas wrote: Part of the reason I suggest this is because it seems that not much gets patched back that far any more. Tom just backpatched something to 7.4 the other day. A quick look in the cvs history shows 5 commits to 7.4 since the last set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3. A couple of these patches were Windows-specific and were made only back to 8.2 because we desupported Windows in older branches awhile back. So far as I can see, the others were all made as far back as applicable. I think the lack of churn in 7.4 just means it's gotten pretty darn stable. I'm not averse to EOL'ing 7.4, but I don't think it's fair to claim that we already stopped supporting 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] A small bug in gram.y
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: LINE 1: SELECT 'aa' NOT SIMILAR TO 123; ^ LINE 1: SELECT 'aa' SIMILAR TO 123; ^ I think the former error location is better. So do I. -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] backup_label in a crash recovery
[ after further thought... ] Andrew Gierth and...@tao11.riddles.org.uk writes: How do you distinguish between these two scenarios: 1) you're starting up in a data dir where you crashed in the middle of a backup 2) you're starting up in a data dir that is a restore of a base backup, but no recovery.conf has been created (hint: you can't) Hmm ... you can not tell this if the postmaster just started, and I agree that removing backup_label in such a case is too risky. However, in a typical crash scenario the postmaster doesn't die, it just kills off and restarts its children; and in that scenario we do have additional knowledge, namely that the postmaster was already up. I think it could be safe and useful to forcibly remove backup_label before commencing recovery, *if* we know that the system had previously been in fully-operational status. However, this begs the question: does a backend crash necessarily imply that an in-progress base backup has to be canceled and restarted from scratch? It's not clear to me why you wouldn't consider that the backup can keep going. So maybe what we really want here is not to remove the label file, but to have the postmaster signal to the recovery process that it knows this is a crash recovery and any backup_label should be ignored. 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] EOL for 7.4?
Tom Lane escribió: A quick look in the cvs history shows 5 commits to 7.4 since the last set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3. A couple of these patches were Windows-specific and were made only back to 8.2 because we desupported Windows in older branches awhile back. So far as I can see, the others were all made as far back as applicable. I think the lack of churn in 7.4 just means it's gotten pretty darn stable. If it's all that stable, what's the point in EOLing it? The only extra pain it causes is having to check whether each patch needs to be backpatched to it or not. (Maybe this means we can announce today that we're going to EOL it in a distant future, say in a year.) -- 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] A small bug in gram.y
Kevin Grittner kevin.gritt...@wicourts.gov writes: Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: LINE 1: SELECT 'aa' NOT SIMILAR TO 123; ^ LINE 1: SELECT 'aa' SIMILAR TO 123; ^ I think the former error location is better. So do I. Uh, why? It looks like it's complaining about the constant 123, not about the operator. 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] EOL for 7.4?
Magnus Hagander wrote: 2009/11/3 Andrew Dunstan and...@dunslane.net: Robert Haas wrote: We had a discussion back in July about our maintenance policy and the upshot of that discussion was that there were relatively few objections to dropping support for 7.4 - I believe Andrew Dunstan was the only one who spoke against it, and it wasn't clear how strenuous his objections were - but there were objections even to setting an end-of-life date for any subsequent release. However, we never really took any action based on that conversation. Maybe it's time? I don't object to EOLing 7.4, although I have a certain nostalgia for it ... it's the first release that contains anything of mine in it ;-) What I want is a proper process for declaring an EOL, though. In particular, we should announce it loudly and well in advance (by which I mean several months). The PR team should swing into action with a press release along the lines of PostgreSQL release version n.n. will reach the end of its maintenance life on -mm-dd. No patches of any kind will be made after that date. Users of this version are advised to start planning now to upgrade to a more modern version. Didn't we discuss EOLing based on number of previous versions? As in if we now announced that 7.4 would EOL when we release 8.5? (Though based on previous track record, that means it really should've been EOLed when we released 8.4, I guess) Indeed I recall that at least once the plan was to EOL 7.4 with the release of 8.4(or rather keeping a max of 5 active release branches) but I guess we kinda forgot about that :) Stefan -- 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] EOL for 7.4?
On Tue, 2009-11-03 at 13:01 -0300, Alvaro Herrera wrote: Tom Lane escribió: A quick look in the cvs history shows 5 commits to 7.4 since the last set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3. A couple of these patches were Windows-specific and were made only back to 8.2 because we desupported Windows in older branches awhile back. So far as I can see, the others were all made as far back as applicable. I think the lack of churn in 7.4 just means it's gotten pretty darn stable. If it's all that stable, what's the point in EOLing it? The only extra pain it causes is having to check whether each patch needs to be backpatched to it or not. Agreed Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? -- Simon Riggs www.2ndQuadrant.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] EOL for 7.4?
2009/11/3 Simon Riggs si...@2ndquadrant.com: On Tue, 2009-11-03 at 13:01 -0300, Alvaro Herrera wrote: Tom Lane escribió: A quick look in the cvs history shows 5 commits to 7.4 since the last set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3. A couple of these patches were Windows-specific and were made only back to 8.2 because we desupported Windows in older branches awhile back. So far as I can see, the others were all made as far back as applicable. I think the lack of churn in 7.4 just means it's gotten pretty darn stable. If it's all that stable, what's the point in EOLing it? The only extra pain it causes is having to check whether each patch needs to be backpatched to it or not. Agreed Unless there are unfixable data loss bugs in it, I say we keep it. There's a difference between doing it and promising it. As long as we are supporting it, we *have* to backpatch critical things, even if that is a lot of extra work. Normally it isn't, but the case will come up. Nothing prevents us from backpatching simple things, and still releasing minors, for a non-supported version. It's just that we don't promise to do it. Many people still run it, so why make them move? Many people still run 7.3... We made them move... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] EOL for 7.4?
On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote: Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? There are non-trivial amounts of effort required to produce and test packages for each branch we maintain. That affects all of the packagers to varying degrees and should not be overlooked. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com PGDay.EU 2009 Conference: http://2009.pgday.eu/start -- 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] A small bug in gram.y
Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: LINE 1: SELECT 'aa' NOT SIMILAR TO 123; ^ LINE 1: SELECT 'aa' SIMILAR TO 123; ^ I think the former error location is better. So do I. Uh, why? It looks like it's complaining about the constant 123, not about the operator. I wrote that before I saw your post, which left me ambivalent. My thinking was that it seems clearest to me when it points to the token at which things become untenable. At this point there it is still possible for the statement to be completed with a valid query: SELECT 'aa' SIMILAR TO At this point it is not: SELECT 'aa' SIMILAR TO 123 If you had something like '123' instead of 123, it would be OK, so I'd be good with it complaining about the constant 123. SELECT 'aa' SIMILAR TO '123'; ?column? -- f (1 row) But if we normally point to the operator when it isn't in the set allowed with the given operands, then consistency trumps the above. I yield the point. -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] EOL for 7.4?
On Tue, 2009-11-03 at 16:37 +, Dave Page wrote: On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote: Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? There are non-trivial amounts of effort required to produce and test packages for each branch we maintain. That affects all of the packagers to varying degrees and should not be overlooked. I see we've already removed it from the home page anyway. People that are running older releases need to be able to find info about our position with respect to earlier releases. Keeping the docs available is important, since people may need to read up on how to dump data so it can be upgraded. We need a link to older releases with mention something like 7.4 Considered Stable, no tracking or fixing of new bugs 7.3 Considered Stable, no tracking or fixing of new bugs 7.2 Considered Unstable; upgrade immediately to avoid data loss Personally, I would be more inclined to keep 7.4 as a supported version and remove support for 8.0, possibly 8.1 also. There's no need to remove them in chronological order - we should remove them based upon whether its sensible to maintain them further. It also helps if we can say we support software over long periods of time; that's very important for embedded software. -- Simon Riggs www.2ndQuadrant.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] A small bug in gram.y
Tom Lane wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: LINE 1: SELECT 'aa' NOT SIMILAR TO 123; ^ LINE 1: SELECT 'aa' SIMILAR TO 123; ^ I think the former error location is better. So do I. Uh, why? It looks like it's complaining about the constant 123, not about the operator. The problem *is* in the constant 123. It's of wrong type for SIMILAR TO operator. I guess your viewpoint is that the operator isn't correct for the operands. Fair enough. BTW, the corresponding error in the SIMILAR TO ... ESCAPE ... syntax is: postgres=# SELECT 'aa' SIMILAR TO 123 ESCAPE 'f'; ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist LINE 1: SELECT 'aa' SIMILAR TO 123 ESCAPE 'f'; ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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] EOL for 7.4?
2009/11/3 Simon Riggs si...@2ndquadrant.com: On Tue, 2009-11-03 at 16:37 +, Dave Page wrote: On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote: Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? There are non-trivial amounts of effort required to produce and test packages for each branch we maintain. That affects all of the packagers to varying degrees and should not be overlooked. I see we've already removed it from the home page anyway. People that are running older releases need to be able to find info about our position with respect to earlier releases. Keeping the docs available is important, since people may need to read up on how to dump data so it can be upgraded. We need a link to older releases with mention something like 7.4 Considered Stable, no tracking or fixing of new bugs 7.3 Considered Stable, no tracking or fixing of new bugs 7.2 Considered Unstable; upgrade immediately to avoid data loss Personally, I would be more inclined to keep 7.4 as a supported version and remove support for 8.0, possibly 8.1 also. There's no need to remove them in chronological order - we should remove them based upon whether its sensible to maintain them further. It also helps if we can say we support software over long periods of time; that's very important for embedded software. +1 Pavel -- Simon Riggs www.2ndQuadrant.com -- 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] operator exclusion constraints
On Mon, 2009-11-02 at 18:28 +, Simon Riggs wrote: I like the NOT here because CHECK NOT = seems to convey pretty clearly what it is you are checking for. Because NOT is reserved and can't appear as a connective, I think that this approach might allow a non-reserved leading word, thus possibly the second variant would work without reserving CONSTRAIN. I have not tested whether bison agrees with me though ;-). In any case I think CHECK NOT = reads pretty well, and don't feel a strong urge to use some other word there. Peter, do any of these ideas work for you? It looks like this opens the door to using a word other than CHECK. CONSTRAIN NOT is a little awkward, is there another word that might work better? I'm not excited about using NOT, because I think it has a hint of a double-negative when combined with EXCLUSION. The original idea was to specify the way to find tuples mutually exclusive with the new tuple; and NOT makes that a little less clear, in my opinion. But I'm fine with it if that's what everyone else thinks is best. Regards, Jeff Davis -- 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] A small bug in gram.y
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: BTW, the corresponding error in the SIMILAR TO ... ESCAPE ... syntax is: postgres=# SELECT 'aa' SIMILAR TO 123 ESCAPE 'f'; ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist LINE 1: SELECT 'aa' SIMILAR TO 123 ESCAPE 'f'; ^ Well, that's complaining specifically about the ESCAPE part of it. This does expose the implementation detail that we try to build the similar_escape() call before the overall similar() function call. 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] EOL for 7.4?
Simon Riggs si...@2ndquadrant.com writes: Personally, I would be more inclined to keep 7.4 as a supported version and remove support for 8.0, possibly 8.1 also. That would be basically useless from a maintenance-effort perspective --- if you don't work back through the branches in a methodical way when back-patching, you're liable to make mistakes; and in any case you have to study each branch delta even if you don't bother to commit. 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] A small bug in gram.y
Tom Lane wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: BTW, the corresponding error in the SIMILAR TO ... ESCAPE ... syntax is: postgres=# SELECT 'aa' SIMILAR TO 123 ESCAPE 'f'; ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist LINE 1: SELECT 'aa' SIMILAR TO 123 ESCAPE 'f'; ^ Well, that's complaining specifically about the ESCAPE part of it. This does expose the implementation detail that we try to build the similar_escape() call before the overall similar() function call. Yeah. The ESCAPE 'f' part is OK. It's still the 123 that's of the wrong type. I'd say that message should point to 123 as well. Or to SIMILAR, if we take your stance that the error is with the SIMILAR TO operator in general. But pointing to ESCAPE is just weird. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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] A small bug in gram.y
Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us wrote: Uh, why? It looks like it's complaining about the constant 123, not about the operator. I wrote that before I saw your post, which left me ambivalent. My thinking was that it seems clearest to me when it points to the token at which things become untenable. Our error pointers are *not* about how far to the right did parsing get, they're about which part of the construct seems to be most directly related to the problem. Otherwise most of them would point at the ending semicolon ;-). A possibly less flippant example is select nosuchfunction(1,2,3,avalidfunction(4)); ^ select nosuchfunction(1,2,3,avalidfunction(4)); ^ Which of these is less likely to be misread about which function is being complained of? 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] operator exclusion constraints
Jeff Davis pg...@j-davis.com writes: I'm not excited about using NOT, because I think it has a hint of a double-negative when combined with EXCLUSION. Well, the choice of EXCLUSION isn't set in stone either ... 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] EOL for 7.4?
On Tue, 2009-11-03 at 16:37 +, Dave Page wrote: On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote: Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? There are non-trivial amounts of effort required to produce and test packages for each branch we maintain. That affects all of the packagers to varying degrees and should not be overlooked. This presumes a single group of packagers that does all releases. We'd be the only project that does that, AFAICS. Seems strange to limit tasks to just the same few people all the time. We could ask for volunteer maintainers for releases, rather than just say the X people that do all the work no longer wish to do it and so we're not going to let anyone else either. No volunteers, no releases. That is exactly how this current project got started in the first place - picking up the maintenance responsibility on code that the original authors no longer wished to maintain. As in all things, any major changes with respect to packages should be discussed publicly, with notice given of any changes. Anybody that feels it is worth supporting could then come forward to do so. I hope we can avoid a sarcastic over to you then Simon reply. I'm not volunteering for it, but we should give others the opportunity to do so. My belief is there is a substantial user community for 7.4, and for 7.3 also. There is no reason why we should act like a commercial company when we're a volunteer organisation. So suggestion: announce that 7.4 will be EOLd in 6 months unless volunteers come forward to support further releases. At the same time, announce what the EOL plans are for other releases, so people can begin planning upgrades. In most stable production systems the planning cycle can extend to years, rather than weeks or months. -- Simon Riggs www.2ndQuadrant.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] A small bug in gram.y
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: ... But pointing to ESCAPE is just weird. Maybe. The implementation's-eye view of this is that the construct is data SIMILAR-operator (pattern ESCAPE-operator escape-char) but I agree that isn't the way a user will think of it. I could see making the location be that of the SIMILAR keyword for both of the operators. 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] EOL for 7.4?
On Tue, Nov 3, 2009 at 10:46 AM, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: Robert Haas wrote: Part of the reason I suggest this is because it seems that not much gets patched back that far any more. Tom just backpatched something to 7.4 the other day. A quick look in the cvs history shows 5 commits to 7.4 since the last set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3. A couple of these patches were Windows-specific and were made only back to 8.2 because we desupported Windows in older branches awhile back. So far as I can see, the others were all made as far back as applicable. I think the lack of churn in 7.4 just means it's gotten pretty darn stable. I'm not averse to EOL'ing 7.4, but I don't think it's fair to claim that we already stopped supporting it. Well, that would be overstating my position. We haven't stopped supporting it, but there's less and less stuff that applies that far back. I think it's better to draw a line in the sand and say we're going to stop supporting this release on this date rather than letting it go on and on and then waking up and realizing hmm, nothing ever applies that far back any more, I guess we don't support 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
Re: [HACKERS] EOL for 7.4?
On Tue, Nov 3, 2009 at 5:23 PM, Robert Haas robertmh...@gmail.com wrote: Well, that would be overstating my position. We haven't stopped supporting it, but there's less and less stuff that applies that far back. I think it's better to draw a line in the sand and say we're going to stop supporting this release on this date rather than letting it go on and on and then waking up and realizing hmm, nothing ever applies that far back any more, I guess we don't support it. If there are few or no patches that have to be back-patched then that seems like an argument against EOLing it -- we can support it basically for free! Realistically we're going to EOL it as soon as the first major bug is found that *doesn't* back patch readily. There's relatively low cost to supporting it up until that bug is found, and apparently it hasn't been found it. The dangers I see are: 1) The committers waste time back patching minor bug fixes to a release we would rather people not be using anyways. 2) Relatively few people are using it so perhaps the reason we haven't found any major bugs recently is because nobody's pushing it hard any more. 3) We're effectively making a promise we have no intention of delivering on. We claim we support it but when we find that hard-to-fix security problem or data corruption problem we'll suddenly EOL it leave people hanging. I think all of these are pretty minor problems in practice. The first because the committers themselves don't seem to be concerned, the second because these releases got pushed pretty hard for pretty long already, and the third because as Steve Crawford mentioned EOLing software doesn't instantly render it useless. It's not like we make any real support commitments unless you actually contract one of our employers anyways. And even if a bug isn't fixed you can usually engineer your application to work around the problem anyways by, for example, avoiding use of hash indexes or using password authentication instead of SSL certs, or whatever. -- greg -- 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] backup_label in a crash recovery
Hi, On Wed, Nov 4, 2009 at 12:01 AM, Andrew Gierth and...@tao11.riddles.org.uk wrote: 2) you're starting up in a data dir that is a restore of a base backup, but no recovery.conf has been created Is the scenario 2 (i.e., a normal crash recovery without recovery.conf) supported in postgres? But, anyway, it's possible by admin's error in operation. So maybe backup_label should not be removed automatically for the fail-safe protection, in that case. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] EOL for 7.4?
All, So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in favor of doing so in, say, February after an announcement this month. The main reason I'm in favor of this is that we have a lot of users using 7.4 out of inertia, and they need a message that 7.4 is not supported to get them to upgrade. I can think of several here in SF who have been working on upgrade plans for the past 3 years. An EOL is what's needed to give them a kick in the pants. The same goes for other OSS projects. There's quite a few random OSS apps which were created on PG 7.4 and have never offered their users an upgrade path (Gnuworld comes to mind). They need an EOL announcement to get them motivated to upgrade. This isn't just a matter of supporting these users; it's a matter of what new developers think of Postgres. Programmers judge PG based on the version they first encounter, and they often don't check to see if later versions exist or what features they have. We'd want to do a full publicity around this, including a how do I upgrade page and an what does EOL mean for an OSS project page. If this goes well, we could EOL 8.0 after 8.5 comes out, and thus decrease our maintenance burden. This will also create some favorable spin around how long we do keep patching stuff ... how many other OSS projects batch-fix 5 years? Also, as Greg points out, 7.4 is just waiting for some exploit which is horribly hard to backpatch for us to desupport it on short notice, and that is NOT a service to our users. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote: You're not going to take all those little dribs and drabs of responsibility and transfer them to one person, or even one group of people. With respect to all the people you just mentioned, I don't see any reason why other people could not perform the duties you describe. Of course, it might require a little effort, as we might expect of any handover of responsibility. Those last 3 words seem to be a big sticking point, so much so that we're not even going to ask whether somebody else is willing to try. I see no reason to act that way and certainly no benefit for our users. -- Simon Riggs www.2ndQuadrant.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] EOL for 7.4?
Many people still run [7.4], so why make them move? Many people still run 7.3... We made them move.. A nitpick. Nobody made anyone move. PHP 4 was EOL some time ago but is still in widespread use. We still see occasional postings regarding 7.3 and sometimes even earlier. The software doesn't suddenly stop working when it hits EOL. It is just an expectations-setting statement to end-users that the release is no longer likely to receive attention from the core team. Users are, of course, free to use/self-support the software as they see fit. It's open-source, after all. Cheers, Steve (who is in favor of 7.4 EOL despite one remaining 7.4 server in my upgrade queue) -- 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] EOL for 7.4?
On Tue, 2009-11-03 at 10:04 -0800, Steve Crawford wrote: Users are, of course, free to use/self-support the software as they see fit. It's open-source, after all. I've heard that a lot recently: It's open source, after all. Is this project not open source any more? Surely this project should be encouraging people within the project to take on new tasks. I don't think anybody should be forced to do anything they don't want to do. So if particular developers want to avoid patching certain releases, I respect that. But I don't see why *this* project cannot allow others to take on the tasks those developers choose not to perform. Why are we forcing people into a position where they have to set up their own independent project, what others would call a fork, in order to support software? Why are we not even willing to ask whether someone is willing? It all seems very strange to me. -- Simon Riggs www.2ndQuadrant.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] EOL for 7.4?
On Tue, Nov 03, 2009 at 10:32:17AM -0800, Josh Berkus wrote: So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in favor of doing so in, say, February after an announcement this month. The main reason I'm in favor of this is that we have a lot of users using 7.4 out of inertia, and they need a message that 7.4 is not supported to get them to upgrade. I can think of several here in SF who have been working on upgrade plans for the past 3 years. An EOL is what's needed to give them a kick in the pants. The same goes for other OSS projects. There's quite a few random OSS apps which were created on PG 7.4 and have never offered their users an upgrade path (Gnuworld comes to mind). They need an EOL announcement to get them motivated to upgrade. +1 -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- 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] EOL for 7.4?
Simon, Why are we not even willing to ask whether someone is willing? It all seems very strange to me. Mostly because, I think, nobody can picture how this would be structured or where the people would come from. Surely a 7.4 maintainer would do only one platform? Or only source? Can we call 7.4 a maintained version if it's only patched for Debian? Also, given the other needs we have for technical skills, this would depend on finding people who were good enough to put out stable packages for 7.4, but wasn't interested in contributing to the project in any other way. If these people are available for other tasks, we'd *far* rather have them testing 8.5, reviewing code, updating drivers, writing docs, making tools, etc. So I don't think that anyone is opposed to your proposal, they just don't (or at least I don't) see a practical way to pursue it. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, Nov 3, 2009 at 1:32 PM, Josh Berkus j...@agliodbs.com wrote: Also, as Greg points out, 7.4 is just waiting for some exploit which is horribly hard to backpatch for us to desupport it on short notice, and that is NOT a service to our users. That is along the line of my concerns as well. Based on a quick look through my pgsql-bugs email, it seems that we don't get many bug reports for 7.4 or even 8.0. Mostly, the fixes that are being back-patched to 7.4 are problems that were found on (much) later releases and happened to go all the way back. We are supporting 7.4 to the extent that the 7.4 code overlaps with the 8.4 code (soon, the 8.5 code), but are we supporting the code in 7.4 that IS NO LONGER IN HEAD? I suspect we are to a point, but not really - and I don't believe that the removed code is bug-free any more than I believe that HEAD is bug-free. I don't really object to supporting 7.4 on the grounds that it is a lot of work. It obviously isn't, or the committers would have stopped doing it before now. I'm more concerned about the perception that the code is more supported than it really is. If we don't want to actually EOL 7.4, then perhaps we should decide for which releases we'd be willing to fix a major bug that affected only that release and for which we would not, and then publish that information so that users can make an informed decision. ...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] EOL for 7.4?
Is a somewhat related question how long are the various commercial support organizations committed to supporting 7.4? I guess support companies might support their client's systems for longer or shorter times than the community patches the old versions. No doubt it's easier for them if the community does the backpatching. But if any of those companies has a lot of 7.4 clients, they might be tempted to deal with backpatches for their clients even after the community stops. -- 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] EOL for 7.4?
On Tue, Nov 3, 2009 at 2:24 PM, Greg Sabino Mullane g...@turnstep.com wrote: That will get some, but not others. What really makes people upgrade their database is when their database driver stops working against it. :) ROFL. ...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] EOL for 7.4?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 The other Greg wrote: Realistically we're going to EOL it as soon as the first major bug is found that *doesn't* back patch readily. There's relatively low cost to supporting it up until that bug is found, and apparently it hasn't been found it. I hope this is not the case, for sane definitions of readily. We have an implicit promise to support 7.4 until we state that we've stopped doing so. Stopping because a patch is hard seems a real crappy excuse. For the record, I'd like to see a year's notice. How about Dec. 1, 2010? February is completely not reasonable. Companies need a lot more time to make plans, get approval, test, etc. 2) Relatively few people are using it so perhaps the reason we haven't found any major bugs recently is because nobody's pushing it hard any more. Or maybe it's a relatively stable branch that people are happy with. As far as few people, where do you get that idea, except anecdotally? I can assure I know of a number of companies that are using it (and some using 7.3, but shame on them). These companies do not advertise their usage of Postgres, and their use of the database stays the same so no bugs are revealed, but they are out there. Josh writes: The main reason I'm in favor of this is that we have a lot of users using 7.4 out of inertia, and they need a message that 7.4 is not supported to get them to upgrade. That will get some, but not others. What really makes people upgrade their database is when their database driver stops working against it. :) - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200911031423 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkrwg4cACgkQvJuQZxSWSsipyQCfb3ZMEnscjrQzj02j/6eGFWdj 3csAoIGwgvA5Y/GfBV47FddjvpZfUGEg =RQOY -END PGP SIGNATURE- -- 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] operator exclusion constraints
2009/11/3 Tom Lane t...@sss.pgh.pa.us: Jeff Davis pg...@j-davis.com writes: I'm not excited about using NOT, because I think it has a hint of a double-negative when combined with EXCLUSION. Well, the choice of EXCLUSION isn't set in stone either ... Is this really a generalized uniqueness constraint, extended to support operators other than = ? Perhaps sticking with the word UNIQUE might be more suggestive of this: UNIQUE (room_number WITH = , during WITH ) or: UNIQUE (room_number , during USING ) - Dean -- 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] EOL for 7.4?
Simon Riggs si...@2ndquadrant.com writes: On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote: You're not going to take all those little dribs and drabs of responsibility and transfer them to one person, or even one group of people. With respect to all the people you just mentioned, I don't see any reason why other people could not perform the duties you describe. Of course, it might require a little effort, as we might expect of any handover of responsibility. It's not handover of responsibility that's the issue, it's that dividing up existing responsibility entails more communication and synchronization overhead. If we have a separate set of people back-patching and releasing old branches, then every time we make a bug fix, we have to explain the patch to them; every time we have a release, we have to get their concurrence on release schedule. And we have to track whether patches that should be back-patched have been. The added overhead of all that would easily exceed the time savings of pushing off the responsibility, IMO. (As an example, it's already been determined among core and -packagers that there will be no 8.4.2 during November, because we can't get everyone's time to make a release this month. Putting even more people in the loop does NOT make that better. And they can't be out of the loop --- for instance, if it's a security update, 7.4.x had better come out at the same time as the other branches.) 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] EOL for 7.4?
On Nov 3, 2009, at 10:32 AM, Josh Berkus wrote: So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in favor of doing so in, say, February after an announcement this month +1 And, frankly, I think that we still need a published deprecation policy -- or at least a set of guidelines. That was my point in starting this discussion back in July. 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] EOL for 7.4?
On Tue, Nov 3, 2009 at 7:24 PM, Greg Sabino Mullane g...@turnstep.com wrote: Realistically we're going to EOL it as soon as the first major bug is found that *doesn't* back patch readily. There's relatively low cost to supporting it up until that bug is found, and apparently it hasn't been found it. I hope this is not the case, for sane definitions of readily. We have an implicit promise to support 7.4 until we state that we've stopped doing so. Stopping because a patch is hard seems a real crappy excuse. For the record, I'd like to see a year's notice. How about Dec. 1, 2010? February is completely not reasonable. Companies need a lot more time to make plans, get approval, test, etc. It seems like a fine excuse to me. I certainly don't feel i have any authority to tell Tom or Alvarro what to work on in their spare time. If you feel the urge to do it if Tom thinks it's too much work to be worthwhile then, well, more power to you, thanks. These companies are free to keep using the software with the known problems or pay someone to support it and do the pointless work fixing bugs in five-year-old versions if they want. It looks to me like our support policy and past success at back patching has engendered a false sense of security for users. *All* our support is best-effort and what I described is effectively our policy for all back branches. The only question is which branches, in our best judgement, we think we're likely to run into such a problem. It's not likely for 8.3 currently because we know there aren't very many major changes in 8.4 that fixed potential major design bugs. It's certainly likely for 7.4 at this point and really 8.0 and 8.1 wouldn't surprise me either. That doesn't mean we have to stop back patching to 7.4, 8.0, and 8.1 today. But if we think it's likely we'll run into some major bug which requires a redesign to fix then we should perhaps make some statement to that effect, call these back branches EOL today, and just release back branches on a best effort basis until that occurs. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] DISTINCT ON
Hi all,
It looks like Postgres has a restriction in DISTINCT ON queries where the
DISTINCT ON expressions must match the left side of the ORDER BY list. The
issue is that if a DISTINCT ON ... has multiple instances of a particular
expression, this check doesn't seem to fire correctly.
For example, this query returns an error (but I guess it shouldn't):
SELECT DISTINCT ON ('1'::varchar, '1'::varchar) a FROM (SELECT 1 AS a) AS a
ORDER BY '1'::varchar, '1'::varchar, '2'::varchar;
And this query doesn't return an error (but I guess it should):
SELECT DISTINCT ON ('1'::varchar, '2'::varchar, '1'::varchar) a FROM (SELECT 1
AS a) AS a ORDER BY '1'::varchar, '2'::varchar, '2'::varchar;
Am I misunderstanding something or is there a bug?
Thanks for the help
Emmanuel
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.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] Architecture of walreceiver (Streaming Replication)
Hi, On Tue, Nov 3, 2009 at 3:23 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: wrt. synchronous replication, if someone else has the cycles to look at it, that would be great. I got stuck on the postmaster-process or not question Fujii raised again now, not being able to decide. What is your worry about the postmaster-subprocess walreceiver? One of those is that the startup process would become stuck because of failure of launching of walreceiver, and I have addressed that. http://archives.postgresql.org/pgsql-hackers/2009-09/msg02003.php If you have another worry, I'll address that. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] EOL for 7.4?
Josh Berkus wrote: ...The main reason I'm in favor of this is that we have a lot of users using 7.4 out of inertia, and they need a message that 7.4 is not supported to get them to upgrade. I'm not entirely sure that inertia is the culprit. From what I've seen, since 7.4 is a good, stable release, checking/fixing everything required for an upgrade (casting, time-calculation changes, administrative procedures, perhaps switching from C to UTF8, client-deployment planning and so on) combined with risks of the unknown and 24x7 availability requirements makes the required expenditure a tough sell - especially in a lean and mean economy. I suspect 7.4 will remain in somewhat widespread use for quite some time after EOL. EOL _does_, however, give IT some powerful ammo to use to in persuading management to devote the required resources to an upgrade. Cheers, Steve -- 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] EOL for 7.4?
On Tue, 2009-11-03 at 10:49 -0800, Josh Berkus wrote: Why are we not even willing to ask whether someone is willing? It all seems very strange to me. Mostly because, I think, nobody can picture how this would be structured or where the people would come from. Surely a 7.4 maintainer would do only one platform? Or only source? Can we call 7.4 a maintained version if it's only patched for Debian? Only if you turn off the buildfarm for them. Also, given the other needs we have for technical skills, this would depend on finding people who were good enough to put out stable packages for 7.4, but wasn't interested in contributing to the project in any other way. If these people are available for other tasks, we'd *far* rather have them testing 8.5, reviewing code, updating drivers, writing docs, making tools, etc. These are currently hypothetical problems. Some people may care, if so, they can work out the problems. We might find some people that are willing to take on responsibility and grow into the role. We will probably end up with more new developers, not less. So I don't think that anyone is opposed to your proposal, they just don't (or at least I don't) see a practical way to pursue it. Why not ask for volunteers and let them work it out? Perhaps there are people not willing to receive the kick in the pants you advocate elsewhere. Ask people, let them decide. -- Simon Riggs www.2ndQuadrant.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] operator exclusion constraints
On Tue, Nov 3, 2009 at 5:05 PM, Jeff Davis pg...@j-davis.com wrote: We already have some reasonable agreement around EXCLUSION ... CHECK WITH. We should stick with the current syntax unless there's a good consensus around some other specific proposal. Yeah. I don't like the inflexibility of the current syntax, but that's mostly because I wish the feature itself could be made more general. It would be nice to be able to write constraints of the form: forall vars : expression For example, a uniqueness constraint on a column c is: forall x,y : x.c != y.c And a does-not overlap constraint might look like this: forall x,y : NOT (x.c y.c) Note that an ordinary check constraint is a special case of this where there is only one rowvar and it is implicit. HOWEVER, this is probably a lot more work than what you've already done, and what you've already done is really good, and we shouldn't hesitate to commit on the grounds that it won't cure diabetes and balance the budget. I don't think there is any really beautiful syntax for the feature as it stands, but considering how useful it is I am not inclined to stand on ceremony... ...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] operator exclusion constraints
On Tue, 2009-11-03 at 21:31 +, Dean Rasheed wrote: Is this really a generalized uniqueness constraint, extended to support operators other than = ? That has been discussed in the past: http://archives.postgresql.org/message-id/1253119552.24770.203.ca...@jdavis http://archives.postgresql.org/message-id/1253122946.24770.250.ca...@jdavis However, some constraints allowed by this feature are the *opposite* of unique: consider . Personally, I don't like to use the word UNIQUE to describe a constraint that may reject unique values or permit duplicates. We already have some reasonable agreement around EXCLUSION ... CHECK WITH. We should stick with the current syntax unless there's a good consensus around some other specific proposal. Regards, Jeff Davis -- 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] DISTINCT ON
On Wed, Nov 4, 2009 at 3:17 AM, Emmanuel Cecchet m...@asterdata.com wrote:
For example, this query returns an error (but I guess it shouldn't):
SELECT DISTINCT ON ('1'::varchar, '1'::varchar) a FROM (SELECT 1 AS a) AS a
ORDER BY '1'::varchar, '1'::varchar, '2'::varchar;
This sounds familiar. What version of Postgres are you testing this on?
--
greg
--
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] DISTINCT ON
On Nov 3, 2009, at 10:17 PM, Emmanuel Cecchet m...@asterdata.com
wrote:
Hi all,
It looks like Postgres has a restriction in DISTINCT ON queries
where the DISTINCT ON expressions must match the left side of the
ORDER BY list. The issue is that if a DISTINCT ON ... has multiple
instances of a particular expression, this check doesn't seem to
fire correctly.
For example, this query returns an error (but I guess it shouldn't):
SELECT DISTINCT ON ('1'::varchar, '1'::varchar) a FROM (SELECT 1 AS
a) AS a ORDER BY '1'::varchar, '1'::varchar, '2'::varchar;
And this query doesn't return an error (but I guess it should):
SELECT DISTINCT ON ('1'::varchar, '2'::varchar, '1'::varchar) a FROM
(SELECT 1 AS a) AS a ORDER BY '1'::varchar, '2'::varchar,
'2'::varchar;
Am I misunderstanding something or is there a bug?
I'm guessing this is the result of some subtly flakey equivalence
class handling. On first glance ISTM that discarding duplicates is
legit and therefore both examples ought to work...
...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] EOL for 7.4?
On Tue, 2009-11-03 at 15:01 -0500, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote: You're not going to take all those little dribs and drabs of responsibility and transfer them to one person, or even one group of people. With respect to all the people you just mentioned, I don't see any reason why other people could not perform the duties you describe. Of course, it might require a little effort, as we might expect of any handover of responsibility. It's not handover of responsibility that's the issue, it's that dividing up existing responsibility entails more communication and synchronization overhead. If we have a separate set of people back-patching and releasing old branches, then every time we make a bug fix, we have to explain the patch to them; every time we have a release, we have to get their concurrence on release schedule. And we have to track whether patches that should be back-patched have been. The added overhead of all that would easily exceed the time savings of pushing off the responsibility, IMO. This is essentially the delegation isn't worth it argument. Which doesn't really wash because there clearly is delegation already. There was also a time when those people started and needed to work things out. I'd hold my hand up and say I love to do things myself rather than delegate, but I won't be arguing that makes sense ahead of knowing: if there is a delegatee at all, how they would want to operate, who they are and what they know. (As an example, it's already been determined among core and -packagers that there will be no 8.4.2 during November, because we can't get everyone's time to make a release this month. Putting even more people in the loop does NOT make that better. And they can't be out of the loop --- for instance, if it's a security update, 7.4.x had better come out at the same time as the other branches.) You're also presupposing that we would need to synchronize things in the way you say. It seems strange to be in a position where we either release everything in lock-step, or just jettison it completely. So we can have everything or nothing. All I'm saying is that some people may be willing to live with something rather than nothing. I might be wrong and nobody gives a damn, but as a project I feel we should at least check to see whether people care enough to act. Or maybe do it for the experience. Who knows without asking? -- Simon Riggs www.2ndQuadrant.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] Architecture of walreceiver (Streaming Replication)
On Tue, Nov 3, 2009 at 12:33 AM, Robert Haas robertmh...@gmail.com wrote: On Mon, Nov 2, 2009 at 10:14 AM, Euler Taveira de Oliveira eu...@timbira.com wrote: BTW, are you going to submit another WIP patch for next commitfest? Well, Heikki was going to keep working on this and Hot Standby between CommitFests until it gets committed, but things seem to be stalled at the moment, possibly because Heikki is tied up with internal EnterpriseDB projects. I don't think the hold-up is with Fujii Masao. BTW, my replication patch is on git repository: git://git.postgresql.org/git/users/fujii/postgres.git branch: replication The changes against Heikki's repository (git://git.postgresql.org/git/users/heikki/postgres.git, branch: replication-orig) are: - Prevent pq_wait from being called more than once for the connection which has already turned out to have data ready to be read. Sometimes walsender was calling pq_wait more than once for the connection before actually reading data. This is OK in Linux, the subsequent pq_wait returns immediately. OTOH, in Windows, this makes the subsequent pq_wait get stuck, i.e., the pq_wait doesn't return even if there is data ready to be read in the connection. Which seems to be derived from the half-baked implementation of pgwin32_select. So I changed pq_wait not to call select/poll until data was read from the connection, once it turned out to be available. - Fix the bug that has crossed a logid boundary wrongly. This bug was introduced by sr-paging-rework.patch. http://archives.postgresql.org/pgsql-hackers/2009-10/msg00384.php - Apply the sr_rework_1001.patch. http://archives.postgresql.org/pgsql-hackers/2009-09/msg01996.php Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] DISTINCT ON
Greg Stark gsst...@mit.edu writes:
On Wed, Nov 4, 2009 at 3:17 AM, Emmanuel Cecchet m...@asterdata.com wrote:
SELECT DISTINCT ON ('1'::varchar, '1'::varchar) a FROM (SELECT 1 AS a) AS a
ORDER BY '1'::varchar, '1'::varchar, '2'::varchar;
This sounds familiar. What version of Postgres are you testing this on?
Presumably something before this bug
http://archives.postgresql.org/pgsql-sql/2008-07/msg00123.php
got fixed
http://archives.postgresql.org/pgsql-committers/2008-07/msg00341.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] EOL for 7.4?
Robert Haas wrote: I'm not averse to EOL'ing 7.4, but I don't think it's fair to claim that we already stopped supporting it. Well, that would be overstating my position. We haven't stopped supporting it, but there's less and less stuff that applies that far back. I think it's better to draw a line in the sand and say we're going to stop supporting this release on this date rather than letting it go on and on and then waking up and realizing hmm, nothing ever applies that far back any more, I guess we don't support it. I think you are mis-diagnosing the reason not everything gets backpatched that far. It's not that we can't, it's that we don't always need to. 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] EOL for 7.4?
On Tue, Nov 3, 2009 at 12:13 PM, Simon Riggs si...@2ndquadrant.com wrote: On Tue, 2009-11-03 at 16:37 +, Dave Page wrote: On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote: Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? There are non-trivial amounts of effort required to produce and test packages for each branch we maintain. That affects all of the packagers to varying degrees and should not be overlooked. This presumes a single group of packagers that does all releases. We'd be the only project that does that, AFAICS. Seems strange to limit tasks to just the same few people all the time. We could ask for volunteer maintainers for releases, rather than just say the X people that do all the work no longer wish to do it and so we're not going to let anyone else either. No volunteers, no releases. That is exactly how this current project got started in the first place - picking up the maintenance responsibility on code that the original authors no longer wished to maintain. As in all things, any major changes with respect to packages should be discussed publicly, with notice given of any changes. Anybody that feels it is worth supporting could then come forward to do so. I hope we can avoid a sarcastic over to you then Simon reply. I'm not volunteering for it, but we should give others the opportunity to do so. My belief is there is a substantial user community for 7.4, and for 7.3 also. There is no reason why we should act like a commercial company when we're a volunteer organisation. So suggestion: announce that 7.4 will be EOLd in 6 months unless volunteers come forward to support further releases. At the same time, announce what the EOL plans are for other releases, so people can begin planning upgrades. In most stable production systems the planning cycle can extend to years, rather than weeks or months. But the effort is distributed across multiple people working at different companies. There are many people involved in packaging PostgreSQL and we may not even know who all of them are, though we probably do know the major ones. Plus Peter updates translations, Marc stamps releases, Tom and others backpatch bug fixes, etc. You're not going to take all those little dribs and drabs of responsibility and transfer them to one person, or even one group of people. We certainly don't have to EOL 7.4. But neither can we maintain an infinite collection of back-branches forever. So we just need to decide whether it's time. If so, we pick a date and announce it. If not, we go on as we are and come back around to this topic in another six months. Personally, I think it would be reasonably to make the announcement that 7.4 will be EOL when 8.5 is released, but YMMV, BANI. ...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] A small bug in gram.y
Tom Lane t...@sss.pgh.pa.us wrote: select nosuchfunction(1,2,3,avalidfunction(4)); ^ select nosuchfunction(1,2,3,avalidfunction(4)); ^ Which of these is less likely to be misread about which function is being complained of? Actually, I much prefer what PostgreSQL does. :-) ERROR: function nosuchfunction(integer, integer, integer, integer) does not exist LINE 1: select nosuchfunction(1,2,3,avalidfunction(4)); ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. But, anyway, point taken. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Is it an expected behavior?
postgres=# CREATE TABLE t1 (a int, b int);
CREATE TABLE
postgres=# CREATE TABLE t2 (b int, c int);
CREATE TABLE
postgres=# CREATE TABLE t3 (d int) inherits (t1, t2);
NOTICE: merging multiple inherited definitions of column b
CREATE TABLE
The t3.d is inherited from t1 and t2. Its attinhcount is 2.
postgres=# ALTER TABLE t1 RENAME b TO x;
ALTER TABLE
It alters name of the column 'b' in the t1 and its child tables ('t3').
postgres=# SELECT * FROM t1;
a | x
---+---
(0 rows)
postgres=# SELECT * FROM t2;
ERROR: could not find inherited attribute b of relation t3
Because t3.b is also inherited from the t2, but ALTER TABLE does not
care about multiple inherited columns well.
I think we should not allow to rename a column with attinhcount 1.
Any comments?
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
