Thread

  1. Weird pg_dumpall bug?

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2006-01-24T08:21:47Z

    I did a dump of a 7.4.11 database using the 8.1.2 pg_dumpall.  I got 
    this at the top of the dump:
    
    ...
    ...
    CREATE ROLE support;
    ALTER ROLE support WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB 
    LOGIN PASSWORD 'md5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx';
    ...
    ...
    CREATE ROLE support;
    ALTER ROLE support WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN;
    ...
    ...
    
    It dumped the "support" role twice!
    
    Any ideas?
    
    Hmmmm...actually.  It's because I have a user called 'support' and a 
    group called 'support'.
    
    Seems like it needs a fix...
    
    Chris
    
    
    
  2. Re: Weird pg_dumpall bug?

    Stephen Frost <sfrost@snowman.net> — 2006-01-24T14:44:55Z

    * Christopher Kings-Lynne (chriskl@familyhealth.com.au) wrote:
    > Hmmmm...actually.  It's because I have a user called 'support' and a 
    > group called 'support'.
    > 
    > Seems like it needs a fix...
    
    Have you got a suggestion on just how to fix it...?  Debian's
    pg_upgradecluster bails out with an error when it discovers this
    situation but I don't think it'd be sensible for pg_dump to do that...
    
    	Thanks,
    
    		Stephen
    
  3. Re: Weird pg_dumpall bug?

    Andrew Dunstan <andrew@dunslane.net> — 2006-01-24T15:04:30Z

    On Tue, 2006-01-24 at 09:44 -0500, Stephen Frost wrote:
    > * Christopher Kings-Lynne (chriskl@familyhealth.com.au) wrote:
    > > Hmmmm...actually.  It's because I have a user called 'support' and a 
    > > group called 'support'.
    > > 
    > > Seems like it needs a fix...
    > 
    > Have you got a suggestion on just how to fix it...?  Debian's
    > pg_upgradecluster bails out with an error when it discovers this
    > situation but I don't think it'd be sensible for pg_dump to do that...
    > 
    
    
    How about an option to map groups whose names conflict with user names
    using a prefix mechanism? 
    
    e.g. --map-conflicting-groups=gr_
    
    Then in Christopher's example his support group would become the role
    gr_support.
    
    Just a thought.
    
    cheers
    
    andrew
    
    
    
  4. Re: Weird pg_dumpall bug?

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-01-24T15:05:43Z

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
    > Hmmmm...actually.  It's because I have a user called 'support' and a 
    > group called 'support'.
    
    This was discussed already.  It's a corner case we didn't really think
    about while designing roles.  It's possible to support this: the group
    and the user will now really be the same entity, ie a role that has both
    its own login privileges and members.  However pg_dump isn't doing the
    right things to make the old situation morph into the new one.  Want to
    write a patch?
    
    			regards, tom lane
    
    
  5. Re: Weird pg_dumpall bug?

    Andrew Dunstan <andrew@dunslane.net> — 2006-01-24T15:38:47Z

    On Tue, 2006-01-24 at 10:05 -0500, Tom Lane wrote:
    > Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
    > > Hmmmm...actually.  It's because I have a user called 'support' and a 
    > > group called 'support'.
    > 
    > It's possible to support this: the group
    > and the user will now really be the same entity, ie a role that has both
    > its own login privileges and members.  
    > 
    
    
    Assuming you actually want to unify the two objects. That might well be
    the common case, but will it always be true?
    
    cheers
    
    andrew
    
    
    
  6. Re: Weird pg_dumpall bug?

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-01-24T15:42:17Z

    Andrew Dunstan <andrew@dunslane.net> writes:
    > On Tue, 2006-01-24 at 10:05 -0500, Tom Lane wrote:
    >> It's possible to support this: the group
    >> and the user will now really be the same entity, ie a role that has both
    >> its own login privileges and members.  
    
    > Assuming you actually want to unify the two objects. That might well be
    > the common case, but will it always be true?
    
    As compared to what?  I didn't like the notion of auto-renaming one of
    the roles, if that's what you're suggesting.  That seems well outside
    pg_dump's charter.
    
    			regards, tom lane
    
    
  7. Re: Weird pg_dumpall bug?

    Peter Eisentraut <peter_e@gmx.net> — 2006-01-24T15:59:27Z

    Am Dienstag, 24. Januar 2006 15:44 schrieb Stephen Frost:
    > Have you got a suggestion on just how to fix it...?  Debian's
    > pg_upgradecluster bails out with an error when it discovers this
    > situation but I don't think it'd be sensible for pg_dump to do that...
    
    Why not?  If the backup cannot be made in a way such that the semantics of the 
    restored database are the same, it shouldn't do it.
    
    -- 
    Peter Eisentraut
    http://developer.postgresql.org/~petere/
    
    
  8. Re: Weird pg_dumpall bug?

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-01-24T17:00:47Z

    Peter Eisentraut <peter_e@gmx.net> writes:
    > Am Dienstag, 24. Januar 2006 15:44 schrieb Stephen Frost:
    >> Have you got a suggestion on just how to fix it...?  Debian's
    >> pg_upgradecluster bails out with an error when it discovers this
    >> situation but I don't think it'd be sensible for pg_dump to do that...
    
    > Why not?  If the backup cannot be made in a way such that the
    > semantics of the restored database are the same, it shouldn't do it.
    
    If you take a hard line on that position, then it's not necessary for
    pg_dump to support cross-version operation at all, because no major
    PG release is ever 100.0% compatible with the previous one.
    
    What is actually required of pg_dump is that it produce the closest
    approximation it can get to the old behavior within the context of the
    new version's semantics.  I can easily cite half a dozen examples of
    cases where we've applied this logic in previous versions.  I do not
    see a reason to treat this case differently.  The difference between
    a single role acting as both user and group and the prior behavior of
    separate objects is certainly well within the "fuzz factor" that we've
    allowed pg_dump to have in the past.
    
    			regards, tom lane
    
    
  9. Re: Weird pg_dumpall bug?

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2006-01-25T01:23:31Z

    > How about an option to map groups whose names conflict with user names
    > using a prefix mechanism? 
    > 
    > e.g. --map-conflicting-groups=gr_
    > 
    > Then in Christopher's example his support group would become the role
    > gr_support.
    
    No bad, have to change some application code then as well...
    
    Chris
    
    
    
  10. Re: Weird pg_dumpall bug?

    Jim Nasby <jnasby@pervasive.com> — 2006-01-25T02:54:27Z

    On Tue, Jan 24, 2006 at 10:42:17AM -0500, Tom Lane wrote:
    > Andrew Dunstan <andrew@dunslane.net> writes:
    > > On Tue, 2006-01-24 at 10:05 -0500, Tom Lane wrote:
    > >> It's possible to support this: the group
    > >> and the user will now really be the same entity, ie a role that has both
    > >> its own login privileges and members.  
    > 
    > > Assuming you actually want to unify the two objects. That might well be
    > > the common case, but will it always be true?
    > 
    > As compared to what?  I didn't like the notion of auto-renaming one of
    > the roles, if that's what you're suggesting.  That seems well outside
    > pg_dump's charter.
    
    If you want something renamed, you can handle that case by just renaming
    it before you do the dump, but it would be nice if pg_dump would raise a
    nice big warning when this condition exists so you're aware of it. Or
    maybe even refuse to run unless you supply some command line option to
    over-ride.
    
    I don't think we should morph the two together by default either,
    because that's very possibly not what the user originally intended.
    -- 
    Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
    Pervasive Software      http://pervasive.com    work: 512-231-6117
    vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461