* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 7 May 2016 at 16:21, Stephen Frost wrote:
> > * Simon Riggs (si...@2ndquadrant.com) wrote:
> > > On 7 May 2016 at 16:14, Stephen Frost wrote:
> > > > > If we don't lock it then we will have a inconsistent dump that will
> > fail
> > > > > later, i
On 7 May 2016 at 16:21, Stephen Frost wrote:
> * Simon Riggs (si...@2ndquadrant.com) wrote:
> > On 7 May 2016 at 16:14, Stephen Frost wrote:
> > > > If we don't lock it then we will have a inconsistent dump that will
> fail
> > > > later, if dumped while an object is being dropped.
> > > > Do we
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 7 May 2016 at 16:14, Stephen Frost wrote:
> > > If we don't lock it then we will have a inconsistent dump that will fail
> > > later, if dumped while an object is being dropped.
> > > Do we want an inconsistent dump?
> >
> > The dump won't be incon
On 7 May 2016 at 16:14, Stephen Frost wrote:
> > If we don't lock it then we will have a inconsistent dump that will fail
> > later, if dumped while an object is being dropped.
> > Do we want an inconsistent dump?
>
> The dump won't be inconsistent, as Tom pointed out. The catalog tables
> are
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 4 May 2016 at 16:45, Tom Lane wrote:
> > Why is it that we need to lock a table at all if we're just going to dump
> > its ACL?
>
> We don't, but surely that's the wrong question.
I tend to agree with this, however...
> If we don't lock
On 4 May 2016 at 16:45, Tom Lane wrote:
> Why is it that we need to lock a table at all if we're just going to dump
> its ACL?
We don't, but surely that's the wrong question.
If we don't lock it then we will have a inconsistent dump that will fail
later, if dumped while an object is being dro
On Thu, May 5, 2016 at 5:35 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > Attached patch implements this change to not LOCK the table in cases
> > > where we don't need to. I'll push this with my other changes to
> pg_dump
> > > tomorrow (and
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Attached patch implements this change to not LOCK the table in cases
> > where we don't need to. I'll push this with my other changes to pg_dump
> > tomorrow (and I've included it in an updated, complete, set of patches
> > sent o
Stephen Frost writes:
> Attached patch implements this change to not LOCK the table in cases
> where we don't need to. I'll push this with my other changes to pg_dump
> tomorrow (and I've included it in an updated, complete, set of patches
> sent on the thread where those changes were being discu
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Seems reasonable otherwise.
Attached patch implements this change to not LOCK the table in cases
where we don't need to. I'll push this with my other changes to pg_dump
tomorrow (and I've included it in an updated, complete, set of patches
sent on the thre
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > - USERMAP
>
> > Uses pg_options_to_table(), but I don't think that actually uses
> > SysCache at all, it's just taking the array provided and builds a
> > table out of it, so I think this case is ok.
>
> USERMAP seems a bit
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Why is it that we need to lock a table at all if we're just going to dump
>> its ACL?
> I think I'm coming around to agree with that, but it seems like it'd be
> better to look at each component and say "we know X is safe, so we wo
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Why is it that we need to lock a table at all if we're just going to dump
> its ACL? I understand the failure modes that motivate locking when we're
> going to dump data or schema, but the ACL is not really subject to that
> kind of problem: we are going to
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> But in Rushabh's example, he's not doing that. He's trying to do a
>> full-database dump of a database that contains one object which the
>> dump user has rights to access. Previously, that worked. Now, it
>> fails with an
On Wed, May 4, 2016 at 9:35 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, May 4, 2016 at 5:29 AM, Stephen Frost wrote:
>> > There is no such limitation on using pg_dump as a non-superuser. It's
>> > always been the case that you need to be able to LOCK the ta
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, May 4, 2016 at 5:29 AM, Stephen Frost wrote:
> > There is no such limitation on using pg_dump as a non-superuser. It's
> > always been the case that you need to be able to LOCK the table that
> > you're dumping. If you don't have ri
On Wed, May 4, 2016 at 5:29 AM, Stephen Frost wrote:
> There is no such limitation on using pg_dump as a non-superuser. It's
> always been the case that you need to be able to LOCK the table that
> you're dumping. If you don't have rights to LOCK a certain table then
> pg_dump is going to throw
Rushabh,
* Rushabh Lathia (rushabh.lat...@gmail.com) wrote:
> On Tue, May 3, 2016 at 8:34 PM, Stephen Frost wrote:
>
> > * Rushabh Lathia (rushabh.lat...@gmail.com) wrote:
> > > With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
> > > bitmap
> > > to represent what to inclu
On Tue, May 3, 2016 at 8:34 PM, Stephen Frost wrote:
> * Rushabh Lathia (rushabh.lat...@gmail.com) wrote:
> > With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
> > bitmap
> > to represent what to include. With this commit if non-super user is
> unable
> > to perform the dum
On Tue, May 3, 2016 at 10:57 AM, Stephen Frost wrote:
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
>> On 3 May 2016 at 19:04, Rushabh Lathia wrote:
>>
>> > With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
>> > bitmap
>> > to represent what to include. With this commit i
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, May 3, 2016 at 10:57 AM, Stephen Frost wrote:
> > * Craig Ringer (cr...@2ndquadrant.com) wrote:
> >> On 3 May 2016 at 19:04, Rushabh Lathia wrote:
> >>
> >> > With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
> >> > bit
* Rushabh Lathia (rushabh.lat...@gmail.com) wrote:
> With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
> bitmap
> to represent what to include. With this commit if non-super user is unable
> to perform the dump.
[...]
> pg_dump: [archiver (db)] query was: LOCK TABLE pg_catalo
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 3 May 2016 at 19:04, Rushabh Lathia wrote:
>
> > With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
> > bitmap
> > to represent what to include. With this commit if non-super user is unable
> > to perform the dump.
> >
>
>
On 3 May 2016 at 19:04, Rushabh Lathia wrote:
> With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
> bitmap
> to represent what to include. With this commit if non-super user is unable
> to perform the dump.
>
Hm. I think we need a src/bin/pg_dump/t/ test for the TAP suite
With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
bitmap
to represent what to include. With this commit if non-super user is unable
to perform the dump.
Consider the below testcase:
postgres=# select version();
version
--
25 matches
Mail list logo
