This patch has been marked Waiting on Author since early March, with the thread
stalled since then. I'm marking this CF entry Returned with Feedback, please
feel free to resubmit it if/when a new version of the patch is available.
--
Daniel Gustafsson https://vmware.com/
On Thu, Feb 11, 2021 at 08:16:30PM +0300, Anastasia Lubennikova wrote:
> On 28.01.2021 09:55, Noah Misch wrote:
> >On Wed, Jan 27, 2021 at 07:32:42PM +0300, Anastasia Lubennikova wrote:
> >>On 27.01.2021 14:21, Noah Misch wrote:
> >>>On Mon, Jan 25, 2021 at 10:14:43PM +0300, Anastasia Lubennikova w
On Wed, Jan 27, 2021 at 07:32:42PM +0300, Anastasia Lubennikova wrote:
> On 27.01.2021 14:21, Noah Misch wrote:
> >On Mon, Jan 25, 2021 at 10:14:43PM +0300, Anastasia Lubennikova wrote:
> >
> >>1) Could you please clarify, what do you mean by REVOKE failures?
> >>
> >>I tried following example:
> >
On Mon, Jan 25, 2021 at 10:14:43PM +0300, Anastasia Lubennikova wrote:
> On 24.01.2021 11:39, Noah Misch wrote:
> >On Thu, Jan 21, 2021 at 01:03:58AM +0300, Anastasia Lubennikova wrote:
> >>On 03.01.2021 14:29, Noah Misch wrote:
> >>>Overall, this patch predicts a subset of cases where pg_dump will
On 24.01.2021 11:39, Noah Misch wrote:
On Thu, Jan 21, 2021 at 01:03:58AM +0300, Anastasia Lubennikova wrote:
On 03.01.2021 14:29, Noah Misch wrote:
Overall, this patch predicts a subset of cases where pg_dump will emit a
failing GRANT or REVOKE that targets a pg_catalog object. Can you write
On Thu, Jan 21, 2021 at 01:03:58AM +0300, Anastasia Lubennikova wrote:
> On 03.01.2021 14:29, Noah Misch wrote:
> >Overall, this patch predicts a subset of cases where pg_dump will emit a
> >failing GRANT or REVOKE that targets a pg_catalog object. Can you write a
> >code comment stating what it d
On Thu, Jan 21, 2021 at 01:03:58AM +0300, Anastasia Lubennikova wrote:
> On 03.01.2021 14:29, Noah Misch wrote:
> >On Thu, Jun 11, 2020 at 07:58:43PM +0300, Anastasia Lubennikova wrote:
> Thank you for the review.
> New version of the patch is attached, though I haven't tested it properly
> yet. I
On 03.01.2021 14:29, Noah Misch wrote:
On Thu, Jun 11, 2020 at 07:58:43PM +0300, Anastasia Lubennikova wrote:
On 08.06.2020 19:31, Alvaro Herrera wrote:
I'm thinking what's a good way to have a test that's committable. Maybe
it would work to add a TAP test to pg_upgrade that runs initdb, does
On Thu, Jun 11, 2020 at 07:58:43PM +0300, Anastasia Lubennikova wrote:
> On 08.06.2020 19:31, Alvaro Herrera wrote:
> >I'm thinking what's a good way to have a test that's committable. Maybe
> >it would work to add a TAP test to pg_upgrade that runs initdb, does a
> >few GRANTS as per your attachm
Tested this patch by running several upgrades from different major
versions and different setups.
ACL, that are impossible to apply, are detected and reported, so it
looks good for me.
On Thu, Jun 11, 2020 at 07:58:43PM +0300, Anastasia Lubennikova wrote:
> I would be glad to add some test, but it seems to me that the infrastructure
> changes for cross-version pg_upgrade test is much more complicated task than
> this modest bugfix. Besides, I've read the discussion and it seems
On 08.06.2020 19:31, Alvaro Herrera wrote:
On 2020-Jun-08, Anastasia Lubennikova wrote:
In this version I rebased test patches, added some more comments, fixed
memory allocation issue and also removed code that handles ACLs on
languages. They require a lot of specific handling, while I doubt t
On 2020-Jun-08, Anastasia Lubennikova wrote:
> In this version I rebased test patches, added some more comments, fixed
> memory allocation issue and also removed code that handles ACLs on
> languages. They require a lot of specific handling, while I doubt that their
> signatures, which consist of
On 06.04.2020 19:40, Anastasia Lubennikova wrote:
On 06.04.2020 16:49, Anastasia Lubennikova wrote:
New version of the patch is attached. I fixed several issues in the
check_for_changed_signatures().
Now it passes check without "test_rename_catalog_objects" and fails
(generates script) with i
On 06.04.2020 16:49, Anastasia Lubennikova wrote:
New version of the patch is attached. I fixed several issues in the
check_for_changed_signatures().
Now it passes check without "test_rename_catalog_objects" and fails
(generates script) with it. Test script pg_upgrade_ACL_test.sh
demonstrates
New version of the patch is attached. I fixed several issues in the
check_for_changed_signatures().
Now it passes check without "test_rename_catalog_objects" and fails
(generates script) with it. Test script pg_upgrade_ACL_test.sh
demonstrates this.
The only known issue left is the usage of
On Wed, Mar 25, 2020 at 11:12:05AM +0900, Artur Zakirov wrote:
> Hello David,
>
> On 3/25/2020 2:08 AM, David Steele wrote:
> > On 12/17/19 3:10 AM, Arthur Zakirov wrote:
> > >
> > > I attached new version of the patch. It still uses
> > > pg_identify_object(), I'm not sure about other ways to bu
> On 25 Mar 2020, at 03:12, Artur Zakirov wrote:
> Regression tests fail because cfbot applies
> "test_rename_catalog_objects.patch". Regression tests pass without it.
>
> This patch shouldn't be applied by cfbot. I'm not sure how to do this. But
> maybe it is possible to use different extensi
Hello David,
On 3/25/2020 2:08 AM, David Steele wrote:
On 12/17/19 3:10 AM, Arthur Zakirov wrote:
I attached new version of the patch. It still uses
pg_identify_object(), I'm not sure about other ways to build
identities yet.
This patch applies and builds but fails regression tests on Linu
On 12/17/19 3:10 AM, Arthur Zakirov wrote:
I attached new version of the patch. It still uses pg_identify_object(),
I'm not sure about other ways to build identities yet.
This patch applies and builds but fails regression tests on Linux and
Windows:
https://travis-ci.org/postgresql-cfbot/po
On 17.12.2019 11:10, Arthur Zakirov wrote:
On 2019/12/05 11:31, Michael Paquier wrote:
On Wed, Dec 04, 2019 at 06:15:52PM +0900, Arthur Zakirov wrote:
Ah, I thought that pg_identify_object() gives properly quoted
identity, and
it could be used to make SQL script.
It depends on the object typ
Hello,
On 2019/12/05 11:31, Michael Paquier wrote:
On Wed, Dec 04, 2019 at 06:15:52PM +0900, Arthur Zakirov wrote:
Ah, I thought that pg_identify_object() gives properly quoted identity, and
it could be used to make SQL script.
It depends on the object type. For columns I can see in your pat
On Wed, Dec 04, 2019 at 06:15:52PM +0900, Arthur Zakirov wrote:
> On 2019/12/04 17:15, Michael Paquier wrote:
>> FWIW, I am not much a fan of that part because the output generated by
>> the description is most likely not compatible with the grammar
>> supported.
>
> Ah, I thought that pg_identify
On 2019/12/04 17:15, Michael Paquier wrote:
On Wed, Dec 04, 2019 at 12:17:25PM +0900, Arthur Zakirov wrote:
I updated the patch. It generates "revoke_objects.sql" (similar to v3 patch)
now and doesn't rely on --check option. It also logs still FATAL message
because it seems pg_upgrade should sto
On Wed, Dec 04, 2019 at 12:17:25PM +0900, Arthur Zakirov wrote:
> I updated the patch. It generates "revoke_objects.sql" (similar to v3 patch)
> now and doesn't rely on --check option. It also logs still FATAL message
> because it seems pg_upgrade should stop here since it fails later if there
> ar
On 2019/12/01 23:58, Grigory Smolkin wrote:
On 11/29/19 11:07 AM, Artur Zakirov wrote:
New version of the patch differs from the previous:
- it doesn't generate script to revoke conflicting permissions (but
the patch can be fixed easily)
- generates file incompatible_objects_for_acl.txt to repo
Hello!
On 11/29/19 11:07 AM, Artur Zakirov wrote:
If Anastasia doesn't mind I'd like to send new version of the patch.
On 2019/11/28 12:29, Artur Zakirov wrote:
On 2019/11/27 13:22, Michael Paquier wrote:
Yeah, the actual take is if we want to make the frontend code more
complicated with a la
If Anastasia doesn't mind I'd like to send new version of the patch.
On 2019/11/28 12:29, Artur Zakirov wrote:
On 2019/11/27 13:22, Michael Paquier wrote:
Yeah, the actual take is if we want to make the frontend code more
complicated with a large set of SQL queries to check that each object
ACL
On 2019/11/27 13:22, Michael Paquier wrote:
On Wed, Nov 27, 2019 at 11:35:14AM +0900, Artur Zakirov wrote:
Other approach is similar to Anastasia's patch, which is scanning pg_proc,
pg_class, pg_attribute and others to get modified ACL's and compare it with
initial ACL from pg_init_privs. Next s
On Wed, Nov 27, 2019 at 11:35:14AM +0900, Artur Zakirov wrote:
> I've started to implement new backend function similar to
> pg_describe_object() and tried to make new version of the patch. But I'm
> wondering now if it is possible to backpatch new functions to older
> Postgres releases? pg_upgrad
Thank you for reviews!
On 2019/11/21 17:53, Michael Paquier wrote:
On Fri, Nov 15, 2019 at 11:30:02AM +0300, Grigory Smolkin wrote:
On 11/9/19 5:26 AM, Michael Paquier wrote:
Another question I have: do we need to care more about other extra
ACLs applied to other object types? For example a s
On Thu, Nov 21, 2019 at 05:53:16PM +0900, Michael Paquier wrote:
> Not arguing against the fact that it is useful, but I'd think that it
> is a two-step process, where we need to understand what logic needs to
> be in the backend or some frontend:
> 1) Warn properly about the objects involved, wher
On Fri, Nov 15, 2019 at 11:30:02AM +0300, Grigory Smolkin wrote:
> On 11/9/19 5:26 AM, Michael Paquier wrote:
>> Another question I have: do we need to care more about other extra
>> ACLs applied to other object types? For example a subset of columns
>> on a table with a column being renamed could
HelLo!
On 11/9/19 5:26 AM, Michael Paquier wrote:
On Fri, Nov 08, 2019 at 06:03:06PM +0900, Michael Paquier wrote:
I have begun looking at this one.
Another question I have: do we need to care more about other extra
ACLs applied to other object types? For example a subset of columns
on a tabl
On Fri, Nov 08, 2019 at 06:03:06PM +0900, Michael Paquier wrote:
> I have begun looking at this one.
Another question I have: do we need to care more about other extra
ACLs applied to other object types? For example a subset of columns
on a table with a column being renamed could be an issue. Pr
On Mon, Oct 28, 2019 at 05:40:44PM +0300, Anastasia Lubennikova wrote:
> I added more comments and updated the error message.
> Please, feel free to fix them, if you have any suggestions.
I have begun looking at this one.
+ /* REVOKE command must be executed in corresponding database */
+ if
08.10.2019 17:08, Stephen Frost wrote:
I attached the updated version. Now it prints a better error message
and generates an SQL script instead of multiple warnings. The attached test
script shows that.
Have you tested this with extensions, where the user has changed the
privileges on the extens
Greetings,
* Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
> Cool. It seems that everyone agrees on this patch.
Thanks for working on this, I took a quick look over it and I do have
some concerns.
> I attached the updated version. Now it prints a better error message
> and generate
27.09.2019 15:51, Bruce Momjian wrote:
On Fri, Sep 27, 2019 at 04:22:15PM +0900, Michael Paquier wrote:
On Thu, Sep 26, 2019 at 04:19:38PM -0400, Bruce Momjian wrote:
On Thu, Sep 26, 2019 at 05:16:19PM -0300, Alvaro Herrera wrote:
On 2019-Sep-26, Bruce Momjian wrote:
Well, right now, pg_upgra
On Fri, Sep 27, 2019 at 04:22:15PM +0900, Michael Paquier wrote:
> On Thu, Sep 26, 2019 at 04:19:38PM -0400, Bruce Momjian wrote:
> > On Thu, Sep 26, 2019 at 05:16:19PM -0300, Alvaro Herrera wrote:
> >> On 2019-Sep-26, Bruce Momjian wrote:
> >>> Well, right now, pg_upgrade --check succeeds, but the
On Thu, Sep 26, 2019 at 04:19:38PM -0400, Bruce Momjian wrote:
> On Thu, Sep 26, 2019 at 05:16:19PM -0300, Alvaro Herrera wrote:
>> On 2019-Sep-26, Bruce Momjian wrote:
>>> Well, right now, pg_upgrade --check succeeds, but the upgrade fails. I
>>> am proposing, at a minimum, that pg_upgrade --chec
On Thu, Sep 26, 2019 at 05:16:19PM -0300, Alvaro Herrera wrote:
> On 2019-Sep-26, Bruce Momjian wrote:
> > Well, right now, pg_upgrade --check succeeds, but the upgrade fails. I
> > am proposing, at a minimum, that pg_upgrade --check fails in such cases,
>
> Agreed, that should be a minimum fix.
On 2019-Sep-26, Bruce Momjian wrote:
> On Wed, Sep 11, 2019 at 06:25:38PM -0300, Álvaro Herrera wrote:
> > On 2019-Aug-21, Bruce Momjian wrote:
> >
> > > > 1) How exactly should we report this incompatibility to a user?
> > > > I think it's fine to leave the warnings and also write some hint for
On Wed, Sep 11, 2019 at 06:25:38PM -0300, Álvaro Herrera wrote:
> On 2019-Aug-21, Bruce Momjian wrote:
>
> > > 1) How exactly should we report this incompatibility to a user?
> > > I think it's fine to leave the warnings and also write some hint for the
> > > user by analogy with other checks.
> >
On 2019-Aug-21, Bruce Momjian wrote:
> > 1) How exactly should we report this incompatibility to a user?
> > I think it's fine to leave the warnings and also write some hint for the
> > user by analogy with other checks.
> > "Reset ACL on the problem functions to default in the old cluster to
> >
Stephen,
On 2019-Aug-20, Stephen Frost wrote:
> Will try to take a look at the actual patch later today.
Any word on that review?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Aug 20, 2019 at 04:38:18PM +0300, Anastasia Lubennikova wrote:
> > Solving this in pg_upgrade does seem like it's probably the better
> > approach rather than trying to do it in pg_dump. Unfortunately, that
> > likely means that all we can do is have pg_upgrade point out to the user
> > wh
Greetings,
* Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
> 14.08.2019 3:28, Stephen Frost wrote:
> >* Bruce Momjian (br...@momjian.us) wrote:
> >>As much as it would be nice if the release notes covered all that, and
> >>we updated pg_upgrade to somehow handle them, it just isn't r
14.08.2019 3:28, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
As much as it would be nice if the release notes covered all that, and
we updated pg_upgrade to somehow handle them, it just isn't realistic.
As we can see here, the problems often take years to show up, and even
th
On Tue, Aug 13, 2019 at 08:28:12PM -0400, Stephen Frost wrote:
> Getting it to be at check time would certainly be a great improvement.
>
> Solving this in pg_upgrade does seem like it's probably the better
> approach rather than trying to do it in pg_dump. Unfortunately, that
> likely means that
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Aug 13, 2019 at 07:04:42PM +0300, Anastasia Lubennikova wrote:
> > Maybe, as a compromise, we can reset grants to default for all changed
> > functions
> > and also generate a script that will allow a user to preserve privileges of
> >
On Tue, Aug 13, 2019 at 07:04:42PM +0300, Anastasia Lubennikova wrote:
> > In an ideal world, it seems like we'd make a judgement call and arrange
> > to pull the privileges across when we can do so without granting the
> > user privileges beyond those that were intended, and otherwise we'd
> > sup
29.07.2019 18:37, Stephen Frost wrote:
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Bruce Momjian writes:
On Thu, Jul 18, 2019 at 06:53:12PM +0300, Anastasia Lubennikova wrote:
pg_upgrade from 9.6 fails if old cluster had non-standard ACL
on pg_catalog functions that have changed betwee
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Bruce Momjian writes:
> > On Thu, Jul 18, 2019 at 06:53:12PM +0300, Anastasia Lubennikova wrote:
> >> pg_upgrade from 9.6 fails if old cluster had non-standard ACL
> >> on pg_catalog functions that have changed between versions,
> >> for example
Bruce Momjian writes:
> On Thu, Jul 18, 2019 at 06:53:12PM +0300, Anastasia Lubennikova wrote:
>> pg_upgrade from 9.6 fails if old cluster had non-standard ACL
>> on pg_catalog functions that have changed between versions,
>> for example pg_stop_backup(boolean).
> Uh, wouldn't this affect any def
On Thu, Jul 18, 2019 at 06:53:12PM +0300, Anastasia Lubennikova wrote:
> pg_upgrade from 9.6 fails if old cluster had non-standard ACL
> on pg_catalog functions that have changed between versions,
> for example pg_stop_backup(boolean).
>
> Error:
>
> pg_restore: creating ACL "pg_catalog.FUNCTION
pg_upgrade from 9.6 fails if old cluster had non-standard ACL
on pg_catalog functions that have changed between versions,
for example pg_stop_backup(boolean).
Error:
pg_restore: creating ACL "pg_catalog.FUNCTION "pg_stop_backup"()"
pg_restore: creating ACL "pg_catalog.FUNCTION
"pg_stop_backup"(
57 matches
Mail list logo
