Re: [HACKERS] [GENERAL] pg_upgrade -u
On May 29, 2013, at 11:07 AM, Bruce Momjian wrote: On Wed, May 29, 2013 at 08:59:42AM -0400, Ray Stell wrote: [ moved to hacker ] The question is whether hard-wiring these helps more than it hurts, and which ones should be hard-wired. I seems to me that superuser is exactly that special case and that if an alternate superuser is hardwired in the src cluster then -u/-U and that specific value will be required on both sides of pg_upgrade, no variability is needed and perhaps not possible. You're point is well taken for port. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] pg_upgrade -u
On May 28, 2013, at 10:55 PM, Bruce Momjian wrote: On Wed, May 22, 2013 at 03:05:57PM -0400, Ray Stell wrote: However, if we pass these items into the scripts, we then force these values to be used, even if the user wants to use a different value. It is a balance between supplying defaults vs. requiring the user to supply or change the values used during the ugprade. At this point, I have favored _not_ supplying defaults in the script. Do you have an alternative argument in favor of supplying defaults? Well, the story really began when I ran initdb with a -U arg. vacuumdb takes the -U also, but pg_upgrade does not. It seems like if I have to supply a -u in order to get pg_upgrade to function in the case where there is no default superuser in the cluster, then an associated vacuumdb command requires a -U arg. Perhaps just documenting the behavior is all that is needed, but -U is everywhere and I think that's a good thing. [ moved to hacker ] Wow, I never realized other tools used -U for user, instead of -u. Should I change pg_upgrade to use -U for 9.4? I can keep supporting -u as an undocumented option. That would make for consistency, but not change the broken behavior. Comments on this below. I have applied the attached patch to document that you might need to set connection parameters for vacuumdb. That will work as this is not a big deal, but have to admit, I didn't understand the logic you posted in your question. If the src cluster has a alternate superuser (from initdb -U), and the the pg_upgrade command has to be supplied a -u/-U in order to work with the src cluster, why would you assume somehow the output cluster has changed to the default superuser when you build the vacuum script on the other side of pg_upgrade? Is that even possible to accomplish? Your statement about forcing the values throws me, as it seems to me the user is requesting the variation. I have not dug into pg_upgrade's guts, so I may just be uninformed. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [ADMIN] command tag logging
On Thu, May 27, 2010 at 12:49:49PM -0400, Tom Lane wrote: alvherre alvhe...@commandprompt.com writes: Excerpts from Ray Stell's message of mi?? may 26 17:08:33 -0400 2010: I just installed a compiled from src 8.3.11. I usually include %i, command tag, in the log_line_prefix setting. This causes some spewage I'd not seen before on connection received lines as if it is dumping the environment: Hmm, I bet it's the recent %.*s patch. That is in the right place, isn't it. That would suggest that get_ps_display() is returning a wrong length on Ray's machine. It works okay here, but since that's platform-specific code that hardly proves much. Ray, what platform is this exactly? I should have included this: version - PostgreSQL 8.3.11 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46) (1 row) [postgres ~]$ uname -a Linux horntail.cns.vt.edu 2.6.18-194.3.1.el5PAE #1 SMP Sun May 2 04:42:25 EDT 2010 i686 i686 i386 GNU/Linux [postgres ~]$ cat /etc/issue Red Hat Enterprise Linux Server release 5.5 (Tikanga) Kernel \r on an \m -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PERFORM] how to plan for vacuum?
On Thu, Jan 25, 2007 at 08:04:49AM -0800, Joshua D. Drake wrote: It really depends on the system. Most of our systems run anywhere from 10-25ms. I find that any more than that, Vacuum takes too long. How do you measure the impact of setting it to 12 as opposed to 15? ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
