[DOCS] Suggestion on reorganizing functions
After some discussion on IRC about improvments that could be made to the documentation I have a suggestion. Note: I don't have much time to work on it and I'm not an sgml-wiz. (Note: Using .html names of things as I don't know what sgml makes what) The basic idea is to make the equivalent of sql-commands.html (A flat list of all SQL commands) but for functions. Usually when I need to go find functions it involves google. The flat list would allow a Joe User to come along and scroll down to find out what FOOBAR() is instead of going to functions.html and trying to decide what type of function FOOBAR is. The organization by category is useful (ie getting all date manip functions) but the flat list would also be quite useful - especially if you are a newcomer to PG and are trying to dissect some code. One idea to solve it would to have the flat list link to functions-foo.html#FOOBAR - this would allow both methods of organization and only having function definitions in one spot. Perhaps there is some other spiffy sgml way of defining the type of function FOOBAR() is inside the sgml? We could have it scan all the little sgml files for functions (ala ref/ files) and automatically make function-TYPE.html files? any thoughts? -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] Suggestion on reorganizing functions
On Aug 9, 2004, at 8:20 PM, Tom Lane wrote: David Fetter <[EMAIL PROTECTED]> writes: I think Jeff's original point was that he wanted some kind of index for all functions, not just ones you already know how to classify. I thought his point was that he didn't fully know how the docs have already classified functions, and therefore didn't know which page to look on to find a given one. This seems a legitimate gripe to me, and one that can be cured with a more complete index. Exactly. or if you are trying to remember a function - say "Oh whats that thing? Colace? Coerce? [scrolls] Ahh! Coalesce!" The trouble seems to be getting that list automatically generated from the existing SGML. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[DOCS] SELinux & Redhat
I think we should put some notes about SELinux causing issues with pgsql in the OS notes or FAQ. Myself and a few coworkers just spent a few hours tracking down why pg_dump would produce no output. We'd fire it up in strace and we'd see all the successful write calls, but not output. We copied pg_dump from another machine and it worked fine, and that machine was running the same OS & pg rpms. Eventually we found it was SELinux was preventing pg_dump from producing output. Any thoughts? I could write up a short blurb but I'm not terribly familiar with selinux. we just disabled the whole thing to make it work. For the record: CentOS 4.0 postgresql-8.0.2-1PGDG.i686.rpm (and associated) rpms from postgresql.org's ftp server -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [DOCS] SELinux & Redhat
On May 6, 2005, at 11:23 AM, Tom Lane wrote:
Jeff - <[EMAIL PROTECTED]> writes:
Eventually we found it was SELinux was preventing pg_dump from
producing output.
That's a new one on me. Why was it doing that --- mislabeling on
the pg_dump executable, or what?
We've got a stock CentOS 4 install
I nabbed the rpms I mentioned (8.0.2) (-rw-r--r-- 1 root root
2955126 May 4 11:51 postgresql-8.0.2-1PGDG.i686.rpm & company)
from /etc/selinux/targeted/contexts/files/file_contexts I see
file_contexts:/usr/bin/pg_dump --
system_u:object_r:postgresql_exec_t
file_contexts:/usr/bin/pg_dumpall --
system_u:object_r:postgresql_exec_t
Syslog logs:
May 6 09:01:25 starslice kernel: audit(1115384485.559:0): avc:
denied { execute_no_trans } for pid=4485 exe=/bin/bash path=/usr/
bin/pg_dump dev=sda3 ino=5272966
scontext=user_u:system_r:postgresql_t
tcontext=system_u:object_r:postgresql_exec_t tclass=file
SELinux is on and under system-config-securitylevel's selinux tab,
"SELinux Protection services" disable postgresql is not clicked.
When I run pg_dump w/these settings the following happens running
pg_dump (.broken is hte original file from the rpm)
bash-3.00$ /usr/bin/pg_dump.broken planet
bash-3.00$
Stracing it I get
write(1, "file_pkey; Type: CONSTRAINT; Sch"..., 4096) = 4096
write(1, "\n-- Name: userprofile_pkey; Type"..., 4096) = 4096
write(1, "_idx_1 OWNER TO planet;\n\n--\n-- N"..., 4096) = 4096
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
send(3, "X\0\0\0\4", 5, 0) = 5
rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_IGN}, 8) = 0
close(3)= 0
write(1, "me: top3_cmtcount_idx; Type: IND"..., 3992) = 3992
munmap(0xb7df, 4096)= 0
exit_group(0) = ?
and what is interesting is it seems only sometimes things get logged
to syslog about the failure.
If I copy the file (not mv) it will work (possibly due to xattrs
being set?)
and if I disable pg checking, (or selinux all together) it works.
COOL, HUH?
--
Jeff Trout <[EMAIL PROTECTED]>
http://www.jefftrout.com/
http://www.stuarthamm.net/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [DOCS] SELinux & Redhat
On May 6, 2005, at 11:57 AM, Tom Lane wrote: bash-3.00$ /usr/bin/pg_dump.broken planet bash-3.00$ Does it work if you direct the output into a file, instead of letting it come to your terminal (which seems a bit useless anyway)? Interesting. Redirecting it worked, but I'm pretty sure at one point it didn't work. (I could also be smoking crack). Hmm.. piping it into another app worked. I only found out about this when another developer here tried to run it and got nothing. in any case, it might be something useful to jot somewhere. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[DOCS] Slow Search
I've noticed that the search function on the docs page appears to be quite slow. Is the problem one of server load, or where does it lie? Is it using postgresql and tsearch2? Is there something I can do to help? I'm concerned that people looking at the database could be getting a bad impression. As a separate issue, I was trying to use the search to find information about "table functions" (functions that return a setof, I'm not sure the terms that the developers use). I usually fund it eventually, but for some reason information about that seems to be hidden to me. Would it be helpful to other people if I included it as a separate heading for pl/pgsql in the sgml docs? Regards, Jeff ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] 7.5 release notes
On Sat, 2004-07-24 at 21:25, Bruce Momjian wrote: > I have completed the 7.5 release notes. You can view them in HTML on > the developer web page. I have marked a few items with question marks > that need to be addressed. I am looking for improvements, even minor > ones. Either send in a patch or committers can modify the file > directly. I don't understand the following passage: "When matching GROUP BY names, prefer local FROM columns first, then SELECT aliases, and then outer FROM columns (Tom) This change was made because it is considered more consistent than the previous behavior." Perhaps it could be more clear? I don't know where else I'd go to find more thorough documentation on that subject. Also, I've included a couple typo fixes below. Regards, Jeff Davis --- release.html.old2004-07-25 03:06:28.0 -0700 +++ release.html2004-07-25 03:10:21.0 -0700 @@ -99,7 +99,6 @@ Before this change some queries would not use an index if the data types did not exactly match. This improvement makes index usage more intuitive and consistent. - match exactly New buffer replacement strategy that improves caching (Jan) Prior releases use a least-recently-used (LRU) cache to keep recently referenced pages in the cache. Unfortunately, the cache @@ -129,7 +128,7 @@ resulting in improved performance. The close relationship between our developers and users reporting problems allows us to make rapid and complex optimizer improvements that would be very - difficult for lose-source companies to emulate. + difficult for closed-source companies to emulate. Improve btree index performance for duplicate keys (Dmitry Tkach, Tom) This improves the way indexes are scanned when many duplicate values exist in the index. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [DOCS] [COMMITTERS] pgsql: Remove replicaiton FAQ item.
Should the text include a mention of synchronous vs. asynchronous? Or does master-master imply synchronous? Regards, Jeff Davis On Sun, 2005-04-24 at 08:01 -0400, Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Tue, 16 Nov 2004, Robert Treat wrote: > > > > > On Sunday 14 November 2004 16:33, Bruce Momjian wrote: > > >> Log Message: > > >> --- > > >> Remove replicaiton FAQ item. > > >> > > >> Modified Files: > > >> -- > > >> pgsql/doc: > > >> FAQ (r1.269 -> r1.270) > > >> > > >> (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/FAQ.diff?r1=1.269&r2= > > >> 1.270) pgsql/doc/src/FAQ: > > >> FAQ.html (r1.227 -> r1.228) > > >> > > >> (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/FAQ.html.diff > > >> ?r1=1.227&r2=1.228) > > > > > > While the answer may have been a little dated, this still seems to be an > > > FAQ. > > > Was there a discussion on removing this? If so I'll go read that, but > > > ISTM > > > this question should remain. > > > > agreed, this definitly does fall under a "Very FAQ" kinda thing ... > > pointers to the various methods that are currently in use, at a minimum, > > would be good ... > > Yep, big mistake my removing the replication FAQ item. I have re-added a > new one: > > 4.21) What replication solutions are available? > > Though "replication" is a single term, there are two major replication > technologies. Multi-master replication allows read/write queries to be > sent to multiple replicated computers. Using this capability has a > serious performance impact. Pgcluster is the most popular such solution > available for PostgreSQL. Master-slave replication allows a single > master to receive read/write queries, with slaves able to accept only > read/SELECT queries. The most popular master-slave PostgreSQL > replication solution is Slony. There are also commercial and > hardware-based replication solutions available. > ---(end of broadcast)--- TIP 8: explain analyze is your friend
[DOCS] broken link on techdocs
I tried to access <http://techdocs.postgresql.org/redir.php?link=http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html> and it says that the connection was refused. However, that's a useful document and I'm not sure it has a replacement. Is this a temporary host server problem, or is that a broken link? Maybe for outside links we should periodically run one of those web crawler things that checks for broken links. It seems unprofessional when we have broken links anywhere on the site. Also, it can alert us to resources that may need to be hosted somewhere more reliably. Regards, Jeff Davis ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] vacuum and routine maintenance docs
On Wed, 18 Jan 2006, Scott Marlowe wrote: Well, I'm kind of tempted to rewrite the whole section. I'd like to come up with some objectives of what we're trying to cover there, and basically start over with all the information that's there plus the other stuff on fsm and mvcc as it applies to vacuum, or link to it as needed. A couple questions I find difficult to answer using the online docs are: * Is my autovacuum doing a good enough job? * What percentage of bloat is reasonable (and how can I tell what my bloat level is)? * What transaction loads would require specific autovacuum settings, or manual vacuum fulls? -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] Proposed doc-patch: Identifying the Current WAL file
On Sat, 15 Apr 2006, Tom Lane wrote: For a command-line solution it's probably sufficient to sort by mtime, ie ls -t | head -1 A while back when I was trying to work this out on the admin list, I believe we came up with the following: ls -tp /pg_xlog/ | grep -v "backup\|/" | head -1 which seems to work fairly well. Looks like that thread is here: http://archives.postgresql.org/pgsql-admin/2005-10/msg00173.php -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] Proposed doc-patch: Identifying the Current WAL file
On Sat, 15 Apr 2006, Bruce Momjian wrote: ls -tp /pg_xlog/ | grep -v "backup\|/" | head -1 which seems to work fairly well. Looks like that thread is here: http://archives.postgresql.org/pgsql-admin/2005-10/msg00173.php What does the -p and \| pipe check do? We don't have named pipes in that directory, do we? Also, what happens if the log switch happens, and some data change is written to the new WAL file in the first second, but nothing happens to the database after that for a minute? Your test would still show the old log file. The -p shows forward slashes after directories and the \| acts as an or and the / following that just lets us filter directories out. I added that because I used to find the archive_status directory winning the ls -t from time to time. Now about your what if question. I don't know if there is a way to get past the mtime granularity. If I understand your scenario correctly, you indicate that the previous log is written to and the new log is switched in during the same mtime second. I did a quick test on linux to see how that operates: touch AA AB This yields both files with the same mtime. ls -tp |head -1 yields AA as you suggested it would. The following seems to do the trick if we can rely on alphabetizing to properly decide the winner of a tie: ls -tp | head -2 | sort -r | head -1 So, with my previous example, it would look like: ls -tp /pg_xlog/ | grep -v "backup\|/" | head -2 | sort -r | head -1 -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] Proposed doc-patch: Identifying the Current WAL file
On Sat, 15 Apr 2006, Tom Lane wrote:
Bruce Momjian writes:
Also, what happens if the log switch happens, and some data change is
written to the new WAL file in the first second, but nothing happens to
the database after that for a minute? Your test would still show the
old log file.
You seem to be assuming that ls will sort on the basis of the truncated
mtime that it displays, which is not the actual behavior of ls AFAIK.
I believe you're correct, at least with the ls I have here on my linux system.
I created two files quickly with touch. Here is the stat output:
File: `AA'
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 802h/2050d Inode: 2736263 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 26/postgres) Gid: ( 26/postgres)
Access: 2006-04-15 11:02:46.0 -0700
Modify: 2006-04-15 11:02:46.0 -0700
Change: 2006-04-15 11:02:46.0 -0700
File: `AB'
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 802h/2050d Inode: 2736264 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 26/postgres) Gid: ( 26/postgres)
Access: 2006-04-15 11:02:48.0 -0700
Modify: 2006-04-15 11:02:48.0 -0700
Change: 2006-04-15 11:02:48.0 -0700
ls -t | head -1
AB
So it looks like the original was correct all along, but with Tom's regex it's
much cleaner. Too bad grep's regex engine doesn't support {24}.
I'll change all my scripts to use the following:
ls -t /pg_xlog/ | grep
'^[0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F]$'
| head -1
Thanks Tom!
--
Jeff Frost, Owner <[EMAIL PROTECTED]>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [DOCS] Proposed doc-patch: Identifying the Current WAL file
On Sat, 15 Apr 2006, Bruce Momjian wrote: Tom Lane wrote: No, I am not: $ touch x1 x2; touch x2 $ sleep 2; ls -lt total 0 -rw-r--r-- 1 root postgres 0 Apr 15 14:04 x1 -rw-r--r-- 1 root postgres 0 Apr 15 14:04 x2 If the write to x2 happens in the first second, but no later writes happen, you still see x1 as first, even though x2 is the new one and might have WAL data in it. The point is that the test does not have a one-second window of showing the wrong answer, meaning I could wait for 60 seconds, and still see the wrong WAL file at the top. Bruce, what does stat x1 x2 look like on your system? Which OS? Maybe we need caveats for various OSes? -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] Proposed doc-patch: Identifying the Current WAL file
On Sat, 15 Apr 2006, Bruce Momjian wrote: And I tried it on Fedora Core 2: Device: 11h/17d Inode: 24707338Links: 1 Access: (0644/-rw-r--r--) Uid: ( 7078/bmomjian) Gid: ( 100/ users) Access: 2006-04-15 11:41:53.0 -0700 Modify: 2006-04-15 11:41:53.0 -0700 Change: 2006-04-15 11:41:53.0 -0700 And you know what? I pulled a bonehead maneuver when I read the output of my stat command. FC3/4 appear to be the same. I wonder if this is filesystem dependent since stat has all those trailing 0's for some reason. Maybe we are back to using sort to decide the winner of a tie? -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [GENERAL] Database users Passwords
On Tue, 2006-10-17 at 10:41 -0400, DEV wrote:
> Hello all,
>
> I have user information in a table that I want to use to add
> users to the user roles tables that are part of postgresql. My
> question is this: the passwords in my user table are in there as a
> text file with the data being encrypted using the crypt function, is
> there a way I can use this crypt password when I do a “CREATE ROLE
> userid LOGIN PASSWORD 'crypt password' NOSUPERUSER INHERIT NOCREATEDB
> NOCREATEROLE” I know that in the current CREATE ROLE I have listed
> will take a clear text password and encrypt it for me. What do I need
> to change to use an encrypted password?
>
If user is foo and password is bar, do:
=# select md5('barfoo');
LOG: duration: 0.140 ms statement: select md5('barfoo');
md5
--
96948aad3fcae80c08a35c9b5958cd89
(1 row)
=# create role foo login password 'md596948aad3fcae80c08a35c9b5958cd89'
nosuperuser inherit nocreatedb nocreaterole;
This seems to be lacking in the docs. At least, the only place I found
this information was a user comment in the 8.0 docs. Is this already in
the 8.1 docs? Should we add a description of the way postgresql does the
md5 hashes in the CREATE ROLE section?
Regards,
Jeff Davis
---(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] [GENERAL] Database users Passwords
On Tue, 2006-10-17 at 21:35 +0200, Peter Eisentraut wrote: > Jeff Davis wrote: > > This seems to be lacking in the docs. At least, the only place I > > found this information was a user comment in the 8.0 docs. Is this > > already in the 8.1 docs? Should we add a description of the way > > postgresql does the md5 hashes in the CREATE ROLE section? > > This has been in the documentation at least as far back as 7.3. > I took a second look, and I am not seeing anything in the CREATE ROLE docs that say you need to concatenate the user to the password before encrypting with md5. I saw that in a comment in the 8.0 docs, but I can't find it in the 8.1 docs. Can you please point me to a specific section? Regards, Jeff Davis ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Replication documentation addition
On Tue, 24 Oct 2006, Joshua D. Drake wrote: AFAIK Continuent's product fails that test... To my knowledge, p/cluster only works with PostgreSQL but I could be wrong. p/cluster was the old name for the PostgreSQL specific version. It's been rebranded as uni/cluster and they have versions for both PostgreSQL and MySQL. One of my customers is trying it out currently. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Replication documentation addition
On Tue, 14 Nov 2006, Bruce Momjian wrote: Your description was too detailed, but I took some of your concepts: In clustering, each server can accept write requests, and these write requests are broadcast from the original server to all other servers before each transaction commits. Heavy write activity can cause excessive locking, leading to poor performance. In fact, write performance is often worse than that of a single server. Read requests can be sent to any server. Clustering is best for mostly read workloads, though its big advantage is that any server can accept write requests --- there is no need to partition workloads between read/write and read-only servers. Clustering is implemented by Oracle in their RAC product. PostgreSQL does not offer this type of load balancing, though PostgreSQL two-phase commit ( and ) can be used to implement this in application code or middleware. Bruce, Continuent's uni/cluster middleware product implements this type of clustering/load balancing. Perhaps it warrants a mention? Not sure how far we want to get into listing external products. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Replication documentation addition
On Tue, 14 Nov 2006, Bruce Momjian wrote: Jeff Frost wrote: On Tue, 14 Nov 2006, Bruce Momjian wrote: Your description was too detailed, but I took some of your concepts: In clustering, each server can accept write requests, and these write requests are broadcast from the original server to all other servers before each transaction commits. Heavy write activity can cause excessive locking, leading to poor performance. In fact, write performance is often worse than that of a single server. Read requests can be sent to any server. Clustering is best for mostly read workloads, though its big advantage is that any server can accept write requests --- there is no need to partition workloads between read/write and read-only servers. Clustering is implemented by Oracle in their RAC product. PostgreSQL does not offer this type of load balancing, though PostgreSQL two-phase commit ( and ) can be used to implement this in application code or middleware. Bruce, Continuent's uni/cluster middleware product implements this type of clustering/load balancing. Perhaps it warrants a mention? Not sure how far we want to get into listing external products. We had a long discussion about that and felt that recommending commercial products or even every open source project was too much. The idea was that we should reference a web page that has them all mentioned, but no one has set one up yet. That makes sense, I just hate to see us say something like "Oracle can do this with RAC but PostgreSQL cannot." -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [DOCS] [HACKERS] Replication documentation addition
On Tue, 14 Nov 2006, Bruce Momjian wrote: We had a long discussion about that and felt that recommending commercial products or even every open source project was too much. The idea was that we should reference a web page that has them all mentioned, but no one has set one up yet. That makes sense, I just hate to see us say something like "Oracle can do this with RAC but PostgreSQL cannot." Agreed. I think we would mention any PostgreSQL solution for this, even if it is not open source. We mention solutions as examples in this part of the documentation. FYI, as far as I know, Continuent's solution is "Query Broadcast Load Balancing", not clustering. I would speculate that your terminology is slightly more accurate than mine. The do query broadcast, but they also do a bit more with it than that as they evaluate many of the non deterministic write queries on a particular server and update the broadcast query so each db gets the same value. I guess middleware of this sort automatically ends up in the query broadcast category. It just sounds awfully similar to the description of cluster for load balancing: In clustering, each server can accept write requests, and these write requests are broadcast from the original server to all other servers before each transaction commits. I guess it's kind of a fine line how it gets defined? -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] [HACKERS] Replication documentation addition
On Tue, 14 Nov 2006, Bruce Momjian wrote: In clustering, each server can accept write requests, and these write requests are broadcast from the original server to all other servers before each transaction commits. I guess it's kind of a fine line how it gets defined? Hmmm. Interesting. Does anyone else have details or an opinion on this? The fact that there is something sitting above the servers seems to be the defining issue of calling it query broadcast. My thinking on the definition of clustering was that there is some smarts for graceful failover and automated or semi-automated ways of bringing failed DB servers back up to date and online with the rest of the servers in the cluster. All servers need to be able to accept writes, but do we differentiate on where the writes originated (i.e. middleware or another postgresql server) or on functionality? -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] [HACKERS] Replication documentation addition
On Tue, 14 Nov 2006, Bruce Momjian wrote: My thinking on the definition of clustering was that there is some smarts for graceful failover and automated or semi-automated ways of bringing failed DB servers back up to date and online with the rest of the servers in the cluster. All servers need to be able to accept writes, but do we No, even replication servers can have that. differentiate on where the writes originated (i.e. middleware or another postgresql server) or on functionality? Fundamentally, broadcast means the queries are being propogated outside the server, with the benefits and limitations inherent in that. I'd definitely have to agree with you on that. I guess I'm trying to decide what differentiates clustering for load balancing from query broadcast based on your text. Maybe just don't use the word broadcast here: "In clustering, each server can accept write requests, and these write requests are broadcast from the original server to all other servers before each transaction commits." Unfortunately, I can't seem to come up with anything more clever. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Replication documentation addition
On Tue, 14 Nov 2006, Bruce Momjian wrote: "In clustering, each server can accept write requests, and these write requests are broadcast from the original server to all other servers before each transaction commits." Unfortunately, I can't seem to come up with anything more clever. Basically, when you are broadcasting outside the server, you are broadcasting SQL queries, and those queries do not have information about non-deterministic functions and have issues with universal commits on all node. Ahh..I like this explanation, because the inter-server communication in clustering is not necessarily SQL queries. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] FOR SHARE vs FOR UPDATE locks
On Fri, 2006-12-01 at 02:46 -0500, Tom Lane wrote: > Michael Paesold <[EMAIL PROTECTED]> writes: > > Now seriously, isn't this a perfectly feasible scenario? E.g. the outer > > transaction acquires a shared lock because of foreign key constraints, and > > the sub transaction later wants to update that row? > > Yeah, it's not implausible. But the only way I can see to implement > that is to upgrade the outer xact's shared lock to exclusive, and that > doesn't seem real cool either. > If it's a plausible enough sequence of events, is it worth adding a note to the "migration" section of the release notes? Regards, Jeff Davis ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [DOCS] psql man page error?
On Tue, 5 Dec 2006, Simon Riggs wrote: which gives prompt> echo "\x \\ select * from foo;" | psql Expanded display is on. invalid command \ i.e. doesn't work on bash. With bash the command should be: echo -e "\x \n select * from foo;" | psql which gives prompt> echo -e "\x \n select * from foo;" | psql Expanded display is on. ERROR: relation "foo" does not exist Does this mean there are multiple forms of the echo command, or is this example just wrong? I believe that /bin/echo and the bash built-in used to be slightly different, although reviewing both man pages on my FC5 system seem to indicate that they have the same command-line arguments. It's also possible that I'm thinking back to my Solaris (2.5.1) days when the built-in tcsh echo was in fact different than /bin/echo. That's why all my scripts seem to call the binary and not the built-in. Another possibility is that the original author had the options set in his xpg_echo environment variable and forgot about it...or his distro was setting it in a profile.d file. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(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] Urgent Postgresql requirement.
Pratik, You should post this to the pgsql-jobs list ([EMAIL PROTECTED]) not to the docs list if you want to get reasonable responses. -Jeff On Wed, 17 Jan 2007, Pratik wrote: Hi, This is Pratik with APN Software services, we have urgent direct client requirement with one of our direct client. Below is the detailed description for the requirement. Location: San Diego, CA Contract to hire or Fultime PostgreSQL Database Developer -Full Time or Contract to hire This position involves creating tables, views, functions and stored procedures in PostgreSQL to support front end OLTP and reporting applications. * Strong experience in PostgreSQL. * Understanding of database normalization concepts * Some experience in logical and physical database design and implementation * Prior experience working in a project oriented environment and meeting deadlines under tight time constraints * Strong analytical skills * Capable of working independently with minimal supervision Pratik Gandhi APN Software Services Inc. Phone: (510) 857-5767 E-Mail: [EMAIL PROTECTED] www.apninc.com <http://www.apninc.com/> -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] Slony for upgrades
On Mon, 15 Oct 2007, Bruce Momjian wrote: Seems we didn't have any mention of Slony for upgrades in the migration section, so I added it: It is also possible to use Slony to create a slave server with the updated version of PostgreSQL. The slave can be on the same computer or a different computer. Once it has synced up with the master server (running the older version of PostgreSQL), you can switch masters and make the slave the master and shut down the older database instance. Such a switch-over results in only several minutes of downtime for an upgrade. Bruce, do you think we should say several minutes of downtime? It's been my experience that the downtime is usually measurable in seconds. I don't think I've ever had a switchover take more than 1 minute. Excellent catch and good work by the way! -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[DOCS] Tsearch docs question
The Tsearch docs, under the GiST and GIN section, say: "Lossiness [of GiST] causes serious performance degradation since random access of heap records is slow and limits the usefulness of GiST indexes." The docs do go into some detail, but I think it causes some confusion, also. Let me digress to state how I understand the relationship between GIN, GiST, and RECHECK: The benefit of avoiding RECHECK is to avoid the need to re-evaluate the predicate after finding the entry in the index. This can be valuable in tsearch, because the functions are much more expensive than (for example) integer equality. We (currently) have to visit the heap anyway, to see the visibility information. So avoiding a RECHECK clause doesn't do anything to prevent random heap I/O (although, a less-lossy index will have fewer false positives, by definition). GIN (as used with tsearch) is lossy for more sophisticated tsqueries (those involving labels) and non-lossy for simpler tsqueries. There's only one tsquery type, so PostgreSQL has no way of differentiating between these two cases. GiST (as used with tsearch) is lossy for large tsvectors or tsqueries containing labels; and non-lossy for small tsvectors matched against a tsquery that contains no labels. PostgreSQL can't differentiate between these two cases. So, for GiST they always RECHECK (so you're always sure to get the right result), and for GIN the default operator does not RECHECK (for performance), but if you suspect that you might be using labels in your tsqueries you need to use a special RECHECKing operator, "@@@", to be accurate. Is the above accurate? Back to the docs: I think the docs could clear this issue up somewhat. The current wording suggests that GIN performs better because it avoids a trip to the heap, when in reality it seems the benefit is avoiding the need to re-evaluate the expensive tsearch functions (which might need to access TOASTed data). There's also a related issue: I think a RECHECK would be less costly if you have the tsvectors materialized in the table (using triggers) and index that. Maybe that could be a tip for using GiST indexes. Regards, Jeff Davis ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] Tsearch docs question
On Fri, 2007-10-26 at 15:26 -0400, Tom Lane wrote: > Are you looking at CVS HEAD, or what was there in beta1? I rewrote > that stuff a few days ago: > http://developer.postgresql.org/pgdocs/postgres/textsearch-indexes.html > Excellent, thanks, that's a big improvement to those docs all around. I should have checked the latest before posting, almost everything I mentioned was already addressed. There's still one very minor thing: "A GiST index is lossy, meaning it is necessary to check the actual table row to eliminate false matches." could be changed to something like: "A GiST index is lossy, meaning that the index may produce false matches, and it is necessary to check the actual table row before eliminating these false matches. And perhaps change: "Lossiness causes performance degradation since random access to table records is slow; ..." to something like: "Lossiness causes performance degradation due to unnecessary random accesses to table records; ..." The only reason I say this is because, on my first reading, I read that to mean that lossless indexes don't require trips to the heap at all (which isn't true, yet). Regards, Jeff Davis ---(end of broadcast)--- TIP 6: explain analyze is your friend
[DOCS] lastval() not included in table
In the current version of the docs here:
http://developer.postgresql.org/pgdocs/postgres/functions-sequence.html
The lastval() function appears to be missing from table 9-38.
I don't see any obvious reason that it's left out.
Regards,
Jeff Davis
---(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
[DOCS] Documentation and mutating PGresult objects
"PGresult objects are read-only after creation, and so can be passed around freely between threads." >From http://www.postgresql.org/docs/9.1/static/libpq-threading.html But what about things like PQsetvalue? Is that a documentation bug? Should result objects be protected by synchronization as well as connection objects? Regards, Jeff Davis -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Comment on max_locks_per_transaction
On Fri, 2012-06-15 at 11:05 -0700, Josh Berkus wrote: > The default, 64, has historically proven sufficient for most databases, > but you might need to raise this value if you have clients that touch > many different tables in a single transaction. Databases with several > tables with many partitions each can require raising this setting. Is "partition" defined somewhere else in the docs? Maybe it should say something like: "Extensive use of table inheritance is the most common reason to increase this value from the default", assuming that's what you meant. Regards, Jeff Davis -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Comment on max_locks_per_transaction
On Fri, 2012-06-15 at 12:37 -0700, Josh Berkus wrote: > Hmmm. I think we should also say "partitioning", as well as > "inheritance". Maybe: > > "Extensive use of table inheritance, such as for tables with many > partitions, may require raising this setting." http://www.postgresql.org/docs/9.2/static/ddl-partitioning.html#DDL-PARTITIONING-CONSTRAINT-EXCLUSION Looks like we do define it, so that's fine with me. Regards, Jeff Davis -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] Documentation cross reference from copy to \copy
Where the SQL COPY command warns us not to confuse it with \copy, a link to \copy would be useful. The attached patch implements that, but I'm not sure it does so in the preferred way. Thanks, Jeff copy_crossref_v1.patch Description: Binary data - Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Would like to contribute a section to docs for 9.3. Where to start?
On Mon, 2012-08-13 at 03:41 -0700, Chris Travers wrote: > Hi all; > > > I would like to contribute a "What is an Object Relational database?" > section to the documentation for 9.3. Where is the best place to > start tools and community-process-wise? > > > My thinking is that since people are often confused by this label, it > would be worth describing what it means, and describing in brief > detail object-relational features in PostgreSQL. A concrete example of the confusion caused by our current branding (with no supporting documentation) recently appeared on -novice: http://archives.postgresql.org/message-id/[email protected] That's exactly the kind of (potential) user we should target with this document. Regards, Jeff Davis -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Confusion over "This page in other versions" links
On Tue, 2012-08-14 at 13:32 +0300, Heikki Linnakangas wrote: > I just had a discussion with someone off-list, where he was looking at > the documentation page of a contrib module at www.postgresql.org/docs. > Looking at the page, he came to the conclusion that the module was no > longer supported in 9.2, because the header at the top of the page said: > > "This page in other versions: 9.1 / 9.0 / 8.4 / 8.3 | Unsupported > versions: 9.2 / devel" > > I find the links really helpful, but apparently they can be > misunderstood. Perhaps we should change the "Unsupported versions" text > to "future versions" or "Development versions". Or change "9.2" to "9.2 > (beta)", and remove the "Unsupported versions" text altogether. Or perhaps: "This document for version: 9.1 / 9.0 / 8.4 / 8.3 | devel / 9.2 (beta) | Old versions: 8.2 / 8.1 / ..." I didn't read the original rationale, but it's not clear to me why we have quick links to the documents for unsupported versions. Maybe just have one link "unsupported versions" that goes to http://www.postgresql.org/docs/manuals/archive/ ? Regards, Jeff Davis -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Would like to contribute a section to docs for 9.3. Where to start?
On Fri, 2012-08-17 at 16:03 -0400, Peter Eisentraut wrote: > On 8/15/12 5:33 AM, Chris Travers wrote: > > So here is a very rough draft. I would be interested in feedback as to > > inaccuracies or omissions. I would like to get the technical side right > > before going into an editorial phase. > > > > Any feedback on the technical side? > > [citation needed] > > Seriously, if we are trying to justify our use of seemingly standard > academic terms, we should have some references to where those are > defined or at least discussed. Otherwise we are just begging the > question: PostgreSQL is object-relational because we say so. I feel like the bar is becoming pretty high for this document. It must: 1. Settle on an accepted criteria for ORDBMS 2. Describe how postgres meets that criteria in a way that's: a. compelling to users b. connects with OOP so the users don't feel like it's a bait-and-switch or get confused by starting with the wrong expectation I feel like making #1 compatible with 2(a) requires some creativity; and #1 might be incompatible with 2(b) entirely. Regards, Jeff Davis -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Would like to contribute a section to docs for 9.3. Where to start?
On Sat, 2012-08-18 at 18:56 -0700, Chris Travers wrote:
> I was thinking initially of a *brief* description of what was meant so
> that people didn't get too confused.
+1.
I was imagining two contrasting examples, one using the relational
mindset and one using the O-R mindset.
Inheritance and composite types are easy enough to understand. Perhaps
those could make for a short example on the O-R side while still looking
different enough from a traditional relational approach.
Regards,
Jeff Davis
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [PERFORM] Planner selects different execution plans depending on limit
On Thu, Sep 13, 2012 at 10:33 AM, Tom Lane wrote: > Bill Martin writes: > >> How can I adjust the statistics target of the index? > > Just pretend it's a table. > > ALTER TABLE index_name ALTER COLUMN column_name SET STATISTICS ... > > You'll need to look at the index (eg with \d) to see what the name of > the desired column is, since index expressions have system-assigned > column names. Is this documented anywhere? I couldn't find it. If not, which section would be the best one to add it to? Cheers, Jeff -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] CONSTRAINT on ARRAY ELEMENTS
On Sat, 2012-11-03 at 09:43 +, Nikolaos Ikonomopoulos wrote: > > CREATE TABLE employ_presence > ( > p_id character(6) not null, > p_month character(3) NOT NULL, > statuscode integer array[7], > CONSTRAINT unq_employ_presence UNIQUE (p_id, p_month), > CONSTRAINT chk_employ_month CHECK (p_month = ANY > (ARRAY['Jan'::bpchar, 'Feb'::bpchar, 'Mar'::bpchar, 'Apr'::bpchar, > 'May'::bpchar, 'Jun'::bpchar, 'Jul'::bpchar, 'Aug'::bpchar, > 'Sep'::bpchar, 'Oct'::bpchar, 'Nov'::bpchar, 'Dec'::bpchar])) > ); > > > > How can add a CONSTRAINT on statuscode array elements to accept values > between 0 to 5 You can try: CHECK (statuscode <@ ARRAY[1,2,3,4,5]) Regards, Jeff Davis -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] 8.4 doc bug for "Incrementally Updated Backups"
Based on Jürgen Fuchsberger's experience described on the general list, I think the following should have been back-patched to 8.4 and 8.3 (assuming it gets a minor update before it EOL) as well, not just 9.0. In particular, in 8.4 chapter 24.4.5 it says "it will be up to you to determine how far back you need to keep WAL segment files to have a recoverable backup" but it dangerously does not mention that it is also up to you to construct a backup_label file such that those WAL segment files will actually get used. commit 13e6d6c5da184abcdfcfc9874ad17ef09f4ea044 Author: Bruce Momjian Date: Wed Aug 25 23:55:54 2010 + Remove docs for "Incrementally Updated Backups" because it was of questionable reliability; information moved to a wiki: http://wiki.postgresql.org/wiki/Incrementally_Updated_Backups Backpatch to 9.0. Cheers, Jeff -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] 8.4 doc bug for "Incrementally Updated Backups"
On Fri, Nov 23, 2012 at 3:42 PM, Bruce Momjian wrote: > > We don't assume people are reading docs from very old versions. > Even if that is the version they are using? It is, after all, still under maintenance, Cheers, Jeff -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] 8.4 doc bug for "Incrementally Updated Backups"
On Fri, Nov 23, 2012 at 5:36 PM, Bruce Momjian wrote: > On Fri, Nov 23, 2012 at 04:26:48PM -0800, Jeff Janes wrote: >> On Fri, Nov 23, 2012 at 3:42 PM, Bruce Momjian wrote: >> > >> > We don't assume people are reading docs from very old versions. >> > >> >> Even if that is the version they are using? It is, after all, still >> under maintenance, > > There are three options for doc patches: > > 1. patch only git head, meaning the next major release > 2. do #1, plus the most recent major released version, e.g. 9.2.X > 3. #1, #2, and all major supported released versions > > In general, #1 is normally for wording clarifications, #2 is for usage > clarifications, and #3 is to correct mistakes. Not sure I follow that > 100%, but that is what I normally do. > > Is that process good? Did I not follow it? It was removed from 9.0 because it was considered to be unreliable. I think that unreliable advice about taking backups is a mistake, so it should have followed path #3. I guess it is also clarification, but a pretty major one. Cheers, Jeff -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] 8.4 doc bug for "Incrementally Updated Backups"
On Mon, Nov 26, 2012 at 12:01 PM, Bruce Momjian wrote: > On Sat, Nov 24, 2012 at 01:56:27PM -0800, Jeff Janes wrote: >> On Fri, Nov 23, 2012 at 5:36 PM, Bruce Momjian wrote: >> > On Fri, Nov 23, 2012 at 04:26:48PM -0800, Jeff Janes wrote: >> >> On Fri, Nov 23, 2012 at 3:42 PM, Bruce Momjian wrote: >> >> > >> >> > We don't assume people are reading docs from very old versions. >> >> > >> >> >> >> Even if that is the version they are using? It is, after all, still >> >> under maintenance, >> > >> > There are three options for doc patches: >> > >> > 1. patch only git head, meaning the next major release >> > 2. do #1, plus the most recent major released version, e.g. 9.2.X >> > 3. #1, #2, and all major supported released versions >> > >> > In general, #1 is normally for wording clarifications, #2 is for usage >> > clarifications, and #3 is to correct mistakes. Not sure I follow that >> > 100%, but that is what I normally do. >> > >> > Is that process good? Did I not follow it? >> >> It was removed from 9.0 because it was considered to be unreliable. I >> think that unreliable advice about taking backups is a mistake, so it >> should have followed path #3. I guess it is also clarification, but a >> pretty major one. > > I checked just now and the unreliable advice does not appear in 8.4, so > it possible that in 2010 I checked and found it only applied back to > 9.0, or I might only have checked 9.0. The docs were re-arranged, so it is present but in a different place. Sorry, I should have included the URL in the first place (24.4.5) : http://www.postgresql.org/docs/8.4/static/warm-standby.html Cheers, Jeff -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] Comments on commit regarding checksums (2266db39)
2PC state files actually are protected by CRC32 (see EndPrepare()), and so is pg_control (which is not mentioned). If we want to be thorough, it might be worth mentioning that we expect filesystem metadata to not be corrupted/lost, either. Regards, Jeff Davis -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] having trouble building the postgres-A4.pdf
Part of the prep work for building the RPMs is building the pdf docs. The
postgres-US.pdf built ok, but I'm receiving the following when trying to build
the postgres-A4.pdf:
Overfull \hbox (2.39996pt too wide) in alignment at lines 230738--232257
[] [] [] [] []
[239.0.8] [240.0.8] [241.0.8] [242.0.8]
Overfull \hbox (1.5pt too wide) in alignment at lines 232562--232622
[] [] []
Overfull \hbox (1.5pt too wide) in alignment at lines 232622--233010
[] [] []
[243.0.8
! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd
fstartlink.
\endgroup \set@typeset@protect
l.233304 ...esult in a run-\/time lookup.\endPar{}
\endNode{}\endDisplayGroup...
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on postgres-A4.log.
make: *** [postgres-A4.pdf] Error 1
rm postgres-A4.tex-pdf
I found this older thread with a similar error:
http://www.postgresql.org/message-id/[email protected]
Help?
--
Jeff Frost
CTO, PostgreSQL Experts, Inc.
Phone: 1-888-PG-EXPRT x506
FAX: 415-762-5122
http://www.pgexperts.com/
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] having trouble building the postgres-A4.pdf
On 06/26/13 10:31, Alvaro Herrera wrote: > Jeff Frost wrote: > >> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than >> \pd >> fstartlink. > Did you see this one? > > http://www.postgresql.org/message-id/[email protected] > > I just found it, thank you! Will give those suggestions a shot. -- Jeff Frost CTO, PostgreSQL Experts, Inc. Phone: 1-888-PG-EXPRT x506 FAX: 415-762-5122 http://www.pgexperts.com/ -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] having trouble building the postgres-A4.pdf
On 06/26/13 10:34, Jeff Frost wrote: > On 06/26/13 10:31, Alvaro Herrera wrote: >> Jeff Frost wrote: >> >>> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than >>> \pd >>> fstartlink. >> Did you see this one? >> >> http://www.postgresql.org/message-id/[email protected] >> >> > I just found it, thank you! Will give those suggestions a shot. > Well, shoot. I built a Wheezy VM, installed texlive2012 and openjade1.3, but I still get this error with the 9.3beta2 postgres-A4.pdf: [243.0.11 ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd fstartlink. \AtBegShi@Output ...ipout \box \AtBeginShipoutBox \fi \fi l.233304 ...esult in a run-\/time lookup.\endPar{} \endNode{}\endDisplayGroup... Here is how much of TeX's memory you used: 22156 strings out of 482156 175817 string characters out of 3785924 310162 words of memory out of 3085000 27148 multiletter control sequences out of 15000+50 80861 words of font info for 131 fonts, out of 300 for 9000 14 hyphenation exceptions out of 8191 30i,12n,43p,307b,1360s stack positions out of 1500i,500n,1500p,20b,5s ! ==> Fatal error occurred, no output PDF file produced! -- Jeff Frost CTO, PostgreSQL Experts, Inc. Phone: 1-888-PG-EXPRT x506 FAX: 415-762-5122 http://www.pgexperts.com/ -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] having trouble building the postgres-A4.pdf
On 06/26/13 11:55, Alvaro Herrera wrote: > Jeff Frost wrote: >> On 06/26/13 10:34, Jeff Frost wrote: >>> On 06/26/13 10:31, Alvaro Herrera wrote: >>>> Jeff Frost wrote: >>>> >>>>> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level >>>>> than \pd >>>>> fstartlink. >>>> Did you see this one? >>>> >>>> http://www.postgresql.org/message-id/[email protected] >>>> >>> I just found it, thank you! Will give those suggestions a shot. >> Well, shoot. I built a Wheezy VM, installed texlive2012 and openjade1.3, but >> I >> still get this error with the 9.3beta2 postgres-A4.pdf: > Did you make sure that it's running the correct openjade? Maybe you > need to rerun configure. I don't remember what I did, perhaps I just > changed Makefile.global to point to the right one. > Yah, it's a different error when it's the wrong openjade version. It looks like this one that's in the docs: openjade:./stylesheet.dsl:664:2:E: flow object not accepted by port; only display flow objects accepted make: *** [postgres-A4.tex-pdf] Segmentation fault jeff@wheezy:~/src/postgresql-9.3beta2/doc/src/sgml$ openjade --version openjade:I: "openjade" version "1.3.2" openjade:I: "OpenSP" version "1.5.2" BTW, I should mention that the US PDF builds fine on both my old system and the new wheezy system. Also, the beta1 PDFs both build fine. -- Jeff Frost CTO, PostgreSQL Experts, Inc. Phone: 1-888-PG-EXPRT x506 FAX: 415-762-5122 http://www.pgexperts.com/ -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] having trouble building the postgres-A4.pdf
On Jun 26, 2013, at 12:07 PM, Alvaro Herrera wrote:
> Jeff Frost wrote:
>
>> Yah, it's a different error when it's the wrong openjade version.
>>
>> It looks like this one that's in the docs:
>>
>> openjade:./stylesheet.dsl:664:2:E: flow object not accepted by port; only
>> display flow objects accepted
>> make: *** [postgres-A4.tex-pdf] Segmentation fault
>
> Hmm, I recall seeing this one as well, but I don't recall the fix for
> it. Did you tweak the jadetex config?
Sorry, that might have been confusing.
I was just pointing out that this is the error you receive if you have the
wrong openjade version.
I am not receiving that error. I am receiving this when building
postgres-A4.pdf for beta2. postgres-US.pdf builds fine.
[243.0.11
! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pd
fstartlink.
\AtBegShi@Output ...ipout \box \AtBeginShipoutBox
\fi \fi
l.233304 ...esult in a run-\/time lookup.\endPar{}
\endNode{}\endDisplayGroup...
Here is how much of TeX's memory you used:
22156 strings out of 482156
175817 string characters out of 3785924
310162 words of memory out of 3085000
27148 multiletter control sequences out of 15000+50
80861 words of font info for 131 fonts, out of 300 for 9000
14 hyphenation exceptions out of 8191
30i,12n,43p,307b,1360s stack positions out of 1500i,500n,1500p,20b,5s
! ==> Fatal error occurred, no output PDF file produced!
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] having trouble building the postgres-A4.pdf
On 06/26/13 12:14, Jeff Frost wrote:
>
> I am receiving this when building postgres-A4.pdf for beta2. postgres-US.pdf
> builds fine.
>
> [243.0.11
> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than
> \pd
> fstartlink.
> \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
> \fi \fi
> l.233304 ...esult in a run-\/time lookup.\endPar{}
>
> \endNode{}\endDisplayGroup...
>
>
>
> Here is how much of TeX's memory you used:
> 22156 strings out of 482156
> 175817 string characters out of 3785924
> 310162 words of memory out of 3085000
> 27148 multiletter control sequences out of 15000+50
> 80861 words of font info for 131 fonts, out of 300 for 9000
> 14 hyphenation exceptions out of 8191
> 30i,12n,43p,307b,1360s stack positions out of 1500i,500n,1500p,20b,5s
> ! ==> Fatal error occurred, no output PDF file produced!
>
Alvaro, did both the beta2 PDFs build fine on borka? If so, could you get
them to me so I can build the RPMs while I figure out the issue with my
tex/jade setup?
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] having trouble building the postgres-A4.pdf
On 06/26/13 12:40, Alvaro Herrera wrote: > Jeff Frost wrote: > >> Alvaro, did both the beta2 PDFs build fine on borka? If so, could you get >> them to me so I can build the RPMs while I figure out the issue with my >> tex/jade setup? > I don't think borka builds those PDFs. But I tried locally, and I am > sad to report that it fails here as well, whereas the beta1 A4 PDF did > build fine. > Well, happy to hear that I'm not special, but sad to hear that it doesn't build. :-/ Any idea how to fix it? -- Jeff Frost CTO, PostgreSQL Experts, Inc. Phone: 1-888-PG-EXPRT x506 FAX: 415-762-5122 http://www.pgexperts.com/ -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] having trouble building the postgres-A4.pdf
On Jun 26, 2013, at 13:20, Alvaro Herrera wrote: >> Any idea how to fix it? > > Nope, but maybe try to build the PDF using the XML toolchain? I'm afraid that's a bit out of my depth. I would speculate that since the US PDF builds and the A4 format is smaller, it's a sizing problem, but I've no idea how to fix that sort of thing. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] FE/BE docs and unsigned integers
The documentation doesn't give much of a hint that the protocol is using unsigned integers. For instance, under ParameterDescription here: http://www.postgresql.org/docs/9.3/static/protocol-message-formats.html it says that the object ID is an Int32, which is described here: http://www.postgresql.org/docs/9.3/static/protocol-message-types.html as just a plain 32-bit integer. But the code (e.g. getParamDescriptions()) is clearly reading it into an Oid, which is unsigned. Is there a reason this isn't clear? Is it meant to be ambiguous because (as far as the protocol is concerned) it's just an opaque 32 bits? It seems like it's worth a note somewhere at least. Regards, Jeff Davis -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] "Alter system" command documentation
Hi, >From http://www.postgresql.org/docs/current/static/sql-altersystem.html "Values set with ALTER SYSTEM will be effective after the next server configuration reload (SIGHUP or pg_ctl reload), or after the next server restart in the case of parameters that can only be changed at server start." Isn't it unfortunate that the command used for changing the configuration file from within SQL mentions SIGHUP and pg_ctl reload, but not "select pg_reload_conf();", as a way to activate that change? Cheers, Jeff
Re: [DOCS] "Alter system" command documentation
On Mon, Jun 15, 2015 at 2:10 PM, David G. Johnston < [email protected]> wrote: > On Mon, Jun 15, 2015 at 4:58 PM, Euler Taveira > wrote: > >> On 15-06-2015 13:32, Jeff Janes wrote: >> > From http://www.postgresql.org/docs/current/static/sql-altersystem.html >> > >> > "Values set with ALTER SYSTEM will be effective after the next server >> > configuration reload (SIGHUP or pg_ctl reload), or after the next server >> > restart in the case of parameters that can only be changed at server >> start." >> > >> > Isn't it unfortunate that the command used for changing the >> > configuration file from within SQL mentions SIGHUP and pg_ctl reload, >> > but not "select pg_reload_conf();", as a way to activate that change? >> > >> SIGHUP is an implementation detail. If I were to change that sentence, >> my preference is replace SIGHUP with pg_reload_conf. >> >> > > I > disagree on SIGHUP being an implementation detail. > > Using signals in IPC (inter-process communication) is a public API that > should be documented when applicable. Yes, various command-line and SQL > commands and functions have been provided so that one does not have to use > raw signals but they are still part of the public API for the application. > > Adding mention of pg_reload_conf may be warranted (probably is but I > haven't made an independent evaluation) but removing SIGHUP is a separate > concern and one that doesn't seem necessary. > Certainly SIGHUP should be (and is) documented elsewhere in the docs. But there is no reason for it to be documented on this particular page, which is about a command we added specifically so you can make config changes without having to drop into an OS shell. If we are going to mention (on this particularly page) only some of the ways to trigger a reload, certainly the way that also doesn't require dropping into an OS shell should be among the ones included. I don't know that pg_reload_conf() should be the only one we mention here. But surely it should not be the only one we don't mention. The cleanest way would probably be to mention this in addition to the other two, as to mention only this one might imply the others don't work for this purpose. We could not mention any of them and let the person go read the other parts of the docs on their own to find the methods used to trigger a reload, but that seems legalistic and unhelpful. In any event, I was mildly annoyed to go read the docs about a feature I was aware of but never needed to use it before, and have it tell me about two things which I already knew about but which aren't very useful in this context (that is, not having convenient shell access at the moment), while not telling me about the third option which actually is useful in this context but which I didn't know how to spell (because I almost always use the other two methods instead--except for right now). Cheers, Jeff
[DOCS]
According to the documentation: http://www.postgresql.org/docs/9.5/static/datatype-pseudo.html At present the procedural languages all forbid use of a pseudo-type as argument type, and allow only void and record as a result type (plus trigger when the function is used as a trigger). However, pl/perl has accepted "record" as in argument type since 9.1. Cheers, Jeff -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] pg_archivecleanup docs
I think the documentation for the -x option is confusing: -x extension When using the program as a standalone utility, provide an extension that will be stripped from all file names before deciding if they should be deleted. This is typically useful for cleaning up archives that have been compressed during storage, and therefore have had an extension added by the compression program. For example: -x .gz. This option behaves the same whether it is used as a standalone utility or used by archive_cleanup_command. I don't think pg_archivecleanup even knows how it is being called. I think we should just strike the first clause. Cheers, Jeff pg_archivecleanup_doc.patch Description: Binary data -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] pg_restore -l documentation
The docs for the -l switch in pg_restore say: List the contents of the archive. this is weird, because everywhere else we use "table of contents" to describe this, which makes it seem like just plain 'contents' should mean the bulk table data. Attached patch changes it to say: List the table of contents of the archive. Cheers, Jeff pg_restore_TOC.patch Description: Binary data -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
