Re: [HACKERS] git: uh-oh
Max Bowsher wrote: On 20/08/10 19:07, Magnus Hagander wrote: On Fri, Aug 20, 2010 at 19:56, Max Bowsher m...@f2s.com wrote: On 20/08/10 18:43, Magnus Hagander wrote: On Fri, Aug 20, 2010 at 19:41, Max Bowsher m...@f2s.com wrote: On 20/08/10 18:30, Magnus Hagander wrote: On Fri, Aug 20, 2010 at 19:28, Tom Lane t...@sss.pgh.pa.us wrote: Max Bowsher m...@f2s.com writes: The history that cvs2svn is aiming to represent here is this: 1) At the time of creation of the REL8_4_STABLE branch, plperl_opmask.pl did *not* exist. 2) Later, it was added to trunk. 3) Then, someone retroactively added the branch tag to the file, marking it as included in the REL8_4_STABLE branch. [This corresponds to the git changeset that Robert is questioning] Uh, no. We have never retroactively added anything to any branch. I don't know enough about the innards of CVS to know what its internal representation of this sort of thing is, but all that actually happened here was a cvs add and a cvs commit in REL8_4_STABLE long after the branch occurred. We would like the git history to look like that too. Yeah. In fact, is the only thing that's wrong here the commit message? Because it's probably trivial to just patch that away.. Hmm, but i guess we'd like to hav ethe actual commit message and not just another fixed one.. There is no actual commit message - the entire changeset is synthesized by cvs2git to represent the addition of a branch tag to the file - i.e. the logical equivalent of a cvs tag -b, which has no commit message. There is a commit message on the trunk when the file was added there. Is there any chance of being able to lift that message off trunk and just copy it into the branch, instead of saying this is a cherry-pick of this commit over here? It wouldn't be accurate to do so, because the synthetic commit is not copying the entire change, only registering the addition of (in this case) one file which happens to be part of the changeset. Please note that there is a changeset on the branch immediately following the synthetic one under discussion which contains the 'real' commit message used when committing to the branch. Hmm. Good point. I wonder if we should try to locate these places and fix them with git filter-branch or rebase -i after the fact, with history rewriting. There seem to be 57 of them. It sounds cumbersome. Michael Haggerty might be better placed than me to assess whether eliding them within cvs2git is practically achievable. I think this would be nontrivial. It is (relatively) easy to tweak a file's history during FilterSymbolsPass, which is the last time during the conversion when the file's whole history is in memory at once. But you don't want to omit all connections between file-on-branch and parent branch; you only want to omit the information if the branching of the particular file cannot be included with the first commit that creates the branch. Unfortunately, determination of commits requires *global* information and is done *after* FilterSymbolsPass. The elision of the file branching event could conceivably be done at the point when it would otherwise be output to the dumpfile, but its elision would affect how the first change to the file on the branch had to be treated, so information would have to be kept around. Moreover, this is a pretty specialized request that would be useless to people who are not so disciplined about their repository as you seem to be. It seems like you already have a way to find these events in the git repository after conversion, so I think it would be more practical to use git-filter-branch to remove the unwanted commits *after* the conversion. Michael -- 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] Version Numbering
The current system give people the completely false impression that 7.0 and 7.4 are somehow similar. On what planet? on every single planet of the universe, except the one called postgrearth, whose inhabitants breathe sql and eat messages from postgresql mailing lists... :-) most people I know, think 8.1 is just 8.0 with some fixes... regards, /sak -- 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] Version Numbering
On 08/20/2010 09:04 PM, David E. Wheeler wrote: On Aug 20, 2010, at 12:02 PM, Greg Stark wrote: Again, it means the format would be consistent. Always three integers. Nice thing about Semantic Versions is that if you append any ASCII string to the third integer, it automatically means less than that integer. So I count three integers in both 9.0rc1 and 9.0beta4 No, I mean 9.0.0beta4. If we were to adopt the Semantic Versioning spec, one would *always* use X.Y.Z, with optional ASCII characters appended to Z to add meaning (including less than unadorned Z). hmm FWIW I would interpret something like 9.0.1B4 as the forth beta release for the first point release of the major release 9.0 bis seems stupid and is not anything we have done before. You could argue that 9.0.0B4 is the foourth beta for the first production release of 9.0 but I find the current naming much more reasonable... 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] Vaccum and analyze counters in pgstat
On Fri, Aug 20, 2010 at 15:49, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: Attached is a patch that adds columns to pg_stat_*_tables for number of [auto]vacuum and [auto]analyze runs on a table, completing the current one that just had the last time these ran. It's particularly useful to see how much autovac is doing on the tables, but I included the counts of regular vacuum and analyze as well for completeness. Comments? Looks reasonably sane in a quick read-through. Applied with suggested documentation changes. -- 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] Version Numbering
On Aug 21, 2010, at 1:45 AM, Stefan Kaltenbrunner wrote: hmm FWIW I would interpret something like 9.0.1B4 as the forth beta release for the first point release of the major release 9.0 bis seems stupid and is not anything we have done before. It does't make sense for PostgreSQL, no. You could argue that 9.0.0B4 is the foourth beta for the first production release of 9.0 but I find the current naming much more reasonable... Yeah, it's just semantics, really. 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] security hook on authorization
On Aug 20, 2010, at 8:27 PM, KaiGai Kohei kai...@kaigai.gr.jp wrote: (2010/08/20 23:34), Robert Haas wrote: 2010/8/19 KaiGai Koheikai...@ak.jp.nec.com: I think our standard criteria for the inclusion of hooks is that you must demonstrate that the hook can be used to do something interesting that couldn't be done without the hook. So far I'm unconvinced. We cannot handle an error of labeled networking (getpeercon(3)), if we don't have any hook during client authorization stage. If and when a connection came from a host but we don't accept the delivered security label, or labeled networking is misconfigured, getpeercon(3) returns NULL. In this case, server cannot identify what label should be applied on the client, then, we should disconnect this connection due to the error on database login, not any access control decision. In similar case, psm_selinux.so disconnect the connection when it cannot identify what security label shall be assigned on the session, due to some reasons such as misconfigurations. Without any hooks at authorization stage (but it might be different place from this patch, of course), we need to delay the error handling by the time when SE-PostgreSQL module is invoked at first. But it is already connection established and user sends a query. It seems to me quite strange behavior. You mentioned that before. I'm not totally sure I buy it, and I think there are other applications that might benefit from a hook in this area. We need to think about trying to do this in a way that is as general as possible. So I'd like to see some analysis of other possible applications. ...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] Version Numbering
On Sat, Aug 21, 2010 at 4:29 AM, Sergio A. Kessler sergiokess...@gmail.com wrote: on every single planet of the universe, except the one called postgrearth, whose inhabitants breathe sql and eat messages from postgresql mailing lists... :-) most people I know, think 8.1 is just 8.0 with some fixes... Really? is Linux 2.6 just 2.5 with some fixes? Glibc 2.Was Windows 3.5 just 3.4 with some fixes? Gnome 2.28 just 2.27 with some fixes? In fact perusing dpkg -l output the *only* software package I find that bumps the major version every single release is Emacs. It stands out as an outlier as soon as you say version 23 -- and that was despite a hiatus when version 18.59 was the newest release for years. Here is the Gnome project's description of what's new in 2.28 (over 2.26, the previous public release): The GNOME Project's focus on users and usability continues in GNOME 2.28 with its hundreds of bug fixes and user-requested improvements. The sheer number of enhancements makes it impossible to list every change and improvement made, but these notes aim to highlight some of the more exciting, user-oriented features in this release. -- 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] Version Numbering
On Sat, 2010-08-21 at 17:00 +0100, Greg Stark wrote: On Sat, Aug 21, 2010 at 4:29 AM, Sergio A. Kessler sergiokess...@gmail.com wrote: on every single planet of the universe, except the one called postgrearth, whose inhabitants breathe sql and eat messages from postgresql mailing lists... :-) most people I know, think 8.1 is just 8.0 with some fixes... Really? is Linux 2.6 just 2.5 with some fixes? Glibc 2.Was Windows 3.5 just 3.4 with some fixes? Gnome 2.28 just 2.27 with some fixes? Thank you for this. It validates something that has been nagging me. Do you really think the majority of users even know what kernel they are running? They don't. They know they are running Ubuntu or Fedora. They probably know the version but they have no idea what version of the kernel that is being run. PostgreSQL is a user space project. Yes we have a solid core of -hackers but our wider use is a place where hackers don't exist. User space developers do. I.e; PHP people. Reminder, there was no Windows 3.4 or Windows 3.5. Yes it does matter. There was: 3.1x 3.11 for Workgroups Windows NT 3.1 Windows NT 3.5 Windows NT 4.0 (I am ignoring ME) Windows XP There was *NEVER* a Windows NT 4.0.x, there was Windows NT 4.0 SP2. The semantics are important. People mock Microsoft but except for some notable blunders (Windows ME, splurt) they are very, very good at getting mind share. Here is the Gnome project's description of what's new in 2.28 (over 2.26, the previous public release): Gnome is a bad example. People barely know if at all they are running Gnome. They are running Ubuntu. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- 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] [BUGS] COPY FROM/TO losing a single byte of a multibyte UTF-8 sequence
Steven Schlansker ste...@trumpet.io writes: Anyway, it looks like this is actually a BSD bug which got copy + pasted into Apple's Darwin source - http://lists.freebsd.org/pipermail/freebsd-i18n/2007-September/000157.html I've applied a patch for this to HEAD 9.0: http://archives.postgresql.org/pgsql-committers/2010-08/msg00273.php I'm reluctant to back-patch it into already-released branches, though. Given the lack of prior reports, the odds of breaking something for somebody in a minor release seem to outweigh the odds of doing good. But you could easily drop it into a local copy of 8.4 if you wish. 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] Version Numbering
Joshua D. Drake j...@commandprompt.com writes: PostgreSQL is a user space project. Yes we have a solid core of -hackers but our wider use is a place where hackers don't exist. User space developers do. I.e; PHP people. This is utter nonsense. We're a database, not a desktop. People who even know what a database is, let alone program one, are sufficiently geeky to be aware of the usual conventions for software version numbering. Or at least to RTFM if they don't. 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] Version Numbering
On Sat, Aug 21, 2010 at 5:51 PM, Joshua D. Drake j...@commandprompt.com wrote: There was *NEVER* a Windows NT 4.0.x, there was Windows NT 4.0 SP2. I'm not sure what you're point is here. There was a NT 4.0 followed by SP1 through SP6. followed by NT 5.0, 5.1, 5.2, 6.0, 6.1, and 7.0. They also had brand names 2000, XP, 2003, Vista, 7, etc -- is this model less confusing? The whole point here is that there is a pretty broad consensus across software projects that the first digit is for major releases that change the whole product character -- Linux 2.0, Samba 3.x, Libc 6, Even Windows 4 and Oracle 8. The second is for releases that add features, and the third digit is for minor releases. Our release numbering scheme is the same used by the vast majority of software packages. There are marketing pressures that cause version number inflation like Oracle 9i, 10g, 11g where regular releases are branded as huge improvements to warrant spending extra money on them. Sometimes the reverse happens and companies release regular releases and want to avoid bumping the number from a popular version. Things like Win 98 SP2 or Oracle 8i. But those are marketing pressures that large companies feel to deceive their users into misunderstanding what they're being sold. Open source projects have generally not felt pressures like that and have been able to just use regular version numbering schemes that users understand. Now we're getting the blowback from users confused by these marketing schemes who no longer understand how normal version number schemes work. There's no evidence that adopting marketing driven version numbering will confuse these people any less -- they're probably perpetually confused about software release engineerng -- and there's every reason to think that it would confuse the 99% of our users who are perfectly accustomed to software version numbering schemes much more to use an unusual scheme used only by a handful of other projects and (inconsistently) by big marketing departments. -- 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] Version Numbering
On Sat, 2010-08-21 at 13:12 -0400, Tom Lane wrote: Joshua D. Drake j...@commandprompt.com writes: PostgreSQL is a user space project. Yes we have a solid core of -hackers but our wider use is a place where hackers don't exist. User space developers do. I.e; PHP people. This is utter nonsense. We're a database, not a desktop. No. Yes. Obviously. I was not comparing us to a desktop. I was stating that the people we are trying to reach are user space developers, like PHP people. People who even know what a database is, let alone program one, are sufficiently geeky to be aware of the usual conventions for software version numbering. Can and will are different things. Every barrier that we can lower without sacrificing the quality of our software, is a barrier that should be lowered. Period. If modifying the version numbering scheme helps even an ants inch, we should do it. Or at least to RTFM if they don't. If this were true, this thread wouldn't be as long as it is, nor would our mailing lists be anywhere near as busy as they are. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- 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] Version Numbering
On Sat, Aug 21, 2010 at 03:34:35AM -, Greg Sabino Mullane wrote: It's possible that we're arguing for the sake of arguing No it's not! ;) Yes it is! ;) It's nice to be able to keep track of the major version number without running out of fingers (at least for a few more years) and it's nice to be able to bump the major version number when we do something to totally destabilize the tree^W^W^W^W^Wreally cool. Or at least, I think it's nice. Again, YMMV, IMHO, etc. If the Windows port was the primary justification for the 8.0 designation, and HS/SR are the justification for the 9.0 designation, what will 10.0 be? Therein lies the problem: our decision to do a major bump is inconsistent at best, and wildy confusing at worst. Does a new feature really constitute a major bump? Perhaps so, as with 9.0 SR/HS, but in that case there have been other times we should have bumped the major for some new feature and did not. What about major internal changes and libpq version bumps? You might think those would always be a major change, but they are not. We went from 7.2 to 7.3 without considering how major it is (hello, schemas!). What about end-user compatiblity? I sometimes suspect few hackers on this list realize how completely disruptive, annoying, and painful the removal of implicit casts was in 8.3. That would have been a major bump in my book at least. I think in the future we should consider lowering the bar for a major release, as it's better to err on that side. Disruptive to developers is one sufficient criterion. Another is does some big thing simply that would have been hard or impossible before. Previous things like dblink, schemas and CTEs, and upcoming things like synchronous replication, SQL/MED, parallel query, and (of course ;) writeable CTEs, would qualify under that second. Open for discussion would be features like Can spit out, on demand, any subset of the dependency graph for an object. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] Version Numbering
On Sat, Aug 21, 2010 at 5:51 PM, Joshua D. Drake j...@commandprompt.com wrote: PostgreSQL is a user space project. Yes we have a solid core of -hackers but our wider use is a place where hackers don't exist. User space developers do. I.e; PHP people. Uhm http://en.wikipedia.org/wiki/PHP#Release_history The current release of PHP is 5.3.3 -- ie, the third patch release of the third regular release of PHP5 -- the fifth major rewrite of the engine and language. They use exactly the same model we use and virtually every other software package every uses unti the marketing department gets ahold of it and confuses things. -- 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] Version Numbering
On Sat, Aug 21, 2010 at 6:24 PM, Greg Stark gsst...@mit.edu wrote: I'm not sure what you're point is here. Argh! This thread is almost enough to make me believe in adding recalls to smtp. I can't even blame this one on my flaky keyboard this time. -- 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] Version Numbering
On Sat, 2010-08-21 at 18:24 +0100, Greg Stark wrote: On Sat, Aug 21, 2010 at 5:51 PM, Joshua D. Drake j...@commandprompt.com wrote: There was *NEVER* a Windows NT 4.0.x, there was Windows NT 4.0 SP2. I'm not sure what you're point is here. There was a NT 4.0 followed by SP1 through SP6. followed by NT 5.0, 5.1, 5.2, 6.0, 6.1, and 7.0. They also had brand names 2000, XP, 2003, Vista, 7, etc -- is this model less confusing? Yeah sorry. I kind of went down a path without completing the thought process. There was no NT 5.0, 5.1 etc... There may have been an internal name, an engineers name, or heck possibly even if you did help about it would mention 5.0 (I don't actually know). However, the users never new them as those. Period. Which is what I am getting at. Our new and less technical users are confused about whether 8.1 and 8.2 are 8.0 SP1 and 8.0 SP2. Which they clearly aren't. The whole point here is that there is a pretty broad consensus across software projects that the first digit is for major releases that change the whole product character -- Linux 2.0, Samba 3.x, Libc 6, All three of those are irrelevant to this conversation. Users don't run Linux 2.0. They run Ubuntu, Fedora or SUSE. I can easily on a weekly basis run into a customer, or external community user that says, I am running PostgreSQL 8. They will actually be running, 8.0, 8.1, 8.2, 8.3 or 8.4. Yes, a good number of more technical, or those who have been in the community longer have figured it out Let's make this simple: Q. Do we have a problem? A. Some of our contributors, even some very experienced contributors feel we do. Q. What is the problem we are trying to solve? A. That users, especially those that are less technical are confused by our versioning system. Q. How do we solve that problem? A. ... Q. Does the presented solution create a new problem that must be solved? A. ... It would be great everyone would stop arguing semantics (myself included) and just attempt to solve the problem. Education isn't going to cut it, we have been educating for almost 15 years. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- 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] Version Numbering
On Sat, 2010-08-21 at 18:35 +0100, Greg Stark wrote: On Sat, Aug 21, 2010 at 6:24 PM, Greg Stark gsst...@mit.edu wrote: I'm not sure what you're point is here. Argh! This thread is almost enough to make me believe in adding recalls to smtp. I can't even blame this one on my flaky keyboard this time. Hahahahaha. Yeah I think we are spinning at this point. I posted a simple, problem we are trying to solve email. If we can do that, great. If not we are just wasting bandwidth. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- 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] Version Numbering
On Sat, Aug 21, 2010 at 6:37 PM, Joshua D. Drake j...@commandprompt.com wrote: Q. Do we have a problem? A. Some of our contributors, even some very experienced contributors feel we do. Q. What is the problem we are trying to solve? A. That users, especially those that are less technical are confused by our versioning system. Q. How do we solve that problem? A. ... Sorry, but this is all a logical fallacy. There will always be a percentage of people who are confused. The question is which scheme results in the least confusion and communicates the most information. Following industry standard practice is the best way to minimize that confusion. If we adopt a different scheme then it might be clearer to beginners but be confusing and unhelpful to everyone else. It'll look like we're doing a major rewrite every year and there's no way to tell which releases are major changes and which are just annual releases. Frankly I think we've been bumping version numbers too often. It's a consequence of the insane pace of development we've had. Adding PITR in 8.0 was a pretty major step and hot standby in 9.0 will be big too. But we should be limiting the first digit for Perl 6 scale changes, not just features that are really really cool. -- 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] Replacing the pg_get_expr security hack with a datatype solution
We agreed that we ought to do $SUBJECT in 9.1. Right offhand the outlines of a cleaner solution look pretty obvious: * Create a datatype with the same internal representation as TEXT; make its input and recv routines throw errors, while the output routines just reuse textout/textsend. * Provide an implicit cast to (but not from) text, so that we don't break any queries doing textual functions on these columns. * Change all system catalog columns holding expression trees to be declared as this type. * Modify the at-risk functions to take inputs of this type instead of text. The only thing that seems like it might need discussion is the name to give the datatype. My first instinct was pg_expr or pg_expression, but there are some cases where this doesn't exactly fit. In particular, pg_rewrite.ev_action contains a whole Query, in fact a list of them. We could go with something like pg_parse_tree, perhaps. Or maybe that's overthinking it. Note that this approach will prevent even superusers from injecting manually-created values into these columns and functions. I don't see a problem with that, and note that if a superuser really wants to do it, he can create a cast that will let him. I can't remember ever having needed to do such a thing myself, so I think the debugging use-case for it is nonexistent. Comments, suggestions? 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] Replacing the pg_get_expr security hack with a datatype solution
On 21 August 2010 20:30, Tom Lane t...@sss.pgh.pa.us wrote: * Change all system catalog columns holding expression trees to be declared as this type. *snip* We could go with something like pg_parse_tree, perhaps. Or maybe that's overthinking it. How about pg_expr_tree? -- Thom Brown Registered Linux user: #516935 -- 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] Version Numbering
Or at least to RTFM if they don't. If this were true, this thread wouldn't be as long as it is, nor would our mailing lists be anywhere near as busy as they are. This thread is as long as it is principally because people generally bikeshed about things that are easy to understand, and are fun to have an opinion about. Frankly I think we've been bumping version numbers too often. It's a consequence of the insane pace of development we've had. Adding PITR in 8.0 was a pretty major step and hot standby in 9.0 will be big too. But we should be limiting the first digit for Perl 6 scale changes, not just features that are really really cool. While I generally agree with your views about versioning conventions, if we did that, we'd probably never bump the major version number. As far as I'm aware, Postgres has never had such radical changes in a single release, that broke compatibility to such an extent. Also, while we aren't subject to the same commercial pressures as the proprietary vendors, I don't think that we can afford to not have our versioning conventions informed by marketing concerns to any extent. We changed 8.5 to 9.0 explicitly because doing so was good marketing, and also because of HS/SR (plus we wanted to hint at the fact that 9.0 might not be the most stable release we've had), and I'm inclined to agree with that. -- Regards, Peter Geoghegan -- 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] Replacing the pg_get_expr security hack with a datatype solution
On Aug 21, 2010, at 3:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: We agreed that we ought to do $SUBJECT in 9.1. One argument against this is that it might cause the current fix to get less testing. ...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] Replacing the pg_get_expr security hack with a datatype solution
Robert Haas robertmh...@gmail.com writes: On Aug 21, 2010, at 3:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: We agreed that we ought to do $SUBJECT in 9.1. One argument against this is that it might cause the current fix to get less testing. Less testing than what? 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] Replacing the pg_get_expr security hack with a datatype solution
On Aug 21, 2010, at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Aug 21, 2010, at 3:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: We agreed that we ought to do $SUBJECT in 9.1. One argument against this is that it might cause the current fix to get less testing. Less testing than what? Is this a smart remark? Less testing than it otherwise would, obviously. ...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] Version Numbering
I don´t have any problem with PostgreSQL version numbering, to the contrary. The only thing I didn´t like was Postgres95, but I didn´t use Pg then. But since then it´s _consistent_ and I really appreciate that. I could live with, say, version 9.12.0 in a dozend years. I accept the alpha, beta or RC extensions. I don´t like the M$ way: Why is WinWord 2 followed by WinWord 7? Why sometimes a number, then a name like Win98 followed by ME. Marketing? What´s the next idea of their marketing departmenr? May be Windows Baobao because the chinese market is really important? I don´t want to compare me or my users with yours. Most of my users know exactly one thing about the data base: When it´s NOT working. That´s all they care for. Working, not numbering. My users are all small and mid size enterprises, with less than 150 employees. They are just users and hire me as generalist, as developer, administrator, DBA, hot line and the one to cope with their inability to RTFM in one person. Usually they are satisfied PostgreSQL users without knowing what it is or what it does. It´s just - sorry for that - somewhere in the background. Like my MTA, which is ehem... duh, have to look for. Wolfgang
[HACKERS] small makeVar refactoring
While hacking around, I noticed that a lot of makeVar() calls could be
refactored into some convenience functions, to save some redundancy and
so that the unusual call patterns stand out better. Useful?
Index: src/backend/commands/tablecmds.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/tablecmds.c,v
retrieving revision 1.341
diff -u -3 -p -r1.341 tablecmds.c
--- src/backend/commands/tablecmds.c 18 Aug 2010 18:35:19 - 1.341
+++ src/backend/commands/tablecmds.c 21 Aug 2010 21:09:30 -
@@ -6077,9 +6077,7 @@ ATPrepAlterColumnType(List **wqueue,
}
else
{
- transform = (Node *) makeVar(1, attnum,
- attTup-atttypid, attTup-atttypmod,
- 0);
+ transform = (Node *) makeVarFromAttribute(1, attnum, attTup);
}
transform = coerce_to_target_type(pstate,
Index: src/backend/nodes/makefuncs.c
===
RCS file: /cvsroot/pgsql/src/backend/nodes/makefuncs.c,v
retrieving revision 1.66
diff -u -3 -p -r1.66 makefuncs.c
--- src/backend/nodes/makefuncs.c 2 Jan 2010 16:57:46 - 1.66
+++ src/backend/nodes/makefuncs.c 21 Aug 2010 21:09:30 -
@@ -17,6 +17,7 @@
#include catalog/pg_type.h
#include nodes/makefuncs.h
+#include nodes/nodeFuncs.h
#include utils/lsyscache.h
@@ -91,6 +92,39 @@ makeVar(Index varno,
}
/*
+ * makeVarFromTargetEntry -
+ * convenience function to create a same-level Var node from a
+ * TargetEntry
+ */
+Var *
+makeVarFromTargetEntry(Index varno,
+ TargetEntry *tle)
+{
+ return makeVar(varno,
+ tle-resno,
+ exprType((Node *) tle-expr),
+ exprTypmod((Node *) tle-expr),
+ 0);
+}
+
+/*
+ * makeVarFromAttribute -
+ * convenience function to create a same-level Var node from a
+ * pg_attribute tuple structure
+ */
+Var *
+makeVarFromAttribute(Index varno,
+ AttrNumber varattno,
+ Form_pg_attribute att)
+{
+ return makeVar(varno,
+ varattno,
+ att-atttypid,
+ att-atttypmod,
+ 0);
+}
+
+/*
* makeTargetEntry -
* creates a TargetEntry node
*/
Index: src/backend/optimizer/path/pathkeys.c
===
RCS file: /cvsroot/pgsql/src/backend/optimizer/path/pathkeys.c,v
retrieving revision 1.101
diff -u -3 -p -r1.101 pathkeys.c
--- src/backend/optimizer/path/pathkeys.c 26 Feb 2010 02:00:45 - 1.101
+++ src/backend/optimizer/path/pathkeys.c 21 Aug 2010 21:09:30 -
@@ -629,12 +629,7 @@ convert_subquery_pathkeys(PlannerInfo *r
Assert(list_length(sub_eclass-ec_members) == 1);
sub_member = (EquivalenceMember *) linitial(sub_eclass-ec_members);
-outer_expr = (Expr *)
- makeVar(rel-relid,
- tle-resno,
- exprType((Node *) tle-expr),
- exprTypmod((Node *) tle-expr),
- 0);
+outer_expr = (Expr *) makeVarFromTargetEntry(rel-relid, tle);
/*
* Note: it might look funny to be setting sortref = 0 for a
@@ -712,12 +707,7 @@ convert_subquery_pathkeys(PlannerInfo *r
if (equal(tle-expr, sub_expr))
{
/* Exact match */
- outer_expr = (Expr *)
- makeVar(rel-relid,
- tle-resno,
- exprType((Node *) tle-expr),
- exprTypmod((Node *) tle-expr),
- 0);
+ outer_expr = (Expr *) makeVarFromTargetEntry(rel-relid, tle);
}
else
{
@@ -730,12 +720,7 @@ convert_subquery_pathkeys(PlannerInfo *r
if (equal(tle_stripped, sub_stripped))
{
/* Match after discarding RelabelType */
- outer_expr = (Expr *)
-makeVar(rel-relid,
- tle-resno,
- exprType((Node *) tle-expr),
- exprTypmod((Node *) tle-expr),
- 0);
+ outer_expr = (Expr *) makeVarFromTargetEntry(rel-relid, tle);
if (exprType((Node *) outer_expr) !=
exprType((Node *) sub_expr))
outer_expr = (Expr *)
Index: src/backend/optimizer/plan/setrefs.c
===
RCS file: /cvsroot/pgsql/src/backend/optimizer/plan/setrefs.c,v
retrieving revision 1.161
diff -u -3 -p -r1.161 setrefs.c
--- src/backend/optimizer/plan/setrefs.c 12 Jul 2010 17:01:06 - 1.161
+++ src/backend/optimizer/plan/setrefs.c 21 Aug 2010 21:09:30 -
@@ -1283,11 +1283,7 @@ search_indexed_tlist_for_non_var(Node *n
/* Found a matching subplan output expression */
Var *newvar;
- newvar = makeVar(newvarno,
- tle-resno,
- exprType((Node *) tle-expr),
- exprTypmod((Node *) tle-expr),
- 0);
+ newvar = makeVarFromTargetEntry(newvarno, tle);
newvar-varnoold = 0; /* wasn't ever a plain Var */
newvar-varoattno = 0;
return newvar;
@@ -1325,11 +1321,7 @@ search_indexed_tlist_for_sortgroupref(No
/* Found a matching subplan output expression */
Var *newvar;
- newvar = makeVar(newvarno,
- tle-resno,
- exprType((Node *) tle-expr),
- exprTypmod((Node *) tle-expr),
-
Re: [HACKERS] small makeVar refactoring
Peter Eisentraut pete...@gmx.net writes: While hacking around, I noticed that a lot of makeVar() calls could be refactored into some convenience functions, to save some redundancy and so that the unusual call patterns stand out better. Useful? I'm not real thrilled with importing catalog/pg_attribute.h into makefuncs.h; that seems like a lot of namespace pollution for not much return. So -1 to makeVarFromAttribute. The other is okay although I'm not convinced it's useful enough to bother with. 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] pg_archivecleanup debug message consistency
pg_archivecleanup -d (=verbose/DEBUG mode) mainly emits 2 types of messages:
pg_archivecleanup: keep WAL file 00010002 and later
and:
pg_archivecleanup: removing file
/var/data2/pg_stuff/dump/hotprime/replication_archive/0001001B
I found it a bit annoying to not see the full path in the 'keep WAL
file'-message (esp. when it is
repeated many screenfulls).
If only for consistency, this patch adds the path info to that message.
Erik Rijkers--- contrib/pg_archivecleanup/pg_archivecleanup.c.orig 2010-08-22 00:05:06.0 +0200
+++ contrib/pg_archivecleanup/pg_archivecleanup.c 2010-08-21 23:56:47.0 +0200
@@ -308,8 +308,15 @@
SetWALFileNameForCleanup();
if (debug)
+ {
+#ifdef WIN32
+snprintf(WALFilePath, MAXPGPATH, %s\\%s, archiveLocation, exclusiveCleanupFileName);
+#else
+snprintf(WALFilePath, MAXPGPATH, %s/%s, archiveLocation, exclusiveCleanupFileName);
+#endif
fprintf(stderr, %s: keep WAL file \%s\ and later\n,
-progname, exclusiveCleanupFileName);
+progname, WALFilePath);
+ }
/*
* Remove WAL files older than cut-off
--
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] Return of the Solaris vacuum polling problem -- anyone remember this?
Josh Berkus wrote: On further reflection, though: since we put in the BufferAccessStrategy code, which was in 8.3, the background writer isn't *supposed* to be very much involved in writing pages that are dirtied by VACUUM. VACUUM runs in a small ring of buffers and is supposed to have to clean its own dirt most of the time. So it's wrong to blame this on the bgwriter not holding up its end. Rather, what you need to be thinking about is how come vacuum seems to be making lots of pages dirty on only one of these machines. This is an anti-wraparound vacuum, so it could have something to do with the hint bits. Maybe it's setting the freeze bit on every page, and writing them one page at a time? Still don't understand the call to pollsys, even so, though. We often mention that we do vacuum freeze for anti-wraparound vacuum, but not for pg_clog file removal, which is the primary trigger for autovacuum vacuum freezing. I have added the attached documentation patch for autovacuum_freeze_max_age; back-patched to 9.0. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + Index: doc/src/sgml/config.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.304 diff -c -c -r1.304 config.sgml *** doc/src/sgml/config.sgml 17 Aug 2010 04:37:20 - 1.304 --- doc/src/sgml/config.sgml 22 Aug 2010 02:30:39 - *** *** 4150,4156 para Specifies the maximum age (in transactions) that a table's structnamepg_class/.structfieldrelfrozenxid/ field can ! attain before a commandVACUUM/ operation is forced to prevent transaction ID wraparound within the table. Note that the system will launch autovacuum processes to prevent wraparound even when autovacuum is otherwise disabled. --- 4150,4157 para Specifies the maximum age (in transactions) that a table's structnamepg_class/.structfieldrelfrozenxid/ field can ! attain before a commandVACUUM/ operation is forced to allow removal ! of old files from the filenamepg_clog/ subdirectory and prevent transaction ID wraparound within the table. Note that the system will launch autovacuum processes to prevent wraparound even when autovacuum is otherwise disabled. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
