Thread

1. pg_dump 9.1.1 hanging (collectSecLabels gets 0 labels)

   Steve Singer <ssinger@ca.afilias.info> — 2011-11-09T22:59:59Z

   We have a cluster running 9.1.1 where pg_dump hangs when we try to dump 
   some a database inside of the cluster.  The server is running AIX.
   
   I can see this on clean cluster where we do an initdb, followed by a 
   createdb and try running pg_dump.
   
   I've tracked the issue down to collectSecLabels in pg_dump.c
   
   SELECT label, provider, classoid, objoid, objsbid FROM 
   pg_catalog.pg_seclabel;
   
   returns 0 rows.
   
   The code in collectSecLabels() is not prepared to deal with a zero row 
   result and tries to malloc 0 bytes.
   
   I am not yet sure if the problem is that my pg_seclabel is empty or if 
   the issue is in collectSecLabels() or if collectSecLabels shouldn't even 
   be called.
   
   Has anyone seen something similar?
   
   

2. Re: pg_dump 9.1.1 hanging (collectSecLabels gets 0 labels)

   Tom Lane <tgl@sss.pgh.pa.us> — 2011-11-09T23:35:00Z

   Steve Singer <ssinger@ca.afilias.info> writes:
   > I've tracked the issue down to collectSecLabels in pg_dump.c
   
   > SELECT label, provider, classoid, objoid, objsbid FROM 
   > pg_catalog.pg_seclabel;
   
   > returns 0 rows.
   
   > The code in collectSecLabels() is not prepared to deal with a zero row 
   > result and tries to malloc 0 bytes.
   
   pg_seclabel is almost always empty, so I'm not convinced that you've
   identified your problem correctly.
   
   			regards, tom lane
   
   

3. Re: pg_dump 9.1.1 hanging (collectSecLabels gets 0 labels)

   Steve Singer <ssinger@ca.afilias.info> — 2011-11-10T18:13:10Z

   On 11-11-09 06:35 PM, Tom Lane wrote:
   > Steve Singer<ssinger@ca.afilias.info>  writes:
   >> I've tracked the issue down to collectSecLabels in pg_dump.c
   >
   >> SELECT label, provider, classoid, objoid, objsbid FROM
   >> pg_catalog.pg_seclabel;
   >
   >> returns 0 rows.
   >
   >> The code in collectSecLabels() is not prepared to deal with a zero row
   >> result and tries to malloc 0 bytes.
   >
   > pg_seclabel is almost always empty, so I'm not convinced that you've
   > identified your problem correctly.
   >
   > 			regards, tom lane
   >
   
   The attached patch seems to fix the issue.
   
   The man page for malloc on AIX is pretty clear on what happens when you 
   try to malloc 0 bytes.  It returns NULL.
   

4. Re: pg_dump 9.1.1 hanging (collectSecLabels gets 0 labels)

   Tom Lane <tgl@sss.pgh.pa.us> — 2011-11-10T19:00:33Z

   Steve Singer <ssinger@ca.afilias.info> writes:
   > The man page for malloc on AIX is pretty clear on what happens when you 
   > try to malloc 0 bytes.  It returns NULL.
   
   Yes, that's a pretty common behavior for malloc(0).  It should not cause
   a problem here AFAICS.
   
   ... Oh, I see, the problem is that &labels[-1] might not compare to
   &labels[0] the way we want.  I think only the first hunk of your
   patch is actually necessary.
   
   			regards, tom lane
   
   

5. Re: pg_dump 9.1.1 hanging (collectSecLabels gets 0 labels)

   Steve Singer <ssinger@ca.afilias.info> — 2011-11-10T19:52:03Z

   On 11-11-10 02:00 PM, Tom Lane wrote:
   > Steve Singer<ssinger@ca.afilias.info>  writes:
   >> The man page for malloc on AIX is pretty clear on what happens when you
   >> try to malloc 0 bytes.  It returns NULL.
   >
   > Yes, that's a pretty common behavior for malloc(0).  It should not cause
   > a problem here AFAICS.
   >
   > ... Oh, I see, the problem is that&labels[-1] might not compare to
   > &labels[0] the way we want.  I think only the first hunk of your
   > patch is actually necessary.
   >
   > 			regards, tom lane
   >
   
   Yes the problem is still fixed if I only apply the first hunk.
   
   
   
   

6. Re: pg_dump 9.1.1 hanging (collectSecLabels gets 0 labels)

   Tom Lane <tgl@sss.pgh.pa.us> — 2011-11-10T20:08:12Z

   Steve Singer <ssinger@ca.afilias.info> writes:
   > On 11-11-10 02:00 PM, Tom Lane wrote:
   >> ... Oh, I see, the problem is that&labels[-1] might not compare to
   >> &labels[0] the way we want.  I think only the first hunk of your
   >> patch is actually necessary.
   
   > Yes the problem is still fixed if I only apply the first hunk.
   
   OK, everything seems satisfactorily explained then.  Will commit the
   fix, thanks for the report!
   
   			regards, tom lane