[DOCS] Correction for 12.2.2.1. Serializable Isolation versus True Serializability
At least two other popular production database products provide true serializability, as described in PostgreSQL documentation (section 12.2.2.1 of 8.1 devel). I'm a big fan of PosgreSQL, but let's not overstate things. Some users may have applications with do depend on the true serializability of their current product and may have subtle bugs under PostreSQL if they are not careful about the difference in behavior. At a minimum we should remove the clause ", and so far as we are aware no other production DBMS does either". If we could explicitly warn people about when these differences may cause problems, it could help smooth transitions from other products -- people could either ensure that they were safe, or they would know where they need to change code to be safe under PostgreSQL. For example, on Sybase ASE 12.5.1: -- Connection A: create table mytab (class int not null, value int not null, primary key (class, value)) lock datarows -- Using the least restrictive blocking level. If it happens here it will happen with the other schemes. -- Connection A: insert into mytab values (1, 10) insert into mytab values (1, 20) insert into mytab values (2, 100) insert into mytab values (2, 200) -- Connection A: set transaction isolation level serializable begin transaction SELECT SUM(value) FROM mytab WHERE class = 1 -- Query returns the value 30. -- Connection B: set transaction isolation level serializable begin transaction SELECT SUM(value) FROM mytab WHERE class = 2 -- Query returns the value 300. -- Connection A: insert into mytab values (2, 30) -- Query blocks indefinitely, waiting for locks from Connection B. -- Connection B: insert into mytab values (1, 300) -- Query blocks, waiting for locks from Connection A. -- After a configurable delay, deadlock checking kicks in. -- One query or the other will get an error like the following: Your server command (family id #0, process id #706) encountered a deadlock situation. Please re-run your command. Error code: 1205 SQL state: 40001 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[DOCS] ALTER TABLE x ALTER COLUMN y TYPE z
On this page: http://www.postgresql.org/docs/8.1/interactive/sql-altertable.html there is this user comment: To change the data type of a column, do this: BEGIN; ALTER TABLE tab ADD COLUMN new_col new_data_type; UPDATE tab SET new_col = CAST(old_col AS new_data_type); ALTER TABLE tab RENAME old_col TO temp_name; ALTER TABLE tab RENAME new_col TO old_col; ALTER TABLE tab DROP COLUMN temp_name; COMMIT; You might then want to do VACUUM FULL tab to reclaim the disk space used by the expired rows. The 8.1 release (and the 8.0 release) support the same functionality with a single line: ALTER TABLE tab ALTER COLUMN old_col TYPE new_data_type; I think the user comment should be removed, unless there is some benefit to using the multi-step process. If there is some benefit, I think it should be described, so that users know when to use it instead of the simpler technique. -Kevin ---(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] ALTER TABLE x ALTER COLUMN y TYPE z
>>> On Wed, Mar 22, 2006 at 1:00 pm, in message <[EMAIL PROTECTED]>, Robert Treat <[EMAIL PROTECTED]> wrote: > > I believe Tom's comments in this email apply similarly here. > http://archives.postgresql.org/pgsql- general/2006- 03/msg00891.php The user comment's recommended technique includes this line: ALTER TABLE tab DROP COLUMN temp_name; Would this cause a table rewrite? (Not a rhetorical question. I really don't know.) > Feel free to submit an additional doc comment. I did, but it was rejected -- presumably because it included a question. Once I have a better handle on the issue, if it seems like it needs it, I'll try again. -Kevin ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [DOCS] Streaming replication document improvements
Tom Lane wrote: > Robert Haas writes: >> Fujii Masao wrote: >>> 3. Your proposal >>>Treat superuser replication connection like non-superuser one > >> Well, only for this one very specific purpose. I would adjust >> the docs like this: > >> Determines the number of connection "slots" that are reserved for >> connections by PostgreSQL superusers. At most max_connections >> connections can ever be active simultaneously. Whenever the >> number of active concurrent connections is at least >> max_connections minus superuser_reserved_connections, new >> connections will be accepted only for superusers, and no new >> replication connections will be accepted. > >> I think that's pretty simple and clear. > > +1. I'm not sure about the consequences of converting walsender > to non-superuser across the board, and would prefer not to > experiment with it at this stage of the release cycle. +1 -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] no universally correct setting for fsync
Josh Berkus wrote: > I believe that the note about needing fsync for Warm Standby to > work correctly is true, but could someone verify it? It couldn't really affect the archiving of the WAL files, but if your warm standby is there for recovery purposes, it might not make a lot of sense to turn off fsync on the standby -- if that is something which has an effect during the recovery phase. Does it? Also, perhaps the issue deserves some mention in the PITR recovery section: http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#BACKUP-PITR-RECOVERY Step 6 says: | If you have unarchived WAL segment files that you saved in step 2, | copy them into pg_xlog/. (It is best to copy them, not move them, | so you still have the unmodified files if a problem occurs and you | have to start over.) If the recovery is happening because of OS or hardware failure on the source, and it was running with fsync off, this might be unwise. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] error in oracle to plpgsql documentation ?
Marc Cousin wrote: > DECLARE > CURSOR referrer_keys IS > I guess it should be > > DECLARE > referrer_keys CURSOR IS > If I'm right, a patch is attached (the code works with the > correction) The patch looks correct to me. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] pgcrypto links
In looking for documentation of pgcrypto to respond to a user request for help, I noticed that we could have provided more links to help users find the docs for it. Attached is a docs patch which is intended to help with that. -Kevin *** a/doc/src/sgml/pgcrypto.sgml --- b/doc/src/sgml/pgcrypto.sgml *** *** 7,12 --- 7,17 pgcrypto + + encryption + for specific columns + + The pgcrypto module provides cryptographic functions for PostgreSQL. *** a/doc/src/sgml/runtime.sgml --- b/doc/src/sgml/runtime.sgml *** *** 1504,1510 $ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid` The contrib function library pgcrypto allows certain fields to be stored ! encrypted. This is useful if only some of the data is sensitive. The client supplies the decryption key and the data is decrypted on the server and then sent to the client. --- 1504,1511 The contrib function library pgcrypto allows certain fields to be stored ! encrypted. (See for details.) ! This is useful if only some of the data is sensitive. The client supplies the decryption key and the data is decrypted on the server and then sent to the client. -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] pgcrypto links
Robert Haas wrote: > I don't think the index entry you've added to pgcrypto is very > appropriate, considering that there is a section with *exactly > that name* in runtime.sgml. That was intentional. Did you look at what it generated on the index page? | encryption, Encryption Options | for specific columns, pgcrypto It seems to me that's a good thing, and we should do more of it. > As for the reference from runtime.sgml to pgcrypto, how about > adding it inline, as in the attached? Absolutely. I wanted to do that, but failed to figure out how. Now I know. Thanks, -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Ambiguous index entry for Privileges
Thom Brown wrote: > On 12 August 2010 00:05, Thom Brown wrote: >> I noticed that there are 2 linked entries for "Privileges": >> http://www.postgresql.org/docs/9.0/static/bookindex.html#AEN128982 >> >> While they both go to different pages (with admittedly very >> similar content), those pages are both entitled "Privileges" so >> it's unclear from the index which page you'll end up at. Can we >> rename one of those pages to clarify as it looks weird in the >> index. > > Does anyone have an opinion on this? Sure -- I think the page at http://www.postgresql.org/docs/9.0/static/privileges.html (in "Chapter 20. Database Roles and Privileges" should be more conceptual rather than a subset of the other page. Rather than explaining how to use GRANT and REVOKE to change privileges, it should give an overview of privileges and discuss what is allowed by each particular privilege. It could link to the other page, so there would be one place to keep up-to-date on how to grant and revoke privileges. I think the page at http://www.postgresql.org/docs/9.0/static/ddl-priv.html (in "Chapter 5. Data Definition") should be renamed to something more like "Modifying Privileges" or "Granting and Revoking Privileges" (or something to that effect). It might make sense to have its entry in the index be a secondary entry under privilege, with some similar qualification. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Primary Key index
Thom Brown wrote: > In response to a user asking a question about indexes on primary > keys > (http://archives.postgresql.org/pgsql-performance/2010-08/msg00194.php) > I attach a patch to add information to the Primary Keys section of > the Constraints page. While the information already exists on the > CREATE TABLE, I don't think a brief mention on the page specifically > concerning primary keys could hurt. > > So here's a patch to add it. Worth adding? I think so, but I think we should cover UNIQUE constraints, too. I was also thinking about possibly mentioning it in the index overview page, and adding an entry or two to the documentation index, but maybe that's overkill. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Primary Key index
Thom Brown wrote: > Well I guess the question is: "where will most people first look > to find that piece of information out?" The OP mentioned looking in the Indexes section of the documentation for the answer. > As long as the information isn't digressing from the topic it's > mentioned in, I don't see the problem. :) The Introduction to the Indexes section mentions how to create and drop indexes, without any mention of indexes tied to these constraints. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Primary Key index
Thom Brown wrote: > On 18 August 2010 21:53, Peter Eisentraut wrote: >> On ons, 2010-08-18 at 16:52 +0100, Thom Brown wrote: >>> I attach a patch to add information to the Primary Keys section >>> of the Constraints page. While the information already exists >>> on the CREATE TABLE, I don't think a brief mention on the page >>> specifically concerning primary keys could hurt. >>> >>> So here's a patch to add it. Worth adding? >> >> is probably not appropriate here, because you are not >> defining the term for the first time. >> > That is true. It looks like discussion died here. Do you want to propose a new patch? (I'd be happy to give it a shot if you'd rather.) In any event, we should probably mention this for all three constraint types which automatically create an index: PRIMARY KEY, UNIQUE, and EXCLUSION. It might even be worth mentioning in the FOREIGN KEY section that in PostgreSQL these are *not* created automatically, and it is often wise to do so manually. I've seen a few posts from people who don't understand why their deletes run so slowly, because they're used to other database products which automatically create an index on the referencing side of a foreign key. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > And another prototype: > http://www.flickr.com/photos/dark_ixion/4927669444/sizes/o/ Wow! That looks *really* slick! That is much more readable than what I'm used to seeing! -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > Joshua D. Drake wrote: >> It is great for it to be aesthetically pleasing but if we have >> those minor inconsistencies I think it would be distracting from >> the information itself. > > Agreed, and it's sort of experimental at the moment. If it > doesn't help present information better, it's useless really. I know this sort of thing gets pretty subjective, but having gone back and looked at it a couple times... (1) I don't find the shadows distracting, but I can see where that could be a factor for some -- if it distracts anybody, I won't miss them too much. (2) The one thing I *do* find distracting is the wide separation in the colors used for the different boxes (grey, yellow, blue, red). I like the warning to stand out with red, but if the others were somewhat more subtle differences, I think it would be less jarring and distracting. You know, enough that you can tell the difference if you're looking for it, and enough to register subliminally, but not enough to slap you upside the head. Hmmm... Does that qualify as bikeshedding? -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Primary Key index
Thom Brown wrote: > Kevin Grittner wrote: >> It looks like discussion died here. Do you want to propose a new >> patch? (I'd be happy to give it a shot if you'd rather.) > > Sure, go for it. :) Initial stab at it attached. I'm torn on whether the paragraph I added to the foreign key constraint section should be in a warning block -- we do see complaints from time-to-time from people who are surprised by slow deletes from referenced tables; in some cases they have come from database products which automatically create an index on the referencing columns and are surprised that they need to choose whether and how to do so in PostgreSQL. I think we may want to link to these sections from the appropriate sections of CREATE TABLE (and possibly ALTER TABLE), but that seems like it could be a separate patch. Exclusion constraint documentation relies rather more heavily on the CREATE TABLE page, and is skimpy on the constraints page. I think that the CREATE TABLE page should focus on syntax and an overview, and link to the constraints page for any in-depth information. Again, that seems like it could be addressed separately, but it seemed worth mentioning, since I stumbled across it. -Kevin *** a/doc/src/sgml/ddl.sgml --- b/doc/src/sgml/ddl.sgml *** *** 550,555 CREATE TABLE products ( --- 550,563 + Adding a unique constraint will automatically create a unique btree + index on the column or group of columns declared for the constraint. + The index name will match the name given to the constraint; if no + constraint name is specified, it will be the table name suffixed + with _columnname_key. + + + In general, a unique constraint is violated when there is more than one row in the table where the values of all of the columns included in the constraint are equal. *** *** 623,628 CREATE TABLE example ( --- 631,644 + Adding a primary key will automatically create a unique btree index + on the column or group of columns declared for the primary key. + The index name will match the name given to the constraint; if no + constraint name is specified, it will be the table name suffixed + with _pkey. + + + A table can have at most one primary key. (There can be any number of unique and not-null constraints, which are functionally the same thing, but only one can be identified as the primary key.) *** *** 832,837 CREATE TABLE order_items ( --- 848,863 + Since a DELETE of a row from a referenced table + or an UPDATE of a referenced column will require + a scan of the referencing table for rows matching the old value, it + is often a good idea to index the referencing columns. Because it + is not always needed, and there are many choices available on how + index, declaration of a foreign key constraint does not + automatically create an index. + + + More information about updating and deleting data is in . *** *** 875,880 CREATE TABLE circles ( --- 901,915 See also CREATE TABLE ... CONSTRAINT ... EXCLUDE for details. + + + Adding an exclusion constraint will automatically create an index + of the type specified in the constraint declaration. The index + name will match the name given to the constraint; if no constraint + name is specified, it will be the table name and column names used + in the constraint, separated by underscores, suffixed with + _excl. + -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Primary Key index
Thom Brown wrote: > Looks good. Do we usually got into fine details such as the name > of the index? They'll see the index name returned when they > create the table or add the constraint anyway, and if they missed > it they only need to do a "\dt tablename" to find out what it was. Hmmm... Perhaps that is overkill. It seemed like a good idea at the time, but I'm not inclined to argue about it if it seems too detailed to you. Revised patch attached. -Kevin *** a/doc/src/sgml/ddl.sgml --- b/doc/src/sgml/ddl.sgml *** *** 550,555 CREATE TABLE products ( --- 550,560 + Adding a unique constraint will automatically create a unique btree + index on the column or group of columns declared for the constraint. + + + In general, a unique constraint is violated when there is more than one row in the table where the values of all of the columns included in the constraint are equal. *** *** 623,628 CREATE TABLE example ( --- 628,638 + Adding a primary key will automatically create a unique btree index + on the column or group of columns declared for the primary key. + + + A table can have at most one primary key. (There can be any number of unique and not-null constraints, which are functionally the same thing, but only one can be identified as the primary key.) *** *** 832,837 CREATE TABLE order_items ( --- 842,857 + Since a DELETE of a row from a referenced table + or an UPDATE of a referenced column will require + a scan of the referencing table for rows matching the old value, it + is often a good idea to index the referencing columns. Because it + is not always needed, and there are many choices available on how + index, declaration of a foreign key constraint does not + automatically create an index. + + + More information about updating and deleting data is in . *** *** 875,880 CREATE TABLE circles ( --- 895,905 See also CREATE TABLE ... CONSTRAINT ... EXCLUDE for details. + + + Adding an exclusion constraint will automatically create an index + of the type specified in the constraint declaration. + -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Primary Key index
Thom Brown wrote: > Yeah, I think that covers it well. :) I found a typo. :-( Another revision attached. -Kevin *** a/doc/src/sgml/ddl.sgml --- b/doc/src/sgml/ddl.sgml *** *** 550,555 CREATE TABLE products ( --- 550,560 + Adding a unique constraint will automatically create a unique btree + index on the column or group of columns declared for the constraint. + + + In general, a unique constraint is violated when there is more than one row in the table where the values of all of the columns included in the constraint are equal. *** *** 623,628 CREATE TABLE example ( --- 628,638 + Adding a primary key will automatically create a unique btree index + on the column or group of columns declared for the primary key. + + + A table can have at most one primary key. (There can be any number of unique and not-null constraints, which are functionally the same thing, but only one can be identified as the primary key.) *** *** 832,837 CREATE TABLE order_items ( --- 842,857 + Since a DELETE of a row from a referenced table + or an UPDATE of a referenced column will require + a scan of the referencing table for rows matching the old value, it + is often a good idea to index the referencing columns. Because it + is not always needed, and there are many choices available on how + to index, declaration of a foreign key constraint does not + automatically create an index. + + + More information about updating and deleting data is in . *** *** 875,880 CREATE TABLE circles ( --- 895,905 See also CREATE TABLE ... CONSTRAINT ... EXCLUDE for details. + + + Adding an exclusion constraint will automatically create an index + of the type specified in the constraint declaration. + -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > The reason I removed the corners is that they can't be applied to > a warning or caution box using their current markup (as the > background pushes beyond the rounded corner), and when they appear > near a normal rounded-corner box, it might look a bit inconsistent > (same but with rounded corners): > http://www.flickr.com/photos/dark_ixion/4931878975/sizes/o/ > > Hmmm.. although looking at it again, maybe it doesn't. I dunno. That looks better to my eye -- square corners on a page with that many boxes for code start to look pretty harsh, to the point of being a bit jarring. The round corners soften that for me, and make it easier to look at. (I don't know how widespread that reaction is, though.) -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > Okay, got rid of all the shadows, rounded corners etc and made > some other changes: > http://www.flickr.com/photos/dark_ixion/4932396780/sizes/o/ I generally liked the rounded corners. The tables near the front are probably better off without them, but I would rather see rounded corners on the rest. I know someone said the shadows were distracting, but I don't remember any complaints about the corners. Did I miss or forget something? -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] SGML on functions
Alvaro Herrera wrote: > Excerpts from Thom Brown's message: >> variance(> class="parameter">expression) >> >> vs >> >> stddev_samp(> class="parameter">expression) >> >> Which way is correct? > > The latter I think -- see > http://www.docbook.org/tdg/en/html/function.html > (but perhaps search the actual standard) Nothing I saw at that link suggests that the parameters should be included within the scope. If you follow links from there to here: http://www.docbook.org/tdg/en/html/funcsynopsis.html You find examples like this: void qsort void *dataptr[] int left int right int (* comp) void *, void * -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > Okay, as per Robert's suggestion, I've changed all > example/definition/synopsis boxes to grey, and followed Dave's > suggestion of restoring borders and making the default text colour > black for all boxed content. Bear in mind the rubbish screenshot > app I'm using heavily compresses the image, so elements aren't > appearing as clear as they should do. > > http://www.flickr.com/photos/dark_ixion/4937010683/sizes/o/ For me, that's the easiest to read so far. With a lot of the other distractions cleaned up, I wonder if it's worth throwing another version up with subtle shadows on the boxes which have rounded corners. I think that glitzes things up enough to make it more pleasing visually, without really distracting me. Of course if its distracting enough for anyone to annoy or detract from usability then they don't belong -- I just wonder if they might have previously been seen as distracting largely because of they were next to all those eye-grabbing colors -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] SGML on functions
Thom Brown wrote: > Kevin Grittner wrote: >> You find examples like this: >> >> >> >> void qsort >>void *dataptr[] >>int left >>int right >>int (* comp) >> void *, void * >> >> >> > > But that page also says "Using FuncSynopsis for languages that are > unrelated to C may prove difficult." > > Using that syntax will result in a semi-colon being placed at the > end of the function when parsed. Yes, but that's the only place I could find an example of function and parameter together. The parameter tag can be used inside of function as well as in most of the places function can be used, so the definition seemed ambiguous to me. I took these examples as being the best evidence I could find about whether parameter tags were intended to be inside or outside of the function tag. I suppose an argument could be made that for functions for which the identity is totally determined by function name (as in C) the parameters should be outside the tag, while functions in SQL need the parameters inside the tag, because they are used to identify a particular function among many with the same name. It appears that, technically, either format is allowed. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > The only change is the addition of very light shadowing (for Dave > and Kevin) Sorry for sounding picky, but can the shadowing be even lighter? It seems a tad heavy next to the light gray in the boxes. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Tom Lane wrote: > The yellow "note" boxes still strike me as too eye-grabbing for > their purpose. Otherwise this version seems nice. How about a color which still differentiates these without being quite so bold -- like Beige (#F5F5DC)? For an example, see: http://en.wikipedia.org/wiki/Beige (What *don't* they have?) -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > Kevin Grittner wrote: >> The rounded corners and shadows aren't showing up in Konqueror > Okay, it appears there's also a KHTML engine setting for pre-CSS3 > support. I've added that in now for rounded corners and shadows. > Any different? Konqueror now shows rounded corners but no shadows. (As you probably expected, no change in Firefox.) -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > And Kevin, I made the shadows a bit lighter in this version and > used the beige notes box. For my taste, that's perfect. (Now there's the trivial matter of making everyone else happy. ;-) ) The rounded corners and shadows aren't showing up in Konqueror, but everything still looks great there -- just not a jazzy as it does in Firefox. This seems to me to be a very professional, attractive presentation. Outstanding work! -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > Okay, I've made a couple other changes, but if it's not working > now, I don't think it's supported. This page suggests that > box-shadow isn't yet supported by KHTML: > http://www.legendscrolls.co.uk/webstandards/khtml No shadows in Konqueror. > I've just tested it in Opera, and CSS as it is causes massive > jumps in font size for some elements, so I'll need to fix those > too. Now that you mention it, there are some large fonts for some elements in Konqueror, too. I'll check that after you fix it for Opera. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: Thom Brown writes: > Now the font sizes should be virtually the same in all > browsers. That looked good in Firefox and Konqueror on my kubuntu machine. > Okay, I've added a slightly modified version of that in (was > missing in the new version of the site), removed the generic > font-size for monospace, and adjusted the gecko CSS file to target > a reduced set of elements (the previous targetted too much on the > new site). Back to giant monospace characters in Konqueror. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > Bruce Momjian wrote: >> I found some sample code the is supposed to work in all browers. >> I tested it in Firefox and it worked. It should work in Opera >> and IE as well. HTML/Javascript file attached. > > Thanks Bruce. I've implemented your recommended change. :) Looks good to me in both Firefox and Konqueror. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > I've added an experimental content navigation menu (appears in > top-right-hand corner) which jumps to sections of the same page. > It only appears on pages which have items to navigate to, > including the main index. I don't feel strongly about this feature one way or another. If it is added, I'll probably use it now and then. > http://pgweb.darkixion.com:8081/docs/8.4/static/sql-syntax-lexical.html The lower level of links in the pop-up don't work for me in either Firefox or Konqueror. The top level works fine. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > Anymore feedback/suggestions? Anything not look right? Are we there > yet? The only thing I found a little distracting with the current layout is that on some pages the horizontal lines for the section and subsection are very close together. If the lines for subsections were less imposing, it would probably help. I don't know if it's possible to make them match the length of the subsection title; if not, perhaps thinner or lighter would help. Overall it's looking quite good to me. > I was thinking the borders look a bit too bold, so might reduce > them. That's worth a try. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > Kevin Grittner wrote: >> The only thing I found a little distracting with the current >> layout is that on some pages the horizontal lines for the section >> and subsection are very close together. If the lines for >> subsections were less imposing, it would probably help. I don't >> know if it's possible to make them match the length of the >> subsection title; > Okay, I think I've now covered those. I like it. >>> I was thinking the borders look a bit too bold, so might reduce >>> them. >> >> That's worth a try. > > Done I like that, too. I just noticed that the text size links in the upper right corner don't seem to work. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > The notes section still looks really drab on my screen. Are you talking about the Release Notes page: http://pgweb.darkixion.com:8081/docs/8.4/static/release.html notes for a major release: http://pgweb.darkixion.com:8081/docs/8.4/static/release-8-4.html or notes for a minor release: http://pgweb.darkixion.com:8081/docs/8.4/static/release-8-4-4.html All three? Something entirely different? -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [pgsql-www] [DOCS] Example indenting
Thom Brown wrote: > There are boxes containing notes which I had originally coloured > yellow, but we went for beige instead. Example appears on: > http://pgweb.darkixion.com:8081/docs/9.0/static/ddl-priv.html Oh, *those* notes. Got it. As I recall, Tom felt that the yellow was too much of an "eye-grabber" for the strength of what we were putting in such sections, and I tended to agree. (I still do, actually.) I suggested beige as something which made them easy to pick out without screaming for attention. I'll concede that beige is drab, but at the time I couldn't think of anything else which would serve as well. If you want about the same degree of "grab" with less "drab", perhaps a pale cyan? I dunno -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] 9.0 PDFs lost 'bookmarks' tab
"Erik Rijkers" wrote: > Something seems to have gone wrong with generating the version 9.0 > PDFs on the website: both A4 and US have no bookmarks tab. (I'm > reading with Adobe Reader 7.0.0) Odd. From this page: http://www.postgresql.org/docs/manuals/ With Okular Version 0.9.2 the 9.0 US PDF has a working Bookmarks tab, as well as the Thumbnail and Reviews tabs, but the Contents tab is disabled. (It works with the 8.4 US PDF.) Perhaps it has something to do with the filtering to reduce the file size; it may have had some unexpected side effects. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] CREATE CUSTOM TEXT SEARCH PARSER
Katharina kuhn wrote: > I'd like to build a custom text search parser and then use it > within a custom text search configuration. > It would be great if you could give us an example showing how to > build a custom parser, including examples of start, gettoken and > end functions. You might want to look at the contrib/test_parser directory. Then again, you might not -- I needed some custom tsearch2 parsing behavior and struggled with a custom parser based on that for a couple days before I decided that it was easier to use regular expression functions within pl/pgsql to pick out what I wanted and cast it to a tsvector. This was less code and seemed less fragile than the developing soemthing based on the contrib example. YMMV, of course. This motivated me to put a rewrite of the current tsearch2 parser to something based on regular expressions onto my personal PostgreSQL TODO list. (No guarantees on when I might get to it, though.) -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] Concurrency Control chapter - READ COMMITTED
I was reviewing the Concurrency Control chapter to work up suggestions for the guy who has agreed to create a doc patch to go with the Serializable Snapshot Isolation (SSI) patch. It occurred to me that there is a gap which has nothing to do with the patch, and wondered whether we should ignore it, include it along with the rest, or submit it as a separate patch. The issue is that I don't see anything in the documentation which would lead people to expect the following behavior, and I'm inclined to think that our documentation should cover it somehow: -- connection 1 test=# create table t (id int not null primary key, val int not null, matches bool not null); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t_pkey" for table "t" CREATE TABLE test=# insert into t select n, n, false from (select generate_series(1,10)) x(n); INSERT 0 10 test=# begin; BEGIN test=# update t set val = val + 1; UPDATE 10 -- connection 2 test=# update t set matches = true where val between 4 and 6; [blocks] -- connection 1 test=# commit; COMMIT -- connection 2 UPDATE 2 test=# select * from t; id | val | matches +-+- 1 | 2 | f 2 | 3 | f 3 | 4 | f 6 | 7 | f 7 | 8 | f 8 | 9 | f 9 | 10 | f 10 | 11 | f 4 | 5 | t 5 | 6 | t (10 rows) Note that the explicit BEGIN and COMMIT would not be necessary for this to occur -- it's just an easy way to get the timings right for an example of what can happen. The two update statements by themselves could do this if the timing happened to fall just the right way. I think most people, having read the PostgreSQL documentation, would expect connection 2 to update three rows, since the table has three matching rows both before and after the transaction on connection 1. This happens because under PostgreSQL's READ COMMITTED transaction isolation level, if a query blocks with a write conflict and the other transaction commits, the blocked transaction follows the pointer to the new version of the row and checks whether it still meets the criteria -- if so it operates on the new row; otherwise it ignores the row. I'm not looking to change this -- the questions are whether the Concurrency Control chapter of the documentation should mention it and, if so, whether that should be submitted as a separate patch. -Kevin
Re: [DOCS] Concurrency Control chapter - READ COMMITTED
"Kevin Grittner" wrote: > The issue is that I don't see anything in the documentation which > would lead people to expect the following behavior Never mind, the "website" example covers the ground. I shouldn't try to post before the caffeine is fully in effect. Sorry for the noise. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] Couple document fixes
Thom Brown wrote: > I've attached a couple minor fixes to the docs. One relating to > SECURITY LABEL and the other for pg_class.relpersistence relpersistence should be "char", not char. Oddly enough, there is a difference. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] Couple document fixes
Thom Brown wrote: > relkind in the same table is the same type, but isn't displayed as > "char" in the docs, and the same applies to many other system tables. > They would need changing too then. > > Examples are: > > pg_type.typtype > pg_proc.provolatile > pg_attribute.attstorage That's a good point. Consistency would trump getting a single entry right, for sure. I wonder, though, whether we shouldn't consistently distinguish them. For one thing, I've seen multiple posts where people were reporting "bugs" because of having confused char with "char". FWIW, \d shows: Table "pg_catalog.pg_class" Column | Type| Modifiers -+---+--- relname | name | not null relnamespace| oid | not null reltype | oid | not null reloftype | oid | not null relowner| oid | not null relam | oid | not null relfilenode | oid | not null reltablespace | oid | not null relpages| integer | not null reltuples | real | not null reltoastrelid | oid | not null reltoastidxid | oid | not null relhasindex | boolean | not null relisshared | boolean | not null relpersistence | "char"| not null relkind | "char"| not null relnatts| smallint | not null relchecks | smallint | not null relhasoids | boolean | not null relhaspkey | boolean | not null relhasexclusion | boolean | not null relhasrules | boolean | not null relhastriggers | boolean | not null relhassubclass | boolean | not null relfrozenxid| xid | not null relacl | aclitem[] | reloptions | text[]| Indexes: "pg_class_oid_index" UNIQUE, btree (oid) "pg_class_relname_nsp_index" UNIQUE, btree (relname, relnamespace) Currently we don't seem to distinguish them in very many places in the docs: $ find -name '*.sgml' | xargs egrep -n '\"char\"' ./doc/src/sgml/textsearch.sgml:1271:setweight(vector tsvector, weight "char") returns tsvector ./doc/src/sgml/datatype.sgml:1116:length might change in a future release. The type "char" ./doc/src/sgml/datatype.sgml:1134: "char" ./doc/src/sgml/release-old.sgml:4406:Add routines for single-byte "char" type(Thomas) ./doc/src/sgml/release-old.sgml:4747:Make "char" type a synonym for "char(1)" (actually implemented as bpchar)(Thomas) ./doc/src/sgml/xfunc.sgml:1794: "char" ./doc/src/sgml/release-8.0.sgml:3389: "char" data type have been removed. ./doc/src/sgml/release-8.0.sgml:4460:"char" data type have been removed. ./doc/src/sgml/release-8.0.sgml:4466:to do arithmetic on a "char" column, you can cast it to ./doc/src/sgml/func.sgml:8462: setweight(tsvector, "char") ./doc/src/sgml/btree-gin.sgml:17: oid, money, "char", -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Document that char () ignores spaces only in non-patterncomparisons
Bruce Momjian wrote: > A private email I received indicated that our documentation about > ignoring trailing spaces in CHAR() comparisons was slightly > inaccurate. I have update our docs to indicate it is only > non-pattern comparisons that ignore spaces with CHAR(). Applied > doc patch attached. This language: | disregarded when non-pattern comparing two values seems quite awkward. Isn't it a stretch to consider pattern-matching predicates to be compares, anyway? It seems like it would be better to distinguish between comparisons, where the trailing spaces are ignored, and other predicates such as pattern matching, where trailing spaces are not ignored. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Document that char () ignores spaces only in non-patterncomparisons
Bruce Momjian wrote: > I have applied an updated patch FWIW, that looks good to me. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] use of '=' in long options documentation
Bruce Momjian wrote: > Peter Eisentraut wrote: >> On tis, 2011-03-08 at 22:32 -0500, Bruce Momjian wrote: >>> Looking at our ref pages, I see some manual pages specify long >>> options that take arguments using '=', e.g. initdb.sgml: >>> >>> --long-opt=opt >>> >>> and some do not, e.g. pg_dump.sgml: >>> >>> --long-opt opt >>> >>> So, which should we use, for consistency? >> >> Using = is more common usage, I think. > > Yeah! Someone chimed in with a vote! I will update the docs, but > not adjust any summary that has a space after the equals, e.g. > initdb. I agree that using = is more common; but also that anything suggesting that a space after the = should be avoided. I think it's preferable to show the = when possible without misleading, and omit it when it would mislead. Accuracy should trump consistency here IMO. I think it's OK to omit in summary and show in detail. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] Another SSI typo
Trivial patch attached. -Kevin ssi-typo-20110327.patch Description: Binary data -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Proposal: syntax highlight in html manual
Daniele Varrazzo wrote: > - http://pgmp.projects.postgresql.org/highlight/psql.html > - http://pgmp.projects.postgresql.org/highlight/postgres.html > > Is there any interest in applying highlighted syntax to the html > rendering of the manual? When using an editor I like some color highlighting, as long as I can control the colors. Documentation is very different, especially since the user probably wouldn't have any control over the colors. The examples in the links above are very hard for me to read, and definitely *not* something I would want in the documentation. There might be room to do something limited and subtle, like maybe making comments a dark gray while other text is black or possibly making computer-generated output very dark blue versus black for user input. It should be subtle enough not to draw attention to it, but rather to give subtle cues. If the display screams "HEY! LOOK HERE!" about anything, it's just wrong. Overall, I'm dubious about whether it would be worth the effort, even if you can come up with a scheme which people like. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] boolean states
Jack Douglas wrote: > There are two kinds of people on this earth, those who understand > boolean arithmatic and those who don't. I'm not one of them. Hmmm... From that, I don't know if you do. Which do I record in the understands_boolean column of the database record for you? Dang, I knew I should have had *two* flags: known_to_understand_boolean and known_to_not_understand_boolean. That would have been much simpler than allowing NULL for UNKNOWN -Kevin "When you come to a fork in the road, take it." -Yogi Berra -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] please unsubscribe me
Peter Eisentraut > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-docs Ferdian Zaman wrote: > Did you try visiting the web page mentioned in the post to which you replied? If so, did you have a problem unsubscribing? If so, please describe what happened so we can fix it. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] ECPG, sentence not complete
Satoshi Nagayasu wrote: > I think it should be rewritten as following: > - > If the query returns more than one records, multiple linked > SQLDA structures are returned, and desc_next > holds a pointer to the next element (record) in the list. > - "more than one records" isn't right -- it could be "multiple records" or "more than one record". -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] 7.2. Table Expressions FULL join is only supported with merge-joinable join conditions
Robert Haas wrote: > Grzegorz Szpetkowski wrote: >> "The join condition specified with ON can also contain conditions >> that do not relate directly to the join." I think the trouble starts with that sentence, which I believe to be completely false and misleading. Simplifying a real-life instance of such confusion among our programmers: SELECT , Demographic.dob FROM Party LEFT JOIN Demographic ON ( AND Demographic.dod is NULL); Which makes absence of date of death part of the outer join criteria. So you get all the parties, dead or alive; and only show date of birth for those not known to be dead. What they really wanted to do was exclude parties known to be dead, and for those parties listed, show date of birth if available. So they wanted: SELECT , Demographic.dob FROM Party LEFT JOIN Demographic ON () WHERE Demographic.dod is NULL; Conditions in the ON clause *do* relate to the JOIN -- it's just that the join might be on conditions other than primary key equality. Let's not contribute to muddy thinking by making incorrect statements like that. > I don't have a clear feeling for exactly what is needed. I think the thing which is most likely to surprise people is that the result can contain rows which are not in the Cartesian product of joining the two relations. We might want to point that out, mention that it's an OUTER JOIN in *both* directions, and maybe give an example which is half-way plausible as a use-case. Maybe something similar to: test=# create table n_en (n int, word text); CREATE TABLE test=# create table n_de (n int, wort text); CREATE TABLE test=# insert into n_en values (1,'one'),(2,'two'); INSERT 0 2 test=# insert into n_de values (2, 'zwei'),(3,'drei'); INSERT 0 2 test=# select * from n_en full join n_de using (n); n | word | wort ---+--+-- 1 | one | 2 | two | zwei 3 | | drei (3 rows) And that works to show the difference between: test=# select * from n_en full join n_de test-# on (n_en.n = n_de.n and n_de.n > 2); n | word | n | wort ---+--+---+-- 1 | one | | 2 | two | | | | 2 | zwei | | 3 | drei (4 rows) and: test=# select * from n_en full join n_de test-# on (n_en.n = n_de.n) where n_de.n > 2; n | word | n | wort ---+--+---+-- | | 3 | drei (1 row) -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] postgres-9.1beta3 typo: recommendable --> recommended
Alvaro Herrera wrote: > Except that we don't use the first person in docs, do we? find doc/src/sgml -name '*.sgml' | xargs cat | egrep -ci '\bwe\b' 786 -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] The translation into Bulgarian
"Albert Ward" wrote: > I am interested in your publication > http://www.postgresql.org/docs/8.1/static/kernel-resources.html > and would like to translate it to Bulgarian language, so I can > share it with the readers on my blog. For doing that I need your > written permission. If you follow the "PostgreSQL 8.1" link at the top of the page you cite, and then the "Copyright" link from there, you will find the permission already granted, with the requirement that the copyright notice accompany your version. http://www.postgresql.org/docs/8.1/static/LEGALNOTICE.html It is odd that you would be looking at version 8.1, though. That is no longer a supported version. http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy Perhaps you should consider the latest released version: http://www.postgresql.org/docs/9.0/static/kernel-resources.html or the soon to be released version: http://www.postgresql.org/docs/9.1/static/kernel-resources.html -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] coalesce
Henry Drexler wrote: > "If the results of the first argument are null, it will return the > second." Unless the second is also null, in which case it will return the third. Unless the third is also null... The trick is to come up with language which recognizes that there can be any number of arguments. Personally, I think the existing language does a good job of that, and is pretty clear. > so I made this example that makes sense: > > COALESCE(column,substitute value) Perhaps a two-argument example would be helpful, as long as it doesn't mislead people into thinking the construct is limited to two arguments. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Cannot build docs on Ubuntu 10.04?
Josh Berkus wrote: > What packages and versions do I need to install to build the docs > on Ubuntu? > > I tried 10.04's version of Openjade, which wasn't recognized > Requirements for building the docs are not documented in our docs. I did find that getting the doc build going was a bit fussy, even after reading the docs on it: http://www.postgresql.org/docs/current/static/docguide.html There were recently some posts that helped me clear up a lot of warnings I was getting, which basically boiled down to the need to install the opensp package. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Invalid sequence for encoding UTF8 0xe86974
"Holec, JPH Software" wrote:
> pg_read_file('pg_log... gives me this report and 0xe86974 doesn't
> know Google...
It would be an odd web page which listed all the values which are
not valid as character encodings in any particular encoding scheme.
> Can You help me?
Questions like this belong on the pgsql-general list; this one is
for discussions about documentation.
> PG 8.4.9 on Windows, database UTF8 and client also Windows... and
> except pg_read_file everything works fine...
You are trying to read a file as text, which is character based.
You are using UTF8 and the file contains data which is not a valid
UTF8 code point.
-Kevin
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] postgresql manuals
antonio guerra wrote: > why all postegresql manuals are not readible? > If I try to open it it says me "file is corrupted and it is > impossible to repair it". What URL(s)? -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] postgresql manuals
[Please keep the list copied.] > antonio guerra wrote: > Il 28/03/2012 22.12, Kevin Grittner ha scritto: >> antonio guerra wrote: >>> why all postegresql manuals are not readible? >>> If I try to open it it says me "file is corrupted and it is >>> impossible to repair it". >> >> What URL(s)? > http://www.postgresql.org/files/documentation/pdf/9.1/postgresql-9.1-A4.pdf > > all .pdf files are not readible. I opened the referenced document with all of these (in kubuntu Linux): xpdf version 3.02 Okular version 0.10.5 Document Viewer 2.30.3 All worked fine. What did you use? Have you checked whether you're using the latest version of whatever viewer you tried? -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] postgresql manuals
antonio guerra wrote: > Il 29/03/2012 14.03, Kevin Grittner ha scritto: >> [Please keep the list copied.] "Reply All" works on most email products. >> antonio guerra wrote: >>> http://www.postgresql.org/files/documentation/pdf/9.1/postgresql-9.1-A4.pdf >>> all .pdf files are not readible. >> >> I opened the referenced document with all of these (in kubuntu >> Linux): >> >> xpdf version 3.02 >> Okular version 0.10.5 >> Document Viewer 2.30.3 >> >> All worked fine. What did you use? Have you checked whether >> you're using the latest version of whatever viewer you tried? > I use a p.c. under windows xp and acrobat reader 8.0. > I updated acrobat to the latest version but it seems me that is > not working yet. I tried Adobe Reader 9 version 9.4.7 and it works fine, including thumbnails and table of contents. What exact version does "Help" -> "About Adobe Reader 9..." show? Maybe a download problem? When I run md5sum against the file, I get: ba50d312b97b222627e75b0aefba91a4 postgresql-9.1-A4.pdf How about you? -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] No such thing as pl/py?
Thom Brown wrote: > I noticed that "pl/py" is listed on the procedural languages page > under external projects, and upon following the link, I can't see any > mention of a procedural language. At the bottom/left corner of the linked page was a link to here: http://python.projects.postgresql.org/backend/ -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] No such thing as pl/py?
Thom Brown wrote: > Kevin Grittner wrote: >> Thom Brown wrote: >> >>> I noticed that "pl/py" is listed on the procedural languages >>> page under external projects, and upon following the link, I >>> can't see any mention of a procedural language. >> >> At the bottom/left corner of the linked page was a link to here: >> >> http://python.projects.postgresql.org/backend/ > > Ah okay. Perhaps it should link to that URL then. I think it should. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Date/Time Types : internals
Florence Cousin wrote: > At the bottom of the page about Date/Time types ( > http://www.postgresql.org/docs/9.1/interactive/datatype-datetime.html > ) > there is this sentence : > > Date conventions before the 19th century make for interesting > reading, but are not consistent enough to warrant coding into a > date/time handler. > > > This sentence seemed very strange to me, and I am not sure to > really understand what it implies (or not) for the user. Could > someone explain that this really means and implies? You can get some idea by reading this page, especially the "Adoption" section: http://en.wikipedia.org/wiki/Gregorian_calendar I guess the point is that for hundreds of years, the same day could have a different date depending which country's calendar you were looking at. I'm not entirely clear why there's a problem if you pick the Gregorian calendar and apply it retroactively. If George Washington was able to adapt to his birthday changing, I think I could deal with it, too: http://www.archives.gov/legislative/features/washington/ II mean, there are still a lot of other calendars in use today, and we don't let that stop us from using the Gregorian calendar. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] "TL;DR:"
[I had a bit of trouble picking which list to use; I guess Wiki pages are part of our docs, in a way...] How do people feel about "TL;DR:" being used at the start of a Wiki page to which we want to direct users? http://wiki.postgresql.org/wiki/Guide_to_reporting_problems I'll go first -- I hate it. Every time I bring up the page before referring a user there, I find that those geeky capital letters in bold screaming at me are distracting and annoying. Since Craig obviously doesn't, I didn't want to just change it without other input. Personally, I think "keep reading" in bold probably covers it. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] "TL;DR:"
> "Kevin Grittner" writes: >> How do people feel about "TL;DR:" being used at the start of a >> Wiki page to which we want to direct users? Tom Lane wrote: > I think it's a pretty lousy way to start off this page in > particular; way too flippant for something we point newcomers to > when they ask for help. +1 for rewriting in a more formal style. "Greg Sabino Mullane" wrote: > Very inappropriate there: remove 'em! I took a shot at reworking the portion ahead of the TOC, but I know there are better wordsmiths than I out there. If anyone wants to redo it, I won't be offended. I have a feeling the "Why were you sent this link?" section is a little harsh, too; but haven't taken a run at that yet. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Behaviour of sql language function
Marcelo Sena wrote: > So, is it documented somewhere? http://www.postgresql.org/docs/current/static/tutorial-transactions.html | PostgreSQL actually treats every SQL statement as being executed | within a transaction. If you do not issue a BEGIN command, then | each individual statement has an implicit BEGIN and (if | successful) COMMIT wrapped around it. Combine this with the fact that a function can only run in the context of a command, like: SELECT func_name(); You have your guarantee -- as long as you understand the possible action of subtransactions (like savepoints). -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Excuse me! Could i to ask a question?
liu...@neusoft.com wrote: > I am a programmer, and i want to use Postgresql 9.2.2 to store my > applications' data. I had to > build a trigger wich based on Database level( When the database startup > , this trigger will fired and > executed.),while i found there are not defined database-level trigger in > postgresql. I read the doc but could > not found methods that could replaced triggers based on database. > Coud you give me a hand? Are there any tables auto update when > postgresql server startup, in this > way i could create a trigger on this table when server startup! It's not entirely clear what you want or why. Do you want this to run when the PostgreSQL cluster (collection of databases running under the control of a single postmaster process) is available for connections, when there is the first connection to the cluster (which creates a backend server process), when there is the first connection to some particular database in the cluster, or for each connection? What sorts of things do you need it to do? What is the problem you are trying to solve? If you want it once per cluster start, the easiest way would be to use a custom service script to stop and start the server, which could run a script. Other timings would need other solutions, but it would help to know what the problem is that you are trying to solve. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Unclear CHARACTER specification
Lyle wrote: > Is there other documentation available that covers this? You might want to read this page: http://www.postgresql.org/docs/9.2/static/storage-toast.html Note that there is seldom a good reason to use char(n) in PostgreSQL for any value of n. As the page you cited mentions, "While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead." Don't try to micro-optimize by breaking what is logically a larger string into 126 character pieces; that will defeat copression, take more space to store, and add processing overhead. In other words, such an attempt will almost certainly backfire. -Kevin -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] ALTER TABLE lock level
Marko Tiikkaja wrote: > On 5/27/13 5:23 PM, I wrote: >> Today I got (unfortunately) reminded that this statement, in >> sql-altertable.html under VALIDATE CONSTRAINT, is not true anymore: >> >> The value of separating validation from initial creation of the >> constraint is that validation requires a lesser lock on the table than >> constraint creation does. > > Since nobody seems to want to pick this up, I'm going to suggest the > following wording: > > The value of separating validation from initial creation of the > constraint is that you can immediately start enforcing the > constraint on all future rows, but delay the validation of > pre-existing data until your database is not under heavy load. That's good as far as it goes, but there's another major reason for wanting the capability. There are cases where, due to dirty converted data or late recognition of the need for a constraint there is existing data which violates the constraint. Being able to add a constraint to protect against creating additional bad data before all the existing problems are cleaned up can be valuable. I know of cases where the old rows which violate the constraint may persist for decades. In a court setting they may care a lot that data on a new and active court case is forced to be correct when entered, but may not feel that it is worth the cost (or in some cases even possible) to determine correct values for cases which are 10 or 20 (or 120) years old. These cases can't be deleted due to records retention laws or relevant court rules, and for a DBA to update them with bogus values to make them comply with the constraint would be not only potentially more misleading than leaving them alone, but would be a felony. > But I'm not going to object to simply removing the entire sentence. I don't know -- it seems like the reasons for the feature are non-obvious enough that such a note is useful. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] pgAmin III 1.18.0 docs.
Barry Gysbers wrote: > I am an experienced database user/programmer. I am absolutely > brand new to PostgreSQL. I just downloaded 9.3.0 on 2013Oct01 > and am finally getting over my reluctance to learn a new system > and taking a look at it. The file was > postgresql-9.3.0-1-windows.exe Welcome to the PostgreSQL world! One of the first things you might want to check out is the page regarding versioning: http://www.postgresql.org/support/versioning/ In PostgreSQL we are very conservative about what goes into a minor release (where the numbers don't change to the left of the second dot); only fixes for security vulnerabilities and serious bugs are considered for a minor release, and conversion of the database is never required. This is so that users can upgrade with minimal risk that anything will be broken by applying the bug fixes. With 9.3.0 you are missing three months worth of bug fixes. I recommend that you grab the latest 9.3 minor release, to avoid finding all the "dot zero" bugs which others have already found and fixed. It generally pays to stay fairly up-to-date as new minor releases become available. > and this email refers to the documentation that came with that > package. > > I started reading the documentation today for pgAdmin III 1.18.0 > as it seems that I must use pgAdmin III in order to get any work > done. While some packagers may include pgAdmin with the PostgreSQL distribution, it really is a separate product. The interface which is included with PostgreSQL is psql, a command-line tool which is very flexible and helpful. It is probably worth trying that out, just so you are familiar with some of what it can do. > I have only read about a dozen pages before becoming > overloaded. With the exception of changing the passworld, I have > no idea what I read means, nor the significance of any of it. I > would think that it would be more helpful to either explain what > you are expected to already know before being able to use the > documentation, or, (more skillfully), put links that explain what > each technical term means, and/or what relevance/consequence each > decision you make has. You may want to start with the documentation for the database product itself before dealing with the docs for a GUI tool to work with the database; that might give the background which would allow the tool's docs to make more sense. http://www.postgresql.org/docs/9.3/static/index.html Of course, that doesn't mean that the pgAdmin docs couldn't be improved; I'm just suggesting it as a way to get the information you want from existing docs. > Mostly, I just wanted to point out that there are an absolutely > incredible number of typos on the very few pages that I have > slogged through so far. > I would be happy to provide at least some editing services as my > contribution to the project, (being absolutely ignorant of > anything actually useful), provided there was some guarantee that > they would actually be implemented or otherwise used. I don't know about an absolute guarantee, but I would be surprised if the committers for pgAdmin would ignore corrections. > I would have to be told exactly how to go about making changes in > a way that would be considered useful. Your best bet would be to download the source code from here: http://www.pgadmin.org/development/git.php ... and submit context diff patches to the pgadmin-hackers list. The pgsql-* lists are not really the right place for discussion or submissions for pgAdmin. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Sample archive_command is still problematic
Josh Berkus wrote: > The example archive_command we give in the docs is this one: > > archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p > /mnt/server/archivedir/%f' > > This is a problematic recommendation. I agree with that statement, ... > If there's any reason why copying the archive file gets > interrupted (storage blip, for example), then the command will > fail and will continue to fail forever, ending archiving. ... but not for that reason. > Is there some good reason why "test ! -f" was added to the > sample? In an environment with more than one cluster archiving, it is otherwise way too easy to copy a config file and have the WAL files of the two systems overwriting one another. I consider a check for an already existing file on the target to be very good practice. The errors in the log are a clue that something went wrong, and gives you a chance to fix things without data loss. The problem with the recommended command is that cp is not atomic. The file can be read before the contents are materialized, causing early end to recovery. I have seen it happen. The right way to do this is to copy to a different name or directory and mv the file into place once it is complete -- or use software which does that automatically, like rsync does. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Sample archive_command is still problematic
Josh Berkus wrote: > On 08/11/2014 10:21 AM, Kevin Grittner wrote: >>> Is there some good reason why "test ! -f" was added to the >>> sample? >> >> In an environment with more than one cluster archiving, it is >> otherwise way too easy to copy a config file and have the WAL files >> of the two systems overwriting one another. I consider a check for >> an already existing file on the target to be very good practice. >> The errors in the log are a clue that something went wrong, and >> gives you a chance to fix things without data loss. > > It depends on what you're guarding against. In the case I was dealing > with, the master crashed in the middle of an archive write. As a > result, the file existed, but was incomplete, and *needed* to be > overwritten. But because of 'test -f' archiving just kept failing. I've seen that happen, too. It's just that the script I used sent an email to the DBAs when that happened, so the problem was quickly investigated and resolved. Also, our monitoring "big board" set an "LED" to red if we went an hour without a new WAL appearing in the archive directory. IMV the archiving script should ensure there is no data loss, and you should have monitoring or alert systems in place to know when things stall. >> The problem with the recommended command is that cp is not atomic. >> The file can be read before the contents are materialized, causing >> early end to recovery. I have seen it happen. The right way to do >> this is to copy to a different name or directory and mv the file >> into place once it is complete -- or use software which does that >> automatically, like rsync does. > > Yeah, realistically, I think we need to start supplying a script or two > in /contrib and referencing that. I'm not sure how to make it work for > the Windows users though. That might work. We should do something, though. The example we give in the docs is not production quality IMO, and is something of an embarrassment. The problem is, it may be hard to get agreement on what that should look like. As a DBA, I insisted on the check for an existing file. I also insisted on having scripts send an email to the DBAs on the first occurrence of a failure (but not to spam us on each and every failed attempt). -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Sample archive_command is still problematic
Peter Eisentraut wrote: > On 8/11/14 6:23 PM, MauMau wrote: > >> I submitted a patch a patch for this a few months ago, which is pg_copy >> listed in the current CF. The patch also addresses the problem that the >> archived file can get lost after power failure because it is not flushed >> to disk. The patch consists of a program called pg_copy which can be >> used instead of cp/copy, and a doc fix to suggest using mv. I made it >> following the favorable suggestions from people. > > I realize that there are about 128 different ways people set this up > (which is itself a problem), but it appears to me that a solution like > pg_copy only provides local copying, which implies the use of something > like NFS. Not necessarily. What I have done is to use the cp/mv technique on the database server and then rsync (through ssh) from each place that needs it. That seems to me much less fragile than copying to an NFS mount point. > Also, I think you can get local copy+fsync with dd. Does the directory entry only become visible to other processes once the file is complete when you use dd? > The alternatives of doing remote copying inside archive_command are also > questionable if you have multiple standbys. Right. It's a nightmare to try to design anything to serve multiple standbys without having the initial archive be local and copying from that archive to the others. At least, if there is some other good solution, I have yet to see it. The above is regarding WAL file archiving -- I'm not putting down streaming replication. Of course, what I would have *really* liked is a WAL receiver that could write out normal-looking WAL files for archiving purposes and pass through the WAL stream to a hot standby. Last I checked (which was admittedly at least a couple years back) there was no such utility, although I seem to remember that Magnus had done some work that looked like it could be bent to that end. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Sample archive_command is still problematic
Magnus Hagander wrote: > On Wed, Aug 13, 2014 at 11:23 PM, Kevin Grittner wrote: > >> The above is regarding WAL file archiving -- I'm not putting down >> streaming replication. Of course, what I would have *really* liked >> is a WAL receiver that could write out normal-looking WAL files for >> archiving purposes and pass through the WAL stream to a hot >> standby. Last I checked (which was admittedly at least a couple >> years back) there was no such utility, although I seem to remember >> that Magnus had done some work that looked like it could be bent to >> that end. > > I did. But I think that has mostly been superceded by replication > slots now. As in, if you use pg_receivexlog with a specific > replication slot, I believe you no longer need archive command at all, > do you? Since the replication slot will block rotation of the WAL > files until they are actually archived by pg_receivexlog (What my > command did was have an archive command that looked back into > pg_stat_replication to see if pg_receivexlog had received the data or > not). > > It did not pass through any WAL stream though - you'd have your > standby connect directly to the same master that pg_receivexlog > connects to. What would be the actual reason for having that one do > the passthrough itself? The use case was to maintain both a hot standby and a set of WAL files to allow PITR recovery (e.g., to recover to just before some catastrophic SQL command was executed) to a remote site across a *slow* WAN connection. Rather than send the WAL across the slow connection twice they would ship and apply WAL files and suffer the consequent replication delay to the hot standby; but if the standby could be done through streaming replication and the WAL files could still be re-created off of the same stream, that would be better. Basically, where bandwidth is limited and expensive, you don't want to have to send the same WAL data over the same connection more than once. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [PATCH] Various documentation typo/grammar fixes
Marti Raudsepp wrote: > I ran the Topy typo-fixer (https://github.com/intgr/topy , using rules > developed for Wikipedia) over the PostgreSQL documentation directory. > Attached is a patch with hand-picked fixes that are clearly an > improvement. > > There are also some changes that I didn't include that seem somewhat > opinionated, for example: > * "eg" -> "e.g." > * "etc" -> "etc." These two seem to me like they should be changed; otherwise they just don't look correct. > * "the exact same" -> "exactly the same" The old version sounds a bit colloquial to my ear, so it seems like it may be worth changing. The problem is, this change doesn't seem like it would generally be a direct substitution; it may require a major reorganization of the sentence. I think the resulting sentences need to be compared to see which is more clear and concise. > * "newly-received" -> "newly received" > * "recently-used" -> "recently used" I think these depend on context. To me, the former scans better when the combination of words is used as an adjective. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [PATCH] Various documentation typo/grammar fixes
Marti Raudsepp wrote: > I ran the Topy typo-fixer (https://github.com/intgr/topy , using rules > developed for Wikipedia) over the PostgreSQL documentation directory. > Attached is a patch with hand-picked fixes that are clearly an > improvement. For the initial patch, I agree with all except the first change of "others'" to "other's" -- the start of the sentence uses "All", so there is clearly more than one "other", so the the apostrophe belongs after the "s". The rest of the 0001- patch all look like improvements to me. I think most or all of the places that the 0002- patch (i.e. and e.g.) need a change to look right, but I'm not sure this goes far enough. In style guides I've had to use these generally should follow punctuation (left parenthesis, colon, semi-colon, comma, or em dash), and be separated from any following text by punctuation -- usually a comma. In patch 0003- I agree that the change to "exactly the same" reads better. I'm torn on changing the hyphens to spaces. I probably wouldn't change them, but I wouldn't squawk if others preferred to do so. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [PATCH] Various documentation typo/grammar fixes
Marti Raudsepp wrote:
> Kevin Grittner wrote:
>> For the initial patch, I agree with all except the first change of
>> "others'" to "other's" -- the start of the sentence uses "All", so
>> there is clearly more than one "other", so the the apostrophe
>> belongs after the "s".
>
> Not arguing against this, but all the grammar advice I've read
> suggests that "each others' " is always wrong. For example
> http://jakubmarian.com/each-others-vs-each-others-in-english/
Hmm. I checked with the Chicago Manual of Style, which is my
preferred source, and it agrees that "each others'" is always
wrong. More than that, it says that traditionalists use "each
other" when exactly two are involved and "one another" when more
than two are involved. So to be totally proper, that instance of
"each others'" should be "one another's". ("One anothers'" is also
always wrong.)
>> I think most or all of the places that the 0002- patch (i.e. and
>> e.g.) need a change to look right, but I'm not sure this goes far
>> enough. In style guides I've had to use these generally should
>> follow punctuation (left parenthesis, colon, semi-colon, comma, or
>> em dash), and be separated from any following text by punctuation
>> -- usually a comma.
>
> This matches my research too. I wrote two rules to add commas where no
> punctation was being used:
> Attached is the updated 0002 patch. I skimmed over all the differences
> and they looked good to me, but with 124 more lines touched, it's
> possible that I missed something.
I'll need a little more time to digest all of those in detail, too.
It sounds like we agree. Where a couple occurrences of "etc" are
being to abbreviate a code example we might have a special case, but
otherwise these are likely to all be the way I'm used to seeing
them.
>> In patch 0003- I agree that the change to "exactly the same" reads
>> better. I'm torn on changing the hyphens to spaces. I probably
>> wouldn't change them
>
> Agreed. I'll move the "exactly the same" hunk to patch 0001 once
> we settle the "each other" question.
Sounds like a good idea. Each patch file is then dealing with a
distinct set of issues.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [PATCH] Various documentation typo/grammar fixes
Marti Raudsepp wrote: > All updated patches attached, per our previous discussion. > Patches 1-2 are ready, 3 can be discarded unless someone else > chimes in. Patch 1 pushed, with each fix back-patched as far as the error exists in supported releases. I held off on patch 2 -- partly because I spotted at least one case where things weren't quite right, partly because there's so much I haven't had time to go over it in sufficient detail, and partly because commas are omitted so consistently where most style guides want them that I thought someone might want to argue that this was an intentional style choice and should be preserved. I'm also not sure that it should be back-patched as the outright errors were -- it does seem like more of a style issue than most of the things in patch 1 were, which included clear misspellings, accidentally repeated words, and incorrect choices of indefinite articles. The remaining error I mentioned above was an occurrence of a parenthetical remark which started with "e.g.," and ended with ", etc."). The Chicago Manual of Style says that you can use one or the other, but using both is redundant and should be avoided. > Do you think it's worth doing a run over developer documentation > (README files) and code comments too, or is that a waste of time? Some README files could use a lot of attention; I'm just not sure that fixing a few misspelling, repeated words, or grammar errors makes enough of a dent in what is needed to be worth it. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [PATCH] Various documentation typo/grammar fixes
Alvaro Herrera wrote: > One reasonably-serious page ... and with that, I guess you've expressed a reasonably clear preference. ;-) -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [PATCH] Various documentation typo/grammar fixes
Marti Raudsepp wrote: > On Sat, Aug 30, 2014 at 8:43 PM, Tom Lane wrote: >> I would argue against applying patch 2 at all. > > I don't feel strongly about this, I originally didn't plan to submit > this patch at all. But I don't agree with: > >> doing it only because some style guide tells >> you to is not the way to approach the issue. We're writing English >> not C code here, and so there is no single standard of correctness. > > There isn't a "single standard", but there are many style guides > about > English and pretty much all of them agree on the usage of periods in > "e.g.", "i.e.", "etc." and "et al." To me, omitting the dots in any of those looks like a misspelling. I think we should fix those. Also, it seems odd to so strictly enforce formatting rules in C code (where it makes no semantic difference) but blow off style issues, and even correctness of English usage, in the documentation. > With regards to commas following e.g. and i.e., this article surveyed > 6 different English style guides and just 1 recommended not using the > > comma: http://www.quickanddirtytips.com/education/grammar/ie-versus-eg?page=2 Commas after "i.e." and "e.g." are less clearly a correctness issue and getting more into style questions, so I wouldn't feel too bad about letting those go where it doesn't cause confusion or too much of a "double take" on reading. Note that the cited page summarizes the positions of these documents on the topic with phrases like "is usually used", "preferable/optional", "makes good sense", and "should be". Only "The Columbia Guide to Standard American English" actually said it was "required". Starting a parenthetical clause with "e.g." and ending it with ", etc." also looks wrong to me. My inclination is to pick one; otherwise I find it distracting or confusing and tend to go back over it one or two extra times to make sure I'm understanding. There's at least one place I spotted "e.g." where it seemed to me that the "example" was really a restatement in other terms, so it seemed like it should have been "i.e." -- I would be inclined to scan for more of those and present that as a separate patch, since it's less mechanical than the others. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] how do I suggest a small docs change?
J Connolly wrote: > I still think being on github would lower the barrier to entry > for would-be contributors I'm not sure whether you're unaware of the github mirror or want something different: https://github.com/postgres/postgres -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Add a new table for Transaction Isolation?
serializable execution.” The prominence of the table | compared to this extra proviso leads to a common misconception | that disallowing the three phenomena implies serializability. ... and later observes: | It would have been simpler [...] to drop [references to phantom | reads] and just use Subclause 4.28 to define ANSI SERIALIZABLE. I tend to agree. Not only would it have been simpler, I think it would have prevented a lot of misunderstanding of the requirements of the standard. Tables like this can do a lot more to promote confusion and misunderstanding than clarity. If we're going to make a change here, I think rather than doubling down on the standard's questionable inclusion of such a table by providing *two* tables, we should consider removing the existing table. > Then why not sure write the entire section relative to the > standard and point out the differences between the standard and our > implementation on the command definition page in the compatibility > section? Many people don't have access to the standard, the standard is confusing to many, and the standard is specifically written to specify minimum required behaviors rather than anything that is dependent on implementation. The standard does not say that the READ UNCOMMITTED transaction isolation level allows other transactions to see the uncommitted work of a transaction; it merely says that no other transaction isolation level may do so. The same is true with all the phenomena -- our implementation does not "differ" from the standard on those points; it is in full compliance with it. > Otherwise, a summary table describing our implementation seems > like a self-evident need. We are already going to great lengths to > describe everything in the table anyway and we already are using a > table to describe the standard's definitions. Placing said table > here seems easiest and if summarizing what is already present in > the text somehow makes the section more confusing I posit that it > must already be confusing without the table. At least this way the > confusing stuff is summarized and is readily available for lookup > by those who know what they are looking for. But the table, by its nature, does not provide the full set of information, and too many people just look at the table because "it's easy". The question seems to me to be whether providing an easy way to get an inaccurate understanding of the topic has value; I submit that the confusion caused by the table in the standard (in spite of a note immediately after the table to try to prevent that) shows that it is not. > Two separate patches here: > > 1) pointing out that additional information is available on the > wiki and the internet That and/or bringing in one or more of the Wiki example. > 2) summarizing the PostgreSQL implementation into a table similar > to that already present for the Standard > > #2 can be implemented in the MVCC section or a more extensive patch > can also update the SQL command SET TRANSACTION section - which > will mean someone feels strongly enough that the status quo is > better than updating MVCC while waiting for someone to write the > more invasive patch. And, for reasons given above, I really question whether such a table doesn't do more harm than good. Even those citing the paper by Berenson, et al., often miss the text in *that* paper about what the actual definition of serializable transactions in the standard is, and instead focus on the quick-to-read tables of how the misinterpretation of serializable transactions based on the standard's table of phenomena (which the paper dubs "ANOMALY SERIALIZABLE") differs from truly serializable behavior. People do love tables like this, which makes providing them tempting; but when a short, clean table is available they often seem less inclined to take the trouble to read the real information the table summarizes -- and they come away with distorted and incorrect ideas about the subject matter. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Add a new table for Transaction Isolation?
Bruce Momjian wrote: > On Sat, Apr 25, 2015 at 11:33:36AM -0700, David G. Johnston wrote: >> Need to add "Serialization Anomalies" to the previous section's >> definitions list. > > Uh, I am afraid the problem is that "Serialization Anomalies" is > kind of defined by the standard in an odd way that is specific to > serializable mode, I think. Kevin, is that true? They never use the word anomaly (or its plural) in the standard (even though it is prevalent in the academic literature). See my earlier email for examples of how the standard describes the issue, but basically it just boils down to saying that the effects of concurrent execution of a set of serializable transactions must be consistent with some one-at-a-time execution order. We could perhaps have the column header say "Non-Serializable Behavior" or some such; but I think we need to define whatever term we use for the new column header. >> Pondering whether something like: "Possible (not in PG)" and >> avoiding the additional rows would make reading the table >> easier. > > Uh, that's an idea. I thought visually having two separate lines > was cleaner. I think one row per transaction isolation level, with three possible values per cell, would be the cleanest. I have been trying to think of alternatives for the three values, but have not come up with anything better than David's suggestion. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Add a new table for Transaction Isolation?
Bruce Momjian wrote: > On Sat, Apr 25, 2015 at 07:45:35PM +0000, Kevin Grittner wrote: >> We could perhaps have the column header say "Non-Serializable >> Behavior" or some such; but I think we need to define whatever >> term we use for the new column header. > > I don't think we can define the column as a negative, e.g. > "Non-". Yeah, that would tend to add to confusion. The basic issue is whether there are any one-at-a-time orders of execution that could yield the same results, or whether there is a cycle in an attempt to graph such an order. "Cycles in Apparent Order of Execution" would be accurate, but it's kinda long, and possibly too arcane. >>>> Pondering whether something like: "Possible (not in PG)" and >>>> avoiding the additional rows would make reading the table >>>> easier. >>> >>> Uh, that's an idea. I thought visually having two separate >>> lines was cleaner. >> >> I think one row per transaction isolation level, with three >> possible values per cell, would be the cleanest. I have been >> trying to think of alternatives for the three values, but have >> not come up with anything better than David's suggestion. > > Well, then "Possible" would refer to the SQL standard behavior, > which seems kind of an odd thing to emphasize there. The field > really needs to be "SQL-standard possible, PostgreSQL not > possible", but that is too long. This is why I split it into > separate lines. We could try "Possible (SQL standard), Not > possible (PostgreSQL)". Yeah, I was searching for some wording that conveyed that the standard *allowed* an implementation to present such phenomena at the isolation level versus whether the PostgreSQL implementation could *actually* present such phenomena. In struggling to come up with an analogy, the best I can do is that it's like each person fishing for rainbow trout in Wisconsin is *allowed* to keep it if it is at least 26 inches long; some people will do so, and some catch and release. Regulations say that it is possible to keep it (and not be in violation of the rules), but you are not required to keep it. For REPEATABLE READ, the SQL standard says that any product would be *allowed* to have phantom reads, but is not *required* to; we, as a community, choose not to. Maybe something like "Prohibited", "Allowed but not Possible", and "Possible"? That would take a little explaining above, since our documentation's table would be deviating from the standard's table in its word choice. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Add a new table for Transaction Isolation?
Bruce Momjian wrote: > I went with "Allowed, but not in PG" for those two fields, and > removed the extra rows I had added. You can see the output here: > > http://momjian.us/expire/transaction-iso.html Looks great! The only suggestion I can think to make to the table itself is to make the new column header singular, to match the other columns. I do think we should define the term used in the new column header; maybe something like this: serialization anomaly The result of successfully committing a group of transactions is inconsistent with all possible orderings of running those transactions one at a time. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Add a new table for Transaction Isolation?
Bruce Momjian wrote: > updated: > > http://momjian.us/expire/transaction-iso.html I can't think of any way to improve on that. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Confused by example in 13.2.2
Dmitry Igrishin wrote: > I'm confused a bit by example in 13.2.2: In current docs that is the "Repeatable Read Isolation Level" section. > "For example, even a read only transaction at this level may see a > control record updated to show that a batch has been completed but > not see one of the detail records which is logically part of the batch > because it read an earlier revision of the control record." > > Could anyone clarify this example? And what is "control record"? Yeah, that sentence doesn't really have enough context. There was discussion around this example in the Wiki: https://wiki.postgresql.org/wiki/SSI#Deposit_Report ... and with that fresh in everyone's memory it seemed to make sense at the time. Would this change make it clear to you?: "For example, you might have a workload involving batches, with a control table having a record to describe the state of each batch and another table with the detail; a read only transaction at this isolation level could see a control record updated to show that a batch has been completed but not see one of the detail records which is logically part of the batch because the transaction inserting the detail read an earlier version of the control record." Hopefully the example from the Wiki makes it clear. There has been some discussion about whether to link to the Wiki or bring an example like that into the documentation; but we usually don't link to Wiki pages and the example is somewhat long to include in-line in the documentation. Any thoughts on the best solution to that? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Docs patch for REFRESH MATERIALIZED VIEW lock level
On Sunday, November 1, 2015 7:59 PM, Craig Ringer wrote: > The explicit locking docs mention the lock taken by REFRESH > MATERIALIZED VIEW CONCURRENTLY, but not plain REFRESH MATERIALIZED > VIEW. Patch. Pushed, with minor adjustment. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] COPY options
On Thu, Apr 28, 2016 at 11:58 AM, Andrei M. Eichler wrote: > when one tries to use it as it is from the docs, one gets the following > results: > ERROR: syntax error at or near "force_null" Works for me. Please copy/paste the actual command and the actual, complete error message. https://wiki.postgresql.org/wiki/Guide_to_reporting_problems -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] COPY options
On Fri, Apr 29, 2016 at 10:31 AM, Andrei M. Eichler wrote: > Following the documentation, I wrote this COPY FROM command: > > COPY test_copy FROM '/mnt/disk1/files/test_file.csv' with csv header > delimiter ';' force_null date_column, date_column2, date_column3, > date_column4, date_column5 encoding 'latin1'; The syntax synopsis in the current docs requires parentheses around any options. I was a little surprised that you got it to work at all without them; but then remembered there is older (deprecated and undocumented) syntax that was not ripped out to avoid breaking code which was working before the syntax change in 9.0. To do this per the current documentation (which I would strongly recommend over the old, undocumented, deprecated syntax), try this: COPY test_copy FROM '/mnt/disk1/files/test_file.csv' with ( format csv, header true, delimiter ';', force_null (date_column, date_column2, date_column3, date_column4, date_column5), encoding 'latin1' ); This new syntax was adopted to make it easier to add new options, and to avoid having to define new keywords or reserved words to do so. It's not really a question of whether we should go back to documenting the deprecated syntax, but whether (and when) support for it should finally be ripped out. It was last documented in 8.4. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Repeatable Read Table Reference
On Tue, May 24, 2016 at 3:38 PM, wrote: > In the documentation for Repeatable Read on this page: > > https://www.postgresql.org/docs/current/static/transaction-iso.html > > The documentation says, "This is a stronger guarantee than is required by > the SQL standard for this isolation level, and prevents all of the phenomena > described in Table 13-1." > > Since the Serialization Anomaly was added to the table in this commit > (https://github.com/postgres/postgres/commit/23c33198b961f27c80655a7cf439d49ef5a1833d#diff-a85793bf153f1f44870606f9695bc33c), > that statement is no longer true if I understand the documentation > correctly. Here's a brief patch to tweak that sentence. Pushed. Thanks! -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Typo.
On Tue, Jun 7, 2016 at 6:26 AM, Dmitry Igrishin wrote: > In "Internal position: this is defined the same as the P field, but it > is used when the cursor position refers to an internally generated", > "internally generated" should be replaced with "internally-generated". Not according to, for example, the Chicago Manual of Style: http://www.chicagomanualofstyle.org/16/images/ch07_tab01.pdf (See the "adverb ending in ly + participle or adjective" category.) I'm pretty sure that this has been discussed on this list before and decided in favor of omitting the hyphenation in such cases. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Typo.
On Tue, Jun 7, 2016 at 8:22 AM, Dmitry Igrishin wrote: > 2016-06-07 15:44 GMT+03:00 Kevin Grittner : >> On Tue, Jun 7, 2016 at 6:26 AM, Dmitry Igrishin wrote: >> >>> In "Internal position: this is defined the same as the P field, but it >>> is used when the cursor position refers to an internally generated", >>> "internally generated" should be replaced with "internally-generated". >> >> Not according to, for example, the Chicago Manual of Style: >> >> http://www.chicagomanualofstyle.org/16/images/ch07_tab01.pdf >> >> (See the "adverb ending in ly + participle or adjective" category.) >> >> I'm pretty sure that this has been discussed on this list before >> and decided in favor of omitting the hyphenation in such cases. > Hm, well, how about removing hypenation from > "Internal query: the text of a failed internally-generated command", > "procedural language functions and internally-generated queries", > at https://www.postgresql.org/docs/9.6/static/protocol-error-fields.html > and similar in other places? I think we should be consistent, especially on adjacent lines. Oddly, a single commit 12 years ago used both in close proximity. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Regarding Overcommit
On Mon, Jun 13, 2016 at 2:00 AM, wrote: > Documentation says: > > sysctl -w vm.overcommit_memory=2 > > "it will lower the chances significantly and will therefore lead to more > robust system behavior." > > This statement in documentation is Wrong. > > This is not recommended for production environments, because if an > out-of-memory condition does present itself, there could be unexpected > behavior. It is wrong for some types of production environments, but for a server where the only (or primary) service is PostgreSQL it is absolutely Right. Without this, an out-of-memory condition which cancels any database process causes a crash and restart of all connections without necessarily giving any useful clues as to the cause of the crash. With vm.overcommit_memory = 2 it will generally yield an error on only the one connection causing the problem, and provide a detailed dump of memory contexts (with allocated space in each). Other connections are generally unaffected and the cause of the problem can be fixed to prevent recurrence. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Documentation for pgp_pub_decrypt
On Sun, Sep 25, 2016 at 4:55 AM, wrote: > I believe the first argument [apparently of pg_sym_decrypt() and > pg_pub_decrypt()] should be of type 'text'. Especially > considering the paragraph that follows discusses how passing in > bytea is disallowed. The *encrypted* form is bytea; those functions *return* text and are thus not a good way to get back to unencrypted bytea data; an additional transformation would still be required to get to the byte format from text, and the bytes representing those character strings would depend on the character encoding. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] SET CONSTRAINTS ALL IMMEDIATE affects SET TRANSACTION READ ONLY
On Mon, Oct 10, 2016 at 7:59 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 9/9/16 12:39 PM, Tom Lane wrote: >>> I wouldn't really imagine that it's sensible to set READ ONLY >>> mid-transaction at all, but if it means anything to do that, surely >>> it ought to mean that no updates can happen *after* you set it. > >> I think there is a bit of code missing in check_transaction_read_only(). >> We prevent changing from read-only to read-write after the first query >> but not vice versa. That seems like an oversight. > > The comments around the code make it absolutely clear that it's > intentional, not an "oversight". Whether it's a good idea is open > for discussion, certainly, but I don't see how you can imagine that > it wasn't considered. I seem to remember that the current state of affairs evolved near the end of 9.1 development, when it surfaced that this GUC could be changed at will during a transaction and that made some nice SSI optimizations impossible. If memory serves, Tom preferred that we not lose the ability to change from READ WRITE to READ ONLY within a transaction, and that wasn't hard to accommodate (we capture the state of the flag at the start of a serializable transaction and use that for determining serializable optimizations), so I didn't really care. I don't remember anyone arguing against this way at the time. Current behavior seems harmless and possibly useful to me, but it seems marginal enough I wouldn't care if the change from READ WRITE to READ ONLY was also prohibited. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Missing important information in backup.sgml
On Wed, Nov 23, 2016 at 12:24 PM, Gunnar "Nick" Bluth wrote: > mentions Stephen's > remarks on rsync (although to get actual _data loss_, you'd have to have > a power outage in the DC caused by your PG server exploding... ;-). I have seen power loss between the UPS and a server; including a tech tripping on the power cord. I have also seen servers abruptly shut down due to high temperatures in spite of having a UPS. I have also seen an OS bug lock up a system such that it was impossible to get a clean shutdown before having to cycle power to recover. No explosion needed. If you value the data in your database you should assume that the OS could go down at any instant without proper shutdown, and that your storage system(s) could be lost without warning at any time. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Missing important information in backup.sgml
On Wed, Nov 23, 2016 at 2:12 PM, Gunnar "Nick" Bluth wrote: > Am 23.11.2016 um 20:21 schrieb Kevin Grittner: >> On Wed, Nov 23, 2016 at 12:24 PM, Gunnar "Nick" Bluth >> wrote: >>> to get actual _data loss_, you'd have to have a power outage in >>> the DC caused by your PG server exploding... >> If you value the data in your database you should assume that the >> OS could go down at any instant without proper shutdown, and that >> your storage system(s) could be lost without warning at any time. > I've been in this business for 15 years, and had my share of outages. > [enumeration of various failure modes and their respective impacts] I have seen multiple posts on these lists where people say that they don't need to worry about data written to the OS failing to make it to storage because they a really good UPS. It sounds like you understand that, as important as it is to have a UPS, it does not preclude abrupt equipment failure; but I fear that the statement you made might reinforce that notion in some quarters. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [HACKERS] Questionable tag usage
On Tue, Jan 10, 2017 at 9:58 AM, Tom Lane wrote: > whether to continue using "see section m.n"-type cross-references For my part, I have a preference for including the section name with the link text, although if it took much work to add it (rather than being the new default) I might question whether the benefit was worth the effort of adding it. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
