Re: [HACKERS] Custom variable class segmentation fault

[Andrew Dunstan]

Tom Lane wrote:

BTW, do I need to mention that the plperl patch is breaking the
buildfarm again?


  


No :-) See my  comments from about an hour ago. It needs to be removed also.

cheers

andrew

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Custom variable class segmentation fault

[Tom Lane]

Michael Fuhr <[EMAIL PROTECTED]> writes:
> The latest HEAD is segfaulting on startup if I have the following
> lines in postgresql.conf:

> custom_variable_classes = 'plperl'
> plperl.use_strict = on

Bruce, please re-revert that GUC patch and don't put it back in until
someone like Peter or me has actually reviewed it.  My faith in it has
gone to zero, and I don't think you are able to fix it either.

BTW, do I need to mention that the plperl patch is breaking the
buildfarm again?

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Custom variable class segmentation fault

[Bruce Momjian]

Michael Fuhr wrote:
> The latest HEAD is segfaulting on startup if I have the following
> lines in postgresql.conf:
> 
> custom_variable_classes = 'plperl'
> plperl.use_strict = on
> 
> If I comment out the second line then the server starts successfully.
> Platform is Solaris 9/sparc.
> 
> (gdb) bt
> #0  0xff0340a0 in strcmp () from /usr/lib/libc.so.1
> #1  0x00257504 in verify_config_option (name=0x0, value=0x397258 "on", 
> context=PGC_POSTMASTER, source=PGC_S_FILE, isNewEqual=0xffbff2cb "\001", 
> isContextOK=0xffbff2ca "\001\001") at guc.c:5513
> #2  0x0025d3b4 in ProcessConfigFile (context=PGC_POSTMASTER) at guc-file.l:152
> #3  0x0025d80c in SelectConfigFiles (userDoption=0x1  bounds>, progname=0x390610 "postgres") at guc.c:2867
> #4  0x0019a450 in PostmasterMain (argc=5, argv=0x391240) at postmaster.c:602
> #5  0x001518c8 in main (argc=5, argv=0x391240) at main.c:187

Thanks for the report.  This attached, applied patch fixes it.  The
problem was that custom variables have _no_ default value for strings on
startup, and the checking code was being too agressive.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: src/backend/utils/misc/guc.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.339
diff -c -c -r1.339 guc.c
*** src/backend/utils/misc/guc.c	13 Aug 2006 02:22:24 -	1.339
--- src/backend/utils/misc/guc.c	13 Aug 2006 15:34:13 -
***
*** 5512,5518 
  		{
  			struct config_string *conf = (struct config_string *) record;
  
! 			return strcmp(*conf->variable, newvalue) == 0;
  		}
  	}
  
--- 5512,5521 
  		{
  			struct config_string *conf = (struct config_string *) record;
  
! 			if (!*conf->variable)	/* custom variable with no value yet */
! return false;
! 			else
! return strcmp(*conf->variable, newvalue) == 0;
  		}
  	}
  

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org