Remove behaviour of postmaster -o

Started by Andy Chambersover 19 years ago5 messages
#1Andy Chambers
andychambers2002@yahoo.co.uk
1 attachment(s)

The first item on the todo list is "remove behaviour
of postmaster -o". Does that simply mean remove the
option and the associated processing from
postmaster.c?

Is anyone working on this?

I've attached a naive patch that does what I've
described above. It compiles and passes the test
script in the tools directory. Is there anything else
this todo should address?

Thanks,
Andy

___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Attachments:

rm_o_option.patchtext/x-diff; name=rm_o_option.patchDownload
*** ./src/backend/postmaster/postmaster.c.orig	2006-05-06 11:26:58.000000000 +0100
--- ./src/backend/postmaster/postmaster.c	2006-05-06 11:42:20.000000000 +0100
***************
*** 175,184 ****
  #define MAXLISTEN	64
  static int	ListenSocket[MAXLISTEN];
  
- /*
-  * Set by the -o option
-  */
- static char ExtraOptions[MAXPGPATH];
  
  /*
   * These globals control the behavior of the postmaster in case some
--- 175,180 ----
***************
*** 346,352 ****
  #endif
  	char		my_exec_path[MAXPGPATH];
  	char		pkglib_path[MAXPGPATH];
- 	char		ExtraOptions[MAXPGPATH];
  	char		lc_collate[LOCALE_NAME_BUFLEN];
  	char		lc_ctype[LOCALE_NAME_BUFLEN];
  }	BackendParameters;
--- 342,347 ----
***************
*** 517,529 ****
  				SetConfigOption("allow_system_table_mods", "true", PGC_POSTMASTER, PGC_S_ARGV);
  				break;
  
- 			case 'o':
- 				/* Other options to pass to the backend on the command line */
- 				snprintf(ExtraOptions + strlen(ExtraOptions),
- 						 sizeof(ExtraOptions) - strlen(ExtraOptions),
- 						 " %s", optarg);
- 				break;
- 
  			case 'P':
  				SetConfigOption("ignore_system_indexes", "true", PGC_POSTMASTER, PGC_S_ARGV);
  				break;
--- 512,517 ----
***************
*** 1158,1164 ****
  	printf(_("  -l              enable SSL connections\n"));
  #endif
  	printf(_("  -N MAX-CONNECT  maximum number of allowed connections\n"));
- 	printf(_("  -o OPTIONS      pass \"OPTIONS\" to each server process (obsolete)\n"));
  	printf(_("  -p PORT         port number to listen on\n"));
  	printf(_("  -s              show statistics after each query\n"));
  	printf(_("  -S WORK-MEM     set amount of memory for sorts (in kB)\n"));
--- 1146,1151 ----
***************
*** 2844,2856 ****
  	 *		postgres [secure switches] -y databasename [insecure switches]
  	 * where the switches after -y come from the client request.
  	 *
- 	 * The maximum possible number of commandline arguments that could come
- 	 * from ExtraOptions or port->cmdline_options is (strlen + 1) / 2; see
- 	 * split_opts().
  	 * ----------------
  	 */
  	maxac = 10;					/* for fixed args supplied below */
- 	maxac += (strlen(ExtraOptions) + 1) / 2;
  	if (port->cmdline_options)
  		maxac += (strlen(port->cmdline_options) + 1) / 2;
  
--- 2831,2839 ----
***************
*** 2860,2872 ****
  
  	av[ac++] = "postgres";
  
- 	/*
- 	 * Pass any backend switches specified with -o in the postmaster's own
- 	 * command line.  We assume these are secure.  (It's OK to mangle
- 	 * ExtraOptions now, since we're safely inside a subprocess.)
- 	 */
- 	split_opts(av, &ac, ExtraOptions);
- 
  	/* Tell the backend what protocol the frontend is using. */
  	snprintf(protobuf, sizeof(protobuf), "-v%u", port->proto);
  	av[ac++] = protobuf;
--- 2843,2848 ----
***************
*** 3815,3822 ****
  
  	StrNCpy(param->pkglib_path, pkglib_path, MAXPGPATH);
  
- 	StrNCpy(param->ExtraOptions, ExtraOptions, MAXPGPATH);
- 
  	StrNCpy(param->lc_collate, setlocale(LC_COLLATE, NULL), LOCALE_NAME_BUFLEN);
  	StrNCpy(param->lc_ctype, setlocale(LC_CTYPE, NULL), LOCALE_NAME_BUFLEN);
  
--- 3791,3796 ----
***************
*** 4018,4025 ****
  
  	StrNCpy(pkglib_path, param->pkglib_path, MAXPGPATH);
  
- 	StrNCpy(ExtraOptions, param->ExtraOptions, MAXPGPATH);
- 
  	setlocale(LC_COLLATE, param->lc_collate);
  	setlocale(LC_CTYPE, param->lc_ctype);
  }
--- 3992,3997 ----
#2Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Andy Chambers (#1)
Re: Remove behaviour of postmaster -o

Andy Chambers wrote:

The first item on the todo list is "remove behaviour
of postmaster -o". Does that simply mean remove the
option and the associated processing from
postmaster.c?

Is anyone working on this?

I've attached a naive patch that does what I've
described above. It compiles and passes the test
script in the tools directory. Is there anything else
this todo should address?

I thought Peter was working on this. Peter?

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andy Chambers (#1)
Re: Remove behaviour of postmaster -o

Andy Chambers <andychambers2002@yahoo.co.uk> writes:

The first item on the todo list is "remove behaviour
of postmaster -o". Does that simply mean remove the
option and the associated processing from
postmaster.c?

No, it means something closer to this:

http://archives.postgresql.org/pgsql-hackers/2005-12/msg01031.php

http://archives.postgresql.org/pgsql-patches/2006-01/msg00239.php

Not sure why Peter didn't continue working on it.

regards, tom lane

#4Peter Eisentraut
peter_e@gmx.net
In reply to: Tom Lane (#3)
Re: Remove behaviour of postmaster -o

Tom Lane wrote:

http://archives.postgresql.org/pgsql-patches/2006-01/msg00239.php

Not sure why Peter didn't continue working on it.

I'm still working on the postmaster/postgres merge. But the behavior of
postmaster -o is not going to be removed. That TODO item might be
appropriate in a release or three at best.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#4)
Re: Remove behaviour of postmaster -o

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane wrote:

Not sure why Peter didn't continue working on it.

I'm still working on the postmaster/postgres merge. But the behavior of
postmaster -o is not going to be removed. That TODO item might be
appropriate in a release or three at best.

I think the point though is that -o becomes a no-op: whether you put -o
in front of some options won't matter anymore, because they'll be
interpreted the same either way.

regards, tom lane