[DOCS] Doc bug (?) in rules vs triggers
Chapter 13 of the documentation on Rules versus Triggers says in part "On the other hand a trigger that is fired on INSERT on a view can do the same as a rule, put the data somewhere else and suppress the insert in the view." However, it does not appear to be possible to set a trigger on a view, so this means something else. (I'd like to set a trigger on a view, because the replacement INSERT I wish to make is easier to write in PLPGSQL than plain SQL.) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] [PERFORM] PostgreSQL vs. MySQL
On Sat, Aug 16, 2003 at 08:36:57PM -0400, Bruce Momjian wrote: > > Do we need to add a mention of the need for tuning to the install docs? Wouldn't be a bad idea, as far as I'm concerned. A -- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Can't find thread on Linux memory overcommit
I replied to Josh thus: --- You need to be careful using Alan's patch. The reason RH stopped using this part of it in their errata kernels is that it had conflicts with other stuff, specifically the rmap stuff (he told me that himself in email). I am very wary of advising people to use what is essentially an experimental patch in a production system. This should be a last resort - a better solution is to have better control over what is running on your db server, so you can ensure it never gets into an OOM situation. For mission critical apps I would advise running the postmaster on a dedicated machine, with no X or other nasty stuff running. - I do have a doc patch ready (with one sensible addition suggested by Jon Jensen). andrew Josh Berkus wrote: Andrew, I see btw that no change has been made to the docs. That's bad IMNSHO. The situation with RH is unchanged with today's kernel errata patch, too. I propose to submit a doc patch with the following wording, unless someone objects or improves it: First, off, I'm crossing this to PGSQL-DOCS, which is the correct list for doc patches. Second, don't you think we should have some mention of the Alan Cox patch? Otherwise, I think your doc patch is good and needed before we go final. When we settle the second question, I'll submit a diff for you. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [DOCS] [HACKERS] 7.5 release notes
Bruce Momjian said: > I have completed the 7.5 release notes. You can view them in HTML on > the developer web page. I have marked a few items with question marks > that need to be addressed. I am looking for improvements, even minor > ones. Either send in a patch or committers can modify the file > directly. > I presume we can also just make some comments ;-) this item: Add new GUC parameter to report useful information at the start of each log line should probably read "Add new GUC parameter log_line_prefix ." I think this item belongs to me, or me and Tom: Replace the virtual_host and tcpip_socket parameters with a unified listen_addresses parameter. Conversely, Tom deserves joint billing for dollar quoting, as most of what I did was based on his work. David Fetter should be mentioned under the dollar quoting and plperl items, as he did documentation for both. Tom's implementation of a new flex-based lexer for psql is a significant source code change which should be mentioned. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] PL/Perl list value return causes segfault
David Fetter wrote: *** 716,724 ! In the current implementation, if you are fetching or returning ! very large data sets, you should be aware that these will all go ! into memory. --- 766,776 ! If you are fetching or returning very large data sets using ! spi_exec_query, you should be aware that ! these will all go into memory. You can avoid this by using ! spi_query/spi_fetchrow as ! illustrated earlier. You have rolled 2 problems into one - spi_query+spi_fetchrow does not address the issue of returning large data sets. Suggest instead: If you are fetching very large data sets using spi_exec_query, you should be aware that these will all go into memory. You can avoid this by using spi_query and spi_fetchrow as illustrated earlier. A similar problem occurs if a set-returning function passes a large set of rows back to postgres via return. You can avoid this problem too by instead using return_next for each row returned, as shown previously. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] Article doing a basic comparison of MySQL, Oracle, PostgreSQL
Joshua D. Drake wrote: I find this peculiar, considering this: http://www.postgresql.org/docs/8.0/static/tutorial-start.html Now, perhaps the author's conclusion is just bogus but can anyone think of better ways in which we could ease people into PostgreSQL? I think more than likely it just isn't obvious where the tutorial is. I just went to the website, I clicked documentation, no immediate mention of the tutorial. Then I click 8.0, where is the tutorial? Oh... it is in the beginning of the 1300 pages of documentation. I think that the documentation should be split (back out) into separate books -- tutorial, reference, release notes, etc. It is too unwieldy as it is. The release notes at least should be separate -- I was rather pissed off when I discovered that what I had printed out included changes for releases I had no interest in. If the documents have been amalgamated to suit a publisher then I feel even more agrieved -- I resent having to pay for padding and resent the waste of paper. With a duplex printer the documentation fills two binders; printed simplex it would be more like four! Andrew Ford ford-mason.co.uk ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] [PATCHES] pl/pgSQL doco patch
I am wondering we should make this warning more prominent - it would be easily missed buried on the Oracle porting section, and I have seen people caught by it lots of times. cheers andrew Philip Yarra wrote: Hi, I supplied a minor doco patch relating to porting pl/SQL to pl/pgSQL: http://archives.postgresql.org/pgsql-hackers/2005-10/msg01295.php. Also attached here. Could someone please review and apply this for me? Regards, Philip. Index: doc/src/sgml/plpgsql.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v retrieving revision 1.79 diff -c -r1.79 plpgsql.sgml *** doc/src/sgml/plpgsql.sgml 21 Oct 2005 05:11:23 - 1.79 --- doc/src/sgml/plpgsql.sgml 28 Oct 2005 05:20:54 - *** *** 3132,3137 --- 3132,3144 state in temporary tables, instead. + + +You cannot use parameter names that are the same as columns +that are referenced in the function. Oracle does allow you to do this +if you qualify the parameter name as function_name.paramater_name + + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Online backup vs Continuous backup
Greg Stark said: > Bruce Momjian writes: > >> I noticed that we are using the term "Online Backup" in our >> documentation when we are talking about continuous backup and PITR. >> >> To me, "online backup" is doing a backup while the system is online >> (online-backup), and that is accomplished by pg_dump. > > Well fwiw what pg_dump does isn't even considered a "backup" at all in > other systems. It's a "logical export" or something of that sort. > > It's not considered a "backup" because it's saving something different > than the actual physical database. When you restore you get something > (hopefully) logically equivalent but still physically different. This seems fairly arbitrary. On that basis anything on a higher level than dd is not a backup method, ISTM. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] [HACKERS] timestamptz alias
Jim C. Nasby wrote: On Tue, Oct 03, 2006 at 12:13:46PM -0400, Andrew Dunstan wrote: Perhaps it'd be better to provide a small table of recognized type aliases, rather than inserting equivalent notes into three or four places. you mean like the table here? http://momjian.us/main/writings/pgsql/sgml/datatype.html An issue I've seen with the docs is that for chapters that have a lot of sections (such as 8), the section list at the start of each chapter fills the screen, so it's easy to miss the fact that there's more info beneath the list (which is wy presumably most folks never knew that table existed). I think the ideal way to handle this would be to put the table of contents in a side-bar and flow the text around it. But that could be a real bear to do in docbook/sgml, so perhaps it would be better to just force the TOC for each chapter onto it's own page (and ensure the overview/introduction text shows up in the TOC). I would like a frame driven version of the docs (c.f. doxygen, javadoc, etc.). The we would not need contents links at the top of each chapter like this. Navigating the HTML docs is less than pleasant. Unfortunately, I don't have enough time or docbook-fu to be able to do this. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] timestamptz alias
Magnus Hagander wrote: I would like a frame driven version of the docs (c.f. doxygen, javadoc, etc.). The we would not need contents links at the top of each chapter like this. Navigating the HTML docs is less than pleasant. Unfortunately, I don't have enough time or docbook-fu to be able to do this. Yuck. Frames. Ickk. All the issues with bookmarking and searching and things like that. Anyway. If done, make sure the current version doesn't go away, but make the frames version just an option instead. Then use a tiled mechanism instead if you want to avoid frames. Or if you want to be get more advanced some sort of Ajax solution. But we need some sort of nav bar that you can drill down on. Navigation now is just horrible, IMNSHO. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-patches] [DOCS] Change draft gmake control
Bruce Momjian wrote: Well, if 'draft' was only for html, I could see suggesting just 'gmake draft', but 'draft' can be used for Postscript and PDF too. The maybe have targets draft-html, draft-postscript and draft-pdf ? cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[DOCS] should we have a separate page that clearly defines what a minor release is and why it's a good idea to keep up with them?
I know it's mentioned in the FAQ, but I'd like to have a separate page that describes what a minor release is, and why it's a good idea to keep up with them. Basically, I want something simple and clear to point middle-managers at when they ask me why I want to upgrade the database. I'm willing to write it, if there's a consensus that it would be worth having. Andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] should we have a separate page that clearly defines what a minor release is and why it's a good idea to keep up with them?
On 2/21/07, Magnus Hagander <[EMAIL PROTECTED]> wrote: > > > I think adding to the FAQ is the best solution. What additional > > > information to we need there? > > > > I think it's important enough (and unclear enough to a lot of people) > > that it shuold have it's own non-FAQ section. Either as a page on the > > website or as a page in the documentation. > > If you look at the developer documentation, you will see I overhauled > the instructions for upgrading a minor release: > > http://momjian.us/main/writings/pgsql/sgml/install-upgrading.html > > I think that would be a good place to add more text. What additional > text do we need? Something about how you are less likely to hit a new > bug if you minor upgrade than if you stay on an older release? Something about how we put only critical fixes in back branches, and not new features. How we *really* recommend that people should always be on the latest release in a branch. How we will never (knowingly) change the behaviour of anything in a back branch (without being *very* clear in the release notes of what and why). More focus on how easy that part is. Mainly, I think people don't upgrade because (a) they don't know what they gain, and (b) they're scared something will break. We need to counter those two arguments. I think this exactly defines what I'm looking for. The most basic approach to risk management is "if it works, don't change it". What I'm looking for is something with which to convince people that the risk of breakage is so low that it's outweighed by the risk of remaining exposed to bugs which haven't caused them problems yet. Andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] should we have a separate page that clearly defines what a minor release is and why it's a good idea to keep up with them?
On 2/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: OK, the FAQ now has: The PostgreSQL team makes only bug fixes in minor releases, so, for example, upgrading from 7.4.8 to 7.4.9 does not require a dump and restore; merely stop the database server, install the updated binaries, and restart the server. All users should upgrade to the most recent minor release as soon as it is available. While upgrades always have some risk, PostgreSQL minor releases fix only common bugs to reduce the risk of upgrading. The community considers not upgrading more risky that upgrading. What should change about this text? That it's in the FAQ? I think this is one of the most common misunderstandings for people outside the community, so I think we need to find a better way to communicate about it. On the front page, we already have "Latest Releases" with links to the most recent release for each version still actively maintained and release notes. (Would it make sense to change that title from "Latest Releases" to "Actively Maintained Releases") What I'd like to see right under it is something like "Minimize your risk by keeping up with minor revisions." Which would link to a page (perhaps that section of the FAQ) that says something like the following. - "The PostgreSQL community provides minor releases on an as-needed basis to address bugs. While all upgrades involve change which carries risk, minor releases have the minimum amount of change necessary to address bugs that are serious but generally obscure (here we could link to an actual description of what does or does not go into a minor release, if we have such a thing). The community considers the risk of minor version upgrades to be less than the risk of remaining exposed to these bugs. When planning your maintenance strategy, please be sure to keep abreast of minor releases. There was a posting a while ago about projected lifespans of major releases that got side-tracked into a discussion about dropping windows builds for 8.0 and 8.1. I think this is related, but I haven't figured out how we can express these ideas. Andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] should we have a separate page that clearly defines what a minor release is and why it's a good idea to keep up with them?
On 2/21/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: All users should upgrade to the most recent minor release as soon as is reasonable for the environment. While upgrades always have some risk, PostgreSQL minor releases fix only bugs to reduce the risk of upgrading. To reduce issues a user may encounter the community strongly Or... Minor releases are intended to minimize the risk associated with change while addressing important stability or security bugs. All users are strongly encouraged to keep abreast of minor releases as their maintenance windows permit. ... Andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] should we have a separate page that clearly defines what a minor release is and why it's a good idea to keep up with them?
On 2/22/07, Magnus Hagander <[EMAIL PROTECTED]> wrote: Andrew Hammond wrote: > On 2/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > >> OK, the FAQ now has: >> >> The PostgreSQL team makes only bug fixes in minor releases, >> so, for example, upgrading from 7.4.8 to 7.4.9 does not require >> a dump and restore; merely stop the database server, install >> the updated binaries, and restart the server. >> >> All users should upgrade to the most recent minor release as soon >> as it is available. While upgrades always have some risk, PostgreSQL >> minor releases fix only common bugs to reduce the risk of upgrading. >> The community considers not upgrading more risky that >> upgrading. >> >> What should change about this text? > > That it's in the FAQ? I think this is one of the most common > misunderstandings for people outside the community, so I think we need > to find a better way to communicate about it. Agreed. > On the front page, we already have "Latest Releases" with links to the > most recent release for each version still actively maintained and > release notes. (Would it make sense to change that title from "Latest > Releases" to "Actively Maintained Releases") I think not. The meaning is "latest releases available for each branch", not "these are the actively maintained branches". Why aren't 7.3.18, 7.2.8, 7.1.6, etc there then? Clearly there is some criteria for which branches are presented there. > What I'd like to see right under it is something like "Minimize your > risk by keeping up with minor revisions." Which would link to a page > (perhaps that section of the FAQ) that says something like the > following. I'm bouncing this over to -www as well to hear what people think about that part. If we do that, I'd definitely like to see a proper page and not just a FAQ link. I agree, however, it could start as a FAQ link and go from there as time permits. > There was a posting a while ago about projected lifespans of major > releases that got side-tracked into a discussion about dropping > windows builds for 8.0 and 8.1. I think this is related, but I haven't > figured out how we can express these ideas. I fully agree that we need some kind of page that explains "versioning policy" or something like that. Like how 8.1 is in principle an "equally major" release as 8.0. I am willing to take a shot at writing a first draft of this page if there's interest in having it. Andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] should we have a separate page that clearly defines what a minor release is and why it's a good idea to keep up with them?
On 2/22/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: >> > On the front page, we already have "Latest Releases" with links to the >> > most recent release for each version still actively maintained and >> > release notes. (Would it make sense to change that title from "Latest >> > Releases" to "Actively Maintained Releases") >> >> I think not. The meaning is "latest releases available for each branch", >> not "these are the actively maintained branches". > > Why aren't 7.3.18, 7.2.8, 7.1.6, etc there then? > > Clearly there is some criteria for which branches are presented there. <7.3 is EOL. We still back patch what we can but they are considered deprecated. Yeah, I figured that was the criteria. So, is it not reasonable to say that the releases listed on the front page under "Latest Releases" are actually "Current minor release for branches which have not reached EoL"? Perhaps instead of "Latest Releases" or "Actively Maintained Releases" something like "Current Releases" says that better? Andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-www] Re: [DOCS] should we have a separate page that clearly defines what a minor release is and why it's a good idea to keep up with them?
On 3/12/07, Magnus Hagander <[EMAIL PROTECTED]> wrote: Dave Page wrote: > Magnus Hagander wrote: >> I'm bouncing this over to -www as well to hear what people think about >> that part. If we do that, I'd definitely like to see a proper page and >> not just a FAQ link. > > Agreed, though there's no reason not to have both. Including it on the > main site will add an air of legitimacy to satisfy PHBs. I've added such a page to the site now, and linked it in from the support section and from the front page. The text is more or less copied directly from the FAQ. Updates to the text are always welcome ;-) url please? Andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [DOCS] OS/X startup scripts
Tom Lane wrote: David Fetter <[EMAIL PROTECTED]> writes: I haven't included the customary diffs. This points me to some of the many deficiencies of CVS, namely that I would need write access in order to have it create a diff, Strange, it works fine for everyone else. Especially if you have cvsutils installed (can be found in many places including fedora extras). cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [DOCS] OS/X startup scripts
Heikki Linnakangas wrote: You need write-access to add files, even on anonymouse server. We often get patches with new files as separate attachments because of that. This is the part that cvsutils fakes for you (by hacking the local cvs metadata files) so you don't need write access. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [DOCS] OS/X startup scripts
David Fetter wrote: cvs diff [list of files here] |grep -v '^?' > the_file.diff Those lines go to stderr. Not when I do "cvs diff." Is there something I should (un)set in my .cvsrc? No. (The lines that go to stderr are the directory names). But I don't see why there's a problem with using the command above. Or if you prefer, use something like this to postprocess the file: perl -ni -e 'print unless /^\?/;' diff-file Bottom line - TIMTOWTDI cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] [HACKERS] Contrib modules documentation online
Tom Lane wrote: Josh Berkus <[EMAIL PROTECTED]> writes: If we go ahead with this, I'll commit to doing a contrib README cleanup so the doc system works better. Why wouldn't we just remove the README files altogether? I can't see maintaining duplicate sets of documentation. Right. Also, let's recall what has previously been discussed for contrib, namely that we break it out into standard modules (think Perl standard modules) and other tools, and that we abandon the wholly misleading "contrib" name altogether. I really want to see that happen next release. Getting the modules properly documented is a very important milestone along the way to getting that done. Maybe then the modules will be considered more first class citizens (until the buildfarm came along they were often hardly tested at all). cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [DOCS] [HACKERS] Contrib modules documentation online
Josh Berkus wrote: Greg, Are you suggesting to add an additional piece of work to the already behind schedule 8.3 timeline when there's already this idea floating around to overhaul the entire contrib structure in 8.4, which may very well make much of that work redundant? Albert's work is cool and all, but from from back here where I sit I'd expect anyone in a position to integrate it into 8.3 properly should be working on something that's already on the to-do list instead. Or the contrib overhaul may *not* get into 8.4 (ala updatable views). Having the contrib stuff in the main docs would remove one of the largest barriers to people knowing about the contrib features. I don't agree with Greg that we shouldn't make this docs improvement. I do think we should do it in such a way that it will fit with our plans for the future. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Contrib modules documentation online
Albert Cervera i Areny wrote: I'm very strongly in favor of having this documentation. However, I think it might make sense to put "Contrib Modules" as a section under either "Reference" or "Appendices". Also, I don't think it's necessary to make each command option a separate subchapter, but I can see how that would be hard to avoid in an automated system. It's not an automated system, README files have different structures so it's all manual work. That's why I asked how you think it should be organized. Anyone else thinks we should put it in Reference or Appendixes? I would far rather have a new top level heading. Something like "Standard Modules and Tools". (Please avoid the use of the word "contrib"). If not, than as a sub-chapter of "References". I don't think it belongs in the Appendixes. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Contrib modules documentation online
Peter Eisentraut wrote: Am Mittwoch, 29. August 2007 20:27 schrieb Andrew Dunstan: Also, let's recall what has previously been discussed for contrib, namely that we break it out into standard modules But that would also mean that the documentation system is somewhat modularized. What? No it doesn't. You have missed the key word in the sentence above: "standard". The idea is that the docs will describe the *standard* modules, i.e. those that ship with the PostgreSQL core distribution (because they are currently in contrib). If you want to design a pluggable documentation system then go for it, but it's not required by what I understand is the consensus plan for contrib. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Contrib modules documentation online
Peter Eisentraut wrote: Am Donnerstag, 30. August 2007 15:26 schrieb Tom Lane: I thought a large part of the desire was to improve the visibility of the contrib docs, ie, put the docs under the noses of people who have *not* installed or even heard of the modules. So "it's not in the docs unless you installed it" seems counter to the point. I thought the point was to make the extensibility features of PostgreSQL more usable so people would be more inclined to use them. The assumption being that the problem is not finding things but the hesitation against using "unofficial" things. Moving everything to the main blob of things seems to go against that idea. So perhaps some market research is required to clarify the actual requirements and goals. The idea that seemed to gain traction last time this was discussed was to treat the contrib modules as standard, included in the core distribution as examples of how modules work, and as modules that have moderately wide use (not sure how true that is of all of them, but I don't see any great point in pushing them out.) Quite apart from anything else, keeping them part of the main distribution helps us to validate the module process via buildfarm etc. So this isn't just "moving everything to the main blob of things". If you want to pay for market research then feel free ;-) cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [DOCS] Partition: use triggers instead of rules
Joshua D. Drake wrote: A trigger will probably beat a rule for inserts/updates involving a small number of rows. Which is exactly what partitioning is doing. For large numbers of rows, like an INSERT/SELECT from another large table, the rule is likely to win, because its overhead is paid once per query not once per row. Also, if you implement the trigger with an EXECUTE (forcing a planning cycle) intead of hard-coded commands, the speed advantage becomes even more dubious. Not for partitioning. Although I agree with your sentiments for normal operation. Joshua, you're not making much sense here. Tom is talking about partitioning and his analysis is correct *in the partitioning case* AFAICS. What basis do you have for saying he is not? cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [DOCS] "distributed checkpoint"
David Fetter wrote: balanced gradual extended (I see you mention time-extended but wouldn't time be implicit based on the actual docs and thus we only need extended?) How about "smoothed?" perhaps we should call it Jacob checkpointing, then. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Uniform policy for author credits in contrib module documentation?
Joshua D. Drake wrote: Tom Lane wrote: Josh Berkus <[EMAIL PROTECTED]> writes: Historically, the only way to troubleshoot some of the contrib modules was to e-mail the author. If people think that we've reached a standard that everything in /contrib is now well-documented and supported by the general community, the I suppose we don't need contact information. I'm not so sure myself. I do not think that we should encourage people to mail the authors first rather than pgsql-bugs. For one thing, a lot of those addresses are dead, and some of the ones that aren't don't respond especially fast. If the community-at-large can't handle a bug, we certainly have enough institutional memory to try to contact the original author, even if that address isn't in the SGML docs. Perhaps the at a minimum the email goes in the commit? I don't see any reason, unless we're going to start doing that for all contributions. 'contrib' is a serious misnomer anyway, and there's no reason to think in general that the original author is specially responsible for any of it. I think Tom's point is entirely valid. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] [SQL] pl/PgSQL, variable names in NEW
Joshua D. Drake wrote: On Thu, 10 Apr 2008 10:45:25 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: Question for plperl hackers: Should we remove the mention of DBD::PgSPI from the PL/Perl manual? It seems like a reasonable suggestion to me, since perl database users probably already know DBD and don't have to learn something new if they go that way. Possibly the text should be reworded, with the mention of DBD::PgSPI put somewhere else or stuck into a or something. From what I can see on CPAN (unless I am missing something) DBD::PgSPI hasn't been updated since 2004 and is at version 0.2. http://www.cpan.org/modules/by-module/DBD/ I think it can safely be removed in entirety from our manuals. +1. It's also GNU licensed, so we can't include it. A clean room BSD licensed implementation would be a nice addition, but it really doesn't buy you much in functionality that you don't already have. cheers andrew -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] include no validation of XML schema in 8.13.1- the XML Type
Poking around in the 8.5 Devel Documentation section 8.13.1, the XML Type, I noticed that: "The xml type does not validate input values against a document type declaration (DTD), even when the input value specifies a DTD" I did not notice any mention of validating against XML schema. Now that it is 2010, the XML schema 1.1 spec is in draft form of one sort or another, is it safe to leave out mentioning validating against XML schema in the PostGreSQL documentation. That is, PostGreSQL users should know enough about XML that if you can't validate against a DTD, why should you be able to validate against XML schema? I would tent towards redundancy, and include the XML schema part. Andrew Lardinois
Re: [DOCS] RFC - Navigation menu for documents
Richard Huxton wrote: Where do we go from here? 1. We can make use of some/all of this on the main site. Yes please! Richard, thanks a lot for your work on this. cheers andrew -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] DOCS: SGML identifier may not exceed 44 characters
On 05/31/2011 04:36 PM, Peter Eisentraut wrote: But it seems like no one else has seen this problem yet, so it's quite suspicious, since surely people have built the documentation in the last few months. I have two buildfarm members with stock openjade/docbook installations building the docs every day. cheers andrew -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] DOCS: SGML identifier may not exceed 44 characters
On 06/01/2011 12:55 PM, Robert Haas wrote: On Wed, Jun 1, 2011 at 3:31 AM, Albe Laurenz wrote: Peter Eisentrautwrote: Excerpts from Brendan Jurd's message of mar may 31 02:17:22 -0400 2011: openjade:information_schema.sgml:828:60:Q: length of name token must not exceed NAMELEN (44) But it seems like no one else has seen this problem yet, so it's quite suspicious, since surely people have built the documentation in the last few months. I have and I encountered the same problem. I didn't bother to report it because my machine and openjade are quite old: The machine is Red Hat Enterprise Linux ES release 3 (Taroon Update 9), and docbook.dcl is from the docbook-dtds-1.0-17.2 RPM. Maybe that really only affects quite old versions, but I think it wouldn't hurt to shorten the tag in question to avoid the problem. +1. Is there no way we can ourselves override this setting if we run into it? If it's possible that seems to me like a much better way to go. cheers andrew -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] PG documentation build is wedged
On 11/24/2011 02:43 AM, Magnus Hagander wrote:
I think the devel docs are now supposed to be built by bf member
guaibasaurus, but the necessary hooks on the buildfarm client to copy
them to the webserver aren't there yet.
It's almost there. Based on current plans, we hope to have the
developer docs up and running early next week. (Actually, didn't
realize they were broken - it's just that their new location is
planned to go live next week, which will implicitly fix this problem)
You need to change the config of this animal to something like:
optional_steps => { build_docs => { branches => [ 'HEAD' ],
min_hours_since => 0 } },
There's no point in not building the docs for HEAD on every build, since
"make dist" in the new module will build them if they're not built
anyway, but in such a way that they're not so readily usable, whereas
this way you can copy them out easily.
cheers
andrew
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Re: [HACKERS] [DOCS] Moving tablespaces
On 12/04/2011 11:41 AM, Tom Lane wrote: 1) Remove the column. Rely on the symlink. Create a pg_get_tablespace_location(oid) function, that could be used by pg_dumpall and friends, that just reads the symlink. Hm, how portable is symlink-reading? If we can actually do that without big headaches, then +1. I wondered that, specifically about Windows junction points, but we seem to have support for it already in dirmod.c::pgreadlink(). Surely there's no other currently supported platform where it would even be a question? cheers andrew -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [HACKERS] [DOCS] Contrib module "xml2" status
On 02/21/2013 12:56 PM, Magnus Hagander wrote: On Thu, Feb 21, 2013 at 6:39 PM, Robert Haas wrote: On Wed, Feb 20, 2013 at 11:58 AM, Ian Lawrence Barwick wrote: I'm not sure if this is a documentation or hackers issue, but the documentation page for contrib module "xml2" refers to PostgreSQL 8.4 in the future tense: "It is planned that this module will be removed in PostgreSQL 8.4 in favor of the newer standard API" http://www.postgresql.org/docs/devel/static/xml2.html Are there any plans to remove this module by a forseeable date? Nope. I have repeatedly been voted down on removing it, and I've also been repeatedly voted down on removing the deprecation text. Could we at least agree on changing the deprecation text to say "This module is deprecated and may be removed in a future release"? Not reopening the actual discussion about rmeoving it, but assuming we're not, strong +1 on changing the deprecation message. And don't forget to backpatch the change so it shows up in the old versions of the docs as well. Yes, we should change it to remove the reference to 8.4. The point is we can remove the module when someone fixes and replaces the functionality that's left in there that some people rely on. So far nobody has stepped up to the plate, although now that we have lateral a sane replacement for xpath_table might well be a lot easier to achieve. If someone is interested in working on this I'd be happy to hear about it. Maybe it would be a good Google SOC project. cheers andrew -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [PATCH] Fix discrepancy in hstore_to_json_loose documentation
On 04/10/2013 08:36 AM, Marti Raudsepp wrote: Hi list, I was checking out the new JSON features coming in 9.3, really cool stuff! I noticed a small discrepancy in the documentation, the "hstore_to_json_loose" example uses hstore_to_json() by accident. Patch attached. Thanks, will fix. cheers andrew -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] 18.4.4. Linux huge pages
In most versions of Linux, the default hugepage size is 2m. Other Unix versions may have different hugepage sizes, e.g. AIX, but Linux defaults to 2m Sent from my iPad > On Oct 21, 2016, at 11:43 AM, [email protected] wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.6/static/kernel-resources.html > Description: > > Hi, > > it's a mistake in 18.4.4. Linux huge pages (also in 9.4 and 9.5 > documentation). Example how to count number f huge pages says: > > 6490428 / 2048 (PAGE_SIZE is 2MB in this case) are roughly 3169.154 huge > pages, so you will need at least 3170 huge pages: > > It's very rare that PAGE_SIZE is 2MB. It's more common situation that > the > value is 4096KB. But it's not a problem. > > The VmPeak should by divded not by PAGE_SIZE but by Hugepagesize listed by > cat /proc/meminfo | grep Hugepagesize. > > > > -- > Sent via pgsql-docs mailing list ([email protected]) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-docs -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Link to PAM pages broken
Alvaro, Its been quite some years since I last followed the pam stuff. Since the kernel.org breakin, pretty much everything there has been undone. I can ask around about what might be salvagable, but Thorsten really is the one to know where the latest copy of everything is. Cheers Andrew On Fri, Oct 28, 2011 at 3:24 PM, Alvaro Herrera wrote: > > Andrew, Thorsten, > > What's the best place to link to the Linux PAM docs now that the > kernel.org copy is gone? > > Thanks > > --- Begin forwarded message from Thom Brown --- > From: Thom Brown > To: Pg Docs > Date: Mon, 10 Oct 2011 13:52:36 -0300 > Subject: [DOCS] Link to PAM pages broken > > Hi all, > > I notice that the links to both the Linux PAM page and Solaris PAM > page are broken in our documentation. The bottom of the > http://www.postgresql.org/docs/current/static/auth-methods.html page > points to http://www.kernel.org/pub/linux/libs/pam/ and > http://www.sun.com/software/solaris/pam/. The former is broken, the > latter redirects to some generic Oracle page. > > I can't find a suitable candidates for substitution. I found > http://linux.die.net/man/8/pam.d and > http://dsc.sun.com/solaris/articles/user_auth_solaris3.html but > nothing to directly replace them. Any ideas? > > --- End forwarded message --- > > -- > Álvaro Herrera > -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
