[DOCS] Ways to improve PgAdmin III SQL context help
Hello All! Currently when I press F1 in the SQL Query window, PgAdmin III looks for first token of selected (or whole) text, recognizes most of SQL commands and tries to open corresponding help page. I tried to extend that list with data types, functions, system catalogs&views etc: https://github.com/jinfroster/pgadmin3/commit/6e70b9f2252ec22e22c4188d5cfe0cf18e6ce7a2 Yeah, quite a stupid way :) but after a week of testing it (writing queries and pl/pgsql), I have a positively pleasant experience, even that is really helpful! Which way is better? IMO it is reasonable to index whole Postgre's actual doc/src/sgml/*.sgml in a separate PgAdmin's build target and bundle fresh index file with every release of PgAdmin. Branded distributions could use same workflow if their documentation inherits same SGML. Index file should contain: - Keywords to be searched, collected from several DocBook tags like , , etc - about 15 of them are most informative. - Locations (Page, Anchor, Title), collected from , etc. - Weights (keyword K in location L has weigth W). W(K,L) = sum(Nklt * Wt), where Nklt is number of occurences of keyword K in location L in tag T Wt is weight for tag T (say, is 1, but is 1 etc). So a user can get most relevant Page#Anchor instantly for a word under cursor, or a sorted list of pages to choose from (Title will be useful here). Currently my questions are: 1. Is such development interesting to the community? 2. Is supposed workflow for index bundling acceptable? 3. May be, some ready-made open source solution can be used for indexing DocBook SGML and later searching? It's searching engine is to be incorporated into PgAdmin. I'd like to work on subject and look for any constructive opinions. Thanks! -- Best regards, J.F. -- 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] Links for upgraders
On Mon, 2014-01-20 at 16:42 +0100, Vik Fearing wrote: > I believe to have addressed your concerns in this new patch. I did > not > do "make postgres.txt" on the previous version, but I did do it on > this > one and it looks okay to me. I think it would be even better to link directly to the migration notes, not to the top-level section of the release notes. I suggest to add a link target like Migration to Version 9.2.4 and then link to that. -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] PATCH: Warn users about tablespace abuse data loss risk
Hi all I've just seen another case of data loss due to misuse of / misunderstanding of tablespaces: http://dba.stackexchange.com/questions/58704/how-do-i-access-a-old-saved-tablespace-after-reinstalling-postgres and it's prompted me to write some docs amendments to make it more obvious that *you shouldn't do that*. Not that it'll stop people, but it'll at least mean they can't say we didn't warn them. This is actually quite important, because many users are used to MySQL's MyISAM, where each table contains its own metadata and is readable by simply copying the table into a different MySQL install's data directory. It doesn't even have to be the same version! Users are clearly surprised that PostgreSQL tablespaces don't have the same properties. Thoughts? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services >From 6d0abd7bcaca596ac2298d8f7ac408e465ec1aef Mon Sep 17 00:00:00 2001 From: Craig Ringer Date: Wed, 12 Feb 2014 11:48:23 +0800 Subject: [PATCH] Warn about risks of tablespace misuse --- doc/src/sgml/manage-ag.sgml | 17 + doc/src/sgml/ref/create_tablespace.sgml | 10 ++ 2 files changed, 27 insertions(+) diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml index b44d521..dd43e19 100644 --- a/doc/src/sgml/manage-ag.sgml +++ b/doc/src/sgml/manage-ag.sgml @@ -379,6 +379,23 @@ dropdb dbname expensive, slower disk system. + + +Tablespaces are not suitable for backup/redundancy. +If the main database cluster is lost, tablespaces cannot simply be reattached +to a different database cluster, the metadata from the original is required +to read the tablespace. Similarly, if you lose a tablespace (deletion, +disk failure, etc) the main database may become unreadable or fail to start. + + + +Do not attempt to use tablespaces to transfer tables between database +clusters, for backup and restore, or to partition your data based on +the reliability of the storage it is on. Never put a tablespace +on a ramdisk or temporary file system. + + + To define a tablespace, use the diff --git a/doc/src/sgml/ref/create_tablespace.sgml b/doc/src/sgml/ref/create_tablespace.sgml index 04c5fb8..83edd88 100644 --- a/doc/src/sgml/ref/create_tablespace.sgml +++ b/doc/src/sgml/ref/create_tablespace.sgml @@ -50,6 +50,16 @@ CREATE TABLESPACE tablespace_name CREATE INDEX or ADD CONSTRAINT to have the data files for these objects stored within the specified tablespace. + + + +You can't use the contents of a tablespace without the database it's part of, +nor can you use the main database if a tablespace is missing. Don't try to +use tablespaces for backup or redundancy. +See . + + + -- 1.8.3.1 -- 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: Warn users about tablespace abuse data loss risk
2014-02-12 12:52 GMT+09:00 Craig Ringer : > Hi all > > I've just seen another case of data loss due to misuse of / > misunderstanding of tablespaces: > > http://dba.stackexchange.com/questions/58704/how-do-i-access-a-old-saved-tablespace-after-reinstalling-postgres > > and it's prompted me to write some docs amendments to make it more > obvious that *you shouldn't do that*. > > Not that it'll stop people, but it'll at least mean they can't say we > didn't warn them. > > This is actually quite important, because many users are used to MySQL's > MyISAM, where each table contains its own metadata and is readable by > simply copying the table into a different MySQL install's data > directory. It doesn't even have to be the same version! Users are > clearly surprised that PostgreSQL tablespaces don't have the same > properties. > > Thoughts? People still use MyISAM!? I had a similar issue pop up at work a while back, having something explicit to point to is definitely a good idea. Suggestion for the first paragraph of the patch (sorry I can't provide it in patch form right now): Even if they are located outside the main PostgreSQL data directory, tablespaces are an integral part of the database cluster and cannot be treated as an autonomous collection of data files. They rely on metadata contained in the main data directory, without which they are useless. In particular, tablespaces cannot be reattached to a different database cluster, and backing up individual tablespaces makes no sense as a backup/redundancy method. Similarly, if you lose a tablespace (file deletion, disk failure, etc) the main database may become unreadable or fail to start. Regards Ian Barwick -- 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: Warn users about tablespace abuse data loss risk
Ian Lawrence Barwick wrote > 2014-02-12 12:52 GMT+09:00 Craig Ringer < > craig@ > >: >> Hi all >> >> I've just seen another case of data loss due to misuse of / >> misunderstanding of tablespaces: >> >> http://dba.stackexchange.com/questions/58704/how-do-i-access-a-old-saved-tablespace-after-reinstalling-postgres >> >> and it's prompted me to write some docs amendments to make it more >> obvious that *you shouldn't do that*. >> >> Not that it'll stop people, but it'll at least mean they can't say we >> didn't warn them. >> >> This is actually quite important, because many users are used to MySQL's >> MyISAM, where each table contains its own metadata and is readable by >> simply copying the table into a different MySQL install's data >> directory. It doesn't even have to be the same version! Users are >> clearly surprised that PostgreSQL tablespaces don't have the same >> properties. >> >> Thoughts? > > People still use MyISAM!? > > I had a similar issue pop up at work a while back, having something > explicit to point to is definitely a good idea. > > Suggestion for the first paragraph of the patch (sorry I can't provide it > in > patch form right now): > > Even if they are located outside the main PostgreSQL data directory, > tablespaces > are an integral part of the database cluster and > > cannot > > be > treated as an autonomous collection of data files. They rely on > metadata contained > in the main data directory, without which they are useless. In > particular, tablespaces > cannot be reattached to a different database cluster, and backing up > individual > tablespaces makes no sense as a backup/redundancy method. Similarly, > if you lose a > tablespace (file deletion, disk failure, etc) the main database may > become unreadable > or fail to start. > > Regards > > > Ian Barwick While providing additional warnings is good and necessary it may also help to be more descriptive as to in what situations tablespaces are appropriate and/or necessary so that people leave with a better understanding of why the feature exists and not just trying to know what not to use it for. It goes against the more prescriptive tone of the documentation generally but both approaches work well together to tackle the knowledge/understanding gap some users seem to have. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/PATCH-Warn-users-about-tablespace-abuse-data-loss-risk-tp5791537p5791542.html Sent from the PostgreSQL - docs mailing list archive at Nabble.com. -- 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: Warn users about tablespace abuse data loss risk
2014-02-12 14:06 GMT+09:00 David Johnston : > Ian Lawrence Barwick wrote >> 2014-02-12 12:52 GMT+09:00 Craig Ringer < > >> craig@ > >> >: >>> Hi all >>> >>> I've just seen another case of data loss due to misuse of / >>> misunderstanding of tablespaces: >>> >>> http://dba.stackexchange.com/questions/58704/how-do-i-access-a-old-saved-tablespace-after-reinstalling-postgres >>> >>> and it's prompted me to write some docs amendments to make it more >>> obvious that *you shouldn't do that*. >>> >>> Not that it'll stop people, but it'll at least mean they can't say we >>> didn't warn them. >>> >>> This is actually quite important, because many users are used to MySQL's >>> MyISAM, where each table contains its own metadata and is readable by >>> simply copying the table into a different MySQL install's data >>> directory. It doesn't even have to be the same version! Users are >>> clearly surprised that PostgreSQL tablespaces don't have the same >>> properties. >>> >>> Thoughts? >> >> People still use MyISAM!? >> >> I had a similar issue pop up at work a while back, having something >> explicit to point to is definitely a good idea. >> >> Suggestion for the first paragraph of the patch (sorry I can't provide it >> in >> patch form right now): >> >> Even if they are located outside the main PostgreSQL data directory, >> tablespaces >> are an integral part of the database cluster and >> >> cannot >> >> be >> treated as an autonomous collection of data files. They rely on >> metadata contained >> in the main data directory, without which they are useless. In >> particular, tablespaces >> cannot be reattached to a different database cluster, and backing up >> individual >> tablespaces makes no sense as a backup/redundancy method. Similarly, >> if you lose a >> tablespace (file deletion, disk failure, etc) the main database may >> become unreadable >> or fail to start. >> > While providing additional warnings is good and necessary it may also help > to be more descriptive as to in what situations tablespaces are appropriate > and/or necessary so that people leave with a better understanding of why the > feature exists and not just trying to know what not to use it for. It goes > against the more prescriptive tone of the documentation generally but both > approaches work well together to tackle the knowledge/understanding gap some > users seem to have. The warning would appear on this page: http://www.postgresql.org/docs/current/static/manage-ag-tablespaces.html which describes what tablespaces *can* do, but unless you're familiar with the structure of the PostgreSQL data directories, it's not obvious what you *can't* do. I recall reading a blog post a while back about tablespaces being "archived" to the cloud with disastrous results, and a quick search pulls up stuff like this: http://stackoverflow.com/questions/3534415/moving-postgres-tablespaces-and-tables-across-ec2-instance so it's definitely not a niche issue. Something "official" to link to would be very useful in this kind of situation. That doesn't preclude the general documentation being improved of course. Regards Ian Barwick -- 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: Warn users about tablespace abuse data loss risk
2014-02-12 15:16 GMT+09:00 Ian Lawrence Barwick : > 2014-02-12 14:06 GMT+09:00 David Johnston : >> Ian Lawrence Barwick wrote >>> 2014-02-12 12:52 GMT+09:00 Craig Ringer < >> >>> craig@ >> >>> >: Hi all I've just seen another case of data loss due to misuse of / misunderstanding of tablespaces: http://dba.stackexchange.com/questions/58704/how-do-i-access-a-old-saved-tablespace-after-reinstalling-postgres and it's prompted me to write some docs amendments to make it more obvious that *you shouldn't do that*. Not that it'll stop people, but it'll at least mean they can't say we didn't warn them. This is actually quite important, because many users are used to MySQL's MyISAM, where each table contains its own metadata and is readable by simply copying the table into a different MySQL install's data directory. It doesn't even have to be the same version! Users are clearly surprised that PostgreSQL tablespaces don't have the same properties. Thoughts? >>> >>> People still use MyISAM!? >>> >>> I had a similar issue pop up at work a while back, having something >>> explicit to point to is definitely a good idea. >>> >>> Suggestion for the first paragraph of the patch (sorry I can't provide it >>> in >>> patch form right now): >>> >>> Even if they are located outside the main PostgreSQL data directory, >>> tablespaces >>> are an integral part of the database cluster and >>> >>> cannot >>> >>> be >>> treated as an autonomous collection of data files. They rely on >>> metadata contained >>> in the main data directory, without which they are useless. In >>> particular, tablespaces >>> cannot be reattached to a different database cluster, and backing up >>> individual >>> tablespaces makes no sense as a backup/redundancy method. Similarly, >>> if you lose a >>> tablespace (file deletion, disk failure, etc) the main database may >>> become unreadable >>> or fail to start. >>> > >> While providing additional warnings is good and necessary it may also help >> to be more descriptive as to in what situations tablespaces are appropriate >> and/or necessary so that people leave with a better understanding of why the >> feature exists and not just trying to know what not to use it for. It goes >> against the more prescriptive tone of the documentation generally but both >> approaches work well together to tackle the knowledge/understanding gap some >> users seem to have. > > The warning would appear on this page: > > http://www.postgresql.org/docs/current/static/manage-ag-tablespaces.html > > which describes what tablespaces *can* do, but unless you're familiar with the > structure of the PostgreSQL data directories, it's not obvious what you > *can't* > do. I recall reading a blog post a while back about tablespaces being > "archived" > to the cloud with disastrous results, and a quick search pulls up > stuff like this: > > > http://stackoverflow.com/questions/3534415/moving-postgres-tablespaces-and-tables-across-ec2-instance > > so it's definitely not a niche issue. Something "official" to link to > would be very useful in this kind of situation. That doesn't preclude the > general > documentation being improved of course. And taking a look at the page in question I see this prominent example: CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data'; As '/mnt' is usually a temporary mount point for detachable media and all that [*] maybe it's not the best impression to give for a suitable tablespace location. [*] http://www.pathname.com/fhs/pub/fhs-2.3.html#MNTMOUNTPOINTFORATEMPORARILYMOUNT "This directory is provided so that the system administrator may temporarily mount a filesystem as needed. " Ian Barwick -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
