From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Spiteri <alexander(at)spiteri(dot)org> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14009: pg_restore not restoring privilegs when one login/group role is missing |
Date: | 2016-03-10 16:24:54 |
Message-ID: | 4509.1457627094@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alexander Spiteri <alexander(at)spiteri(dot)org> writes:
> Please find a test case attached. I tried to put as much detail as i could.
Okay, I see what's going on. I really doubt that there is a regression
here from 8.4 though. I will bet that the difference is you used plain
text output from pg_dump back in 8.4, and now in 9.5 you are trying to
use pg_restore direct-to-database mode.
The proximate cause of the problem is that pg_dump bundles up GRANT/REVOKE
statements for any object into a single "ACL" entry in the archive file.
If you dump to SQL text this doesn't matter because it just looks like a
stream of separate statements. But if pg_restore is trying to restore
direct to database then it issues the whole text of each archive file
entry as a single PQexec() operation, which means that an error in one
statement in that string causes the rest of 'em to be skipped.
As a short-term workaround you could try restoring in this way:
pg_restore foo.dump | psql
To really fix it, I think we'd need either to expand "ACL" archive entries
into a separate entry for each target user, or to change pg_restore to
parse the entry contents into separate statements. The latter seems
messy and bug-prone. The former solution wouldn't fix the problem
for dumps from existing pg_dump versions; but on the other hand, it might
provide additional flexibility for selective restores, so I'm not sure
that it's a bad idea going forward.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Rich Schaaf | 2016-03-10 19:44:39 | Bad interaction between pg_dump/pg_restore and table inheritance |
Previous Message | David G. Johnston | 2016-03-10 16:06:36 | Re: Performance Improvement in SQL |