Thread

  1. Remove support for 'userlocks'?

    Bruce Momjian <bruce@momjian.us> — 2011-06-03T18:01:41Z

    According to our documentation, 'userlocks' were removed in PG 8.2:
    
    	http://developer.postgresql.org/pgdocs/postgres/runtime-config-developer.html
    
    	trace_userlocks (boolean)
    	
    	If on, emit information about user lock usage. Output is the same as
    	for trace_locks, only for user locks.
    	
    	User locks were removed as of PostgreSQL version 8.2. This option
    	currently has no effect.
    	
    	This parameter is only available if the LOCK_DEBUG macro was defined
    	when PostgreSQL was compiled.
    
    Should we remove this parameter and the supporting code since pre-8.2 is
    now end-of-life?
    
    --
      Bruce Momjian  <bruce@momjian.us>        http://momjian.us
      EnterpriseDB                             http://enterprisedb.com
    
      + It's impossible for everything to be true. +
    
    
  2. Re: Remove support for 'userlocks'?

    Merlin Moncure <mmoncure@gmail.com> — 2011-06-03T18:22:35Z

    On Fri, Jun 3, 2011 at 1:01 PM, Bruce Momjian <bruce@momjian.us> wrote:
    > According to our documentation, 'userlocks' were removed in PG 8.2:
    >
    >        http://developer.postgresql.org/pgdocs/postgres/runtime-config-developer.html
    >
    >        trace_userlocks (boolean)
    >
    >        If on, emit information about user lock usage. Output is the same as
    >        for trace_locks, only for user locks.
    >
    >        User locks were removed as of PostgreSQL version 8.2. This option
    >        currently has no effect.
    >
    >        This parameter is only available if the LOCK_DEBUG macro was defined
    >        when PostgreSQL was compiled.
    >
    > Should we remove this parameter and the supporting code since pre-8.2 is
    > now end-of-life?
    
    hm, shouldn't it be replaced with trace_advisory_locks?
    
    merlin
    
    
  3. Re: Remove support for 'userlocks'?

    Josh Berkus <josh@agliodbs.com> — 2011-06-03T23:41:04Z

    On 6/3/11 11:01 AM, Bruce Momjian wrote:
    > According to our documentation, 'userlocks' were removed in PG 8.2:
    > 
    > 	http://developer.postgresql.org/pgdocs/postgres/runtime-config-developer.html
    
    I take it this doesn't trace advisory locks, and trace_locks does?
    
    If so, then by all means remove the code.  I highly doubt anyone is
    using that option anyway ...
    
    -- 
    Josh Berkus
    PostgreSQL Experts Inc.
    http://pgexperts.com
    
    
  4. Re: Remove support for 'userlocks'?

    Bruce Momjian <bruce@momjian.us> — 2011-06-04T02:12:10Z

    Josh Berkus wrote:
    > On 6/3/11 11:01 AM, Bruce Momjian wrote:
    > > According to our documentation, 'userlocks' were removed in PG 8.2:
    > > 
    > > 	http://developer.postgresql.org/pgdocs/postgres/runtime-config-developer.html
    > 
    > I take it this doesn't trace advisory locks, and trace_locks does?
    > 
    > If so, then by all means remove the code.  I highly doubt anyone is
    > using that option anyway ...
    
    OK, that is something I will do for 9.2.
    
    -- 
      Bruce Momjian  <bruce@momjian.us>        http://momjian.us
      EnterpriseDB                             http://enterprisedb.com
    
      + It's impossible for everything to be true. +
    
    
  5. Re: Remove support for 'userlocks'?

    Bruce Momjian <bruce@momjian.us> — 2011-10-14T00:00:13Z

    Josh Berkus wrote:
    > On 6/3/11 11:01 AM, Bruce Momjian wrote:
    > > According to our documentation, 'userlocks' were removed in PG 8.2:
    > > 
    > > 	http://developer.postgresql.org/pgdocs/postgres/runtime-config-developer.html
    > 
    > I take it this doesn't trace advisory locks, and trace_locks does?
    > 
    > If so, then by all means remove the code.  I highly doubt anyone is
    > using that option anyway ...
    
    The attached, applied patch removes all "traces" of trace_userlocks.
    
    -- 
      Bruce Momjian  <bruce@momjian.us>        http://momjian.us
      EnterpriseDB                             http://enterprisedb.com
    
      + It's impossible for everything to be true. +