Re: [PATCHES] Recalculating OldestXmin in a long-running vacuum
Alvaro Herrera wrote: I'm wondering if there has been any effort to make this work in conjunction with ITAGAKI Takahiro's patch to correct the dead tuple count estimate. I just looked at that patch. If we applied both patches, the dead_tuples estimate would be off by the number of dead tuples removed thanks to my patch. In vacuum, we could count separately the tuples that were vacuumable according to the first snapshot, and tuples that were vacuumable according to a new snapshot. We could then get an estimate that's as good as with just Takahiro's patch with this formula: new_n_dead_tuples = n_dead_tuples_at_end - (n_dead_tuples_at_start + tuples_removed_thanks_to_new_snapshot) -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] \prompt for psql
I have applied a modified version of your patch. I moved the prompt 'text' field as optional before name, and removed the default prompt string, which seemed un-Unix-like. I also simplified when stdin/stdout is used. If stdin is the terminal, it seems it makes no difference if we use the terminal or stdin. Now, prompt uses the terminal unless -f is used. I think this simplifies its behavior. I realize cases where stdin is the terminal and stdout is not behave differently in the new patch (prompt goes to the terminal and not to stdout), but I think the previous behavior was too confusing to be useful. I can adjust this if people want different behavior. Update version attached. --- Chad Wagner wrote: On 2/17/07, Tom Lane [EMAIL PROTECTED] wrote: Chad Wagner [EMAIL PROTECTED] writes: Would it make sense to say: 1. if pset.notty is set and '-f' switch is not set then use simple_prompt 2. else then use gets_fromFile(stdin) or some other alternative? Actually, there's another issue, which is where to send the prompt. If we're using /dev/tty the answer is clear, but if we're proposing to read from stdin then it's not necessarily the case that stdout (or even stderr) is appropriate. Arguably a prompt is useless except to a human user, so maybe the rule is if stdin is a tty according to pset.notty, then prompt to /dev/tty; otherwise suppress the prompt altogether. Or we could prompt to stderr instead of /dev/tty in this case. I'm not sure if there are plausible use-cases where stdin leads to the terminal and stderr doesn't. pset.notty will be set to 1 if either stdin or stdout is not a tty. So in the case where they are redirecting both input and output then it will prompt on /dev/tty, otherwise the prompt would go out on stdout. I was thinking perhaps it should look at the '-q' quiet switch for determining whether to display prompt at all. So perhaps with a '-q' switch instead of dumping the prompt to stdout it should always be sent to /dev/tty. Also, I think in general most users of this feature that would be scripting output (via expect or similar) would probably just use the '-v' switches. BTW, attached is the latest version of this patch that includes the code (and updates to the psql-ref.sgml) I talked about earlier. Not sure if gets_fromFile is favored, or perhaps the creation of a psql_prompt_var routine that takes into account some of what simple_prompt is doing but considering the logic we are discussing. [ Attachment, skipping... ] ---(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 -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/ref/psql-ref.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v retrieving revision 1.186 diff -c -c -r1.186 psql-ref.sgml *** doc/src/sgml/ref/psql-ref.sgml 21 Feb 2007 23:22:42 - 1.186 --- doc/src/sgml/ref/psql-ref.sgml 23 Feb 2007 18:14:04 - *** *** 1430,1435 --- 1430,1453 /varlistentry varlistentry + termliteral\prompt [ replaceable class=parametertext/replaceable ] replaceable class=parametername/replaceable/literal/term + listitem + para + Prompts the user to set variable replaceable + class=parametername/. An optional prompt, replaceable + class=parametertext/, can be specified. (For multi-word + prompts, use single-quotes.) + /para + + para + By default, literal\prompt/ uses the terminal for input and + output. However, if the option-f/ command line switch is + used, literal\prompt/ uses standard input and standard output. + /para + /listitem + /varlistentry + + varlistentry termliteral\pset replaceable class=parameterparameter/replaceable [ replaceable class=parametervalue/replaceable ]/literal/term listitem Index: src/bin/psql/command.c === RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v retrieving revision 1.177 diff -c -c -r1.177 command.c *** src/bin/psql/command.c 5 Jan 2007 22:19:49 - 1.177 --- src/bin/psql/command.c 23 Feb 2007 18:14:06 - *** *** 712,717 --- 712,768 free(pw2); } + /* \prompt -- prompt and set variable */ + else if (strcmp(cmd, prompt) == 0) + { + char *opt, *prompt_text = NULL; + char *arg1, *arg2; + + arg1 = psql_scan_slash_option(scan_state,
Re: [PATCHES] [BUGS] BUG #2969: Inaccuracies in Solaris FAQ
There is Solaris FAQ update. Please, look on it and let me know any comments. Thanks Zdenek Rich Teer wrote: The following bug has been logged online: Bug reference: 2969 Logged by: Rich Teer Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.2 Operating system: Solaris 10 Description:Inaccuracies in Solaris FAQ Details: Hi there, First, many thanks for providing the best open source database! I've spotted a couple of errors/bits of bad advice in doc/FAQ_Solaris, which I think should be updated. 1. The answer to question 3 (Why does configure complain about a failed test program?) says to set LD_LIBRARY_PATH to point to the directory containing the missing libs. While this does work (as does the other suggestion of using LD_RUN_PATH), the correct answer to this question is to include the library's path in the executable by using the -R flag, thus avoiding the need for the end user to mess about with environment variables. For example, I use LDFLAGS=-R/usr/sfw/lib ./configure ... to build Postgres which uses Sun's OpenSSL. 2. The answer to question 8 (Can I use DTrace for tracing PostgreSQL?) says that Solaris 10u3 or newer is required to handle probes in static functions. Unfortunately, this is not the case. DTrace can't be enabled when using update 3 (aka 11/06); the (as yet unreleased) update 4 or newer is required. Thanks for reading! Rich Teer, Author of Solaris Systems Programming ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster Index: doc/FAQ_Solaris === RCS file: /projects/cvsroot/pgsql/doc/FAQ_Solaris,v retrieving revision 1.23 diff -c -r1.23 FAQ_Solaris *** doc/FAQ_Solaris 2 Dec 2006 09:29:51 - 1.23 --- doc/FAQ_Solaris 23 Feb 2007 16:12:19 - *** *** 16,21 --- 16,22 6) Where I can download prepared Solaris packages? 7) How can I tune PostgreSQL and Solaris for performance? 8) Can I use DTrace for tracing PostgreSQL? + 9) Can I compile PostgreSQL with Kerberos v5 support? 1) What tools do I need to build and install PostgreSQL on Solaris? *** *** 72,85 This is probably a case of the run-time linker being unable to find some library, probably libz, libreadline or some other non-standard library such as libssl. To point it to the right location, set the ! LD_LIBRARY_PATH environment variable, e.g., ! LD_LIBRARY_PATH=/usr/sfw/lib:/opt/sfw/lib:/usr/local/lib ! export LD_LIBRARY_PATH ! and restart configure. You will also have to keep this setting whenever ! you run any of the installed PostgreSQL programs. Alternatively, set ! the environment variable LD_RUN_PATH. See the ld(1) man page for more information. --- 73,84 This is probably a case of the run-time linker being unable to find some library, probably libz, libreadline or some other non-standard library such as libssl. To point it to the right location, set the ! LDFLAGS environment variable, e.g., ! LDFLAGS=-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib ! export LDFLAGS ! and restart configure. See the ld(1) man page for more information. *** *** 145,150 --- 144,153 Yes, see the chapter Monitoring Database Activity in the documentation for further information. + You can also find more information here: + + http://blogs.sun.com/robertlor/entry/user_level_dtrace_probes_in + If you see the linking of the postgres executable abort with an error message like *** *** 157,164 gmake: *** [postgres] Error 1 your DTrace installation is too old to handle probes in static ! functions. You need Solaris 10u3 or newer. - You can also find more information here: - - http://blogs.sun.com/robertlor/entry/user_level_dtrace_probes_in --- 160,176 gmake: *** [postgres] Error 1 your DTrace installation is too old to handle probes in static ! functions. You need Solaris 10u4 or newer. Workaround is remove static ! keyword from AbortTransaction and CommitTransaction functions declaration in ! src/backend/access/transam/xact.c. ! ! See http://sunsolve.sun.com/search/document.do?assetkey=1-1-2139224-1 ! (registration required). ! ! 9) Can I compile PostgreSQL with Kerberos v5 support? ! ! Kerberos is integrated in OpenSolaris and will be integrated in Solaris 10u4. GSS security ! mechanism contains internal Kerberos v5 library implementation which provide all necessary ! krb5 function. However, usage this library is only on own risk. It is private library ! and interface may change without notice. ---(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: [PATCHES] [BUGS] BUG #2969: Inaccuracies in Solaris FAQ
Patch applied. Thanks. --- Zdenek Kotala wrote: There is Solaris FAQ update. Please, look on it and let me know any comments. Thanks Zdenek Rich Teer wrote: The following bug has been logged online: Bug reference: 2969 Logged by: Rich Teer Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.2 Operating system: Solaris 10 Description:Inaccuracies in Solaris FAQ Details: Hi there, First, many thanks for providing the best open source database! I've spotted a couple of errors/bits of bad advice in doc/FAQ_Solaris, which I think should be updated. 1. The answer to question 3 (Why does configure complain about a failed test program?) says to set LD_LIBRARY_PATH to point to the directory containing the missing libs. While this does work (as does the other suggestion of using LD_RUN_PATH), the correct answer to this question is to include the library's path in the executable by using the -R flag, thus avoiding the need for the end user to mess about with environment variables. For example, I use LDFLAGS=-R/usr/sfw/lib ./configure ... to build Postgres which uses Sun's OpenSSL. 2. The answer to question 8 (Can I use DTrace for tracing PostgreSQL?) says that Solaris 10u3 or newer is required to handle probes in static functions. Unfortunately, this is not the case. DTrace can't be enabled when using update 3 (aka 11/06); the (as yet unreleased) update 4 or newer is required. Thanks for reading! Rich Teer, Author of Solaris Systems Programming ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [BUGS] BUG #2969: Inaccuracies in Solaris FAQ
Zdenek Kotala wrote: There is Solaris FAQ update. Please, look on it and let me know any comments. The actual answer to the question Can I compile PostgreSQL with Kerberos v5 support? is Yes, why not?. I don't think Can I use this weird internal private library that seems to provide a similar interface? is a Frequently Asked Question. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] BLCKSZ fun facts
Peter Eisentraut wrote: Bruce Momjian wrote: I have implemented your ideas for checking BLCKSZ = 1024, I think the check should be were the issue arises, not in some distant file without explanation. OK, moved to guc.c. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org