Also try pg_stat_statements, does that on the fly and it will give you very
interesting execution stats too.
On Mon, Apr 13, 2020 at 12:37 AM Chris Morris
wrote:
> Thx!
>
> On Sat, Apr 11, 2020 at 11:55 PM Julien Rouhaud
> wrote:
>
>> On Sun, Apr 12, 2020 at 6:51 AM Chris Morris
>> wrote:
>> >
Thx!
On Sat, Apr 11, 2020 at 11:55 PM Julien Rouhaud wrote:
> On Sun, Apr 12, 2020 at 6:51 AM Chris Morris
> wrote:
> >
> > I have a local script I've written that will scan a log of PG queries to
> extract out unique queries without any specific parameter data. For
> example, if these 2 querie
In PostgreSQL 9.5:
I have created a function that does the following:
USER CREATE: 'CREATE USER user_x WITH PASSWORD 'abc' CREATEDB CREATEROLE;'
WITH GRANT: 'GRANT master_user TO user_x;'
GRANT CONNECT ON DATABASE my_db TO user_x
LOOP THROUGH ALL USER SCHEMAS:
OUTER LOOP: GRANT USAGE ON SC
Hi!
You cannot write such a script, but you will have to REVOKE and change ownership
and ALTER DEFAULT PRIVILEGES until no more dependencies on the role exist.
I ran script as superuser. In this case more detailed information appears:
ERROR: role "roletodelete" cannot be dropped because some
On Sun, Apr 12, 2020 at 10:23:24AM -0400, Tom Lane wrote:
> Magnus Hagander writes:
>> And FWIW, I do think we should change the default. And maybe spend some
>> extra effort on the message coming out of pg_upgrade in this case to make
>> it clear to people what their options are and exactly what
On Sun, 2020-04-12 at 00:25 +0300, Andrus wrote:
> User "currentuser" tries to delete role "roletodelete" from this database
> using
>
> But got error
>
> ERROR: role "roletodelete" cannot be dropped because some objects depend on it
> DETAIL: privileges for schema public;
>
> How to create s
Magnus Hagander writes:
> And FWIW, I do think we should change the default. And maybe spend some
> extra effort on the message coming out of pg_upgrade in this case to make
> it clear to people what their options are and exactly what to do.
Is there any hard evidence of checksums catching proble
On Sun, Apr 12, 2020 at 8:05 AM Michael Paquier wrote:
> On Fri, Apr 10, 2020 at 04:37:46PM -0400, Stephen Frost wrote:
> > There's definitely a lot of reasons to want to have the ability to
> > change an existing cluster. Considering the complications around
> > running pg_upgrade already, I do
