Scott Ribe writes:
> So, one last follow-up, perhaps \du or \du+ should show when a role is mapped
> that way. If I'd seen a clue to this setting that had been made "before I got
> here" it would have been figured out sooner.
\drds does already show this; of course, you have to know to look at
So, one last follow-up, perhaps \du or \du+ should show when a role is mapped
that way. If I'd seen a clue to this setting that had been made "before I got
here" it would have been figured out sooner.
I realize ALTER ROLE... SET... can be used to set many more defaults, and there
could be some
> On Aug 7, 2020, at 1:32 PM, Tom Lane wrote:
>
> Yes, you are. It looks like what you actually issued is
>
> ALTER USER akanzler SET role confidential_read_only;
>
> but that would have the effect that subsequent session starts would
> automatically do "SET ROLE confidential_read_only".
AHA!
On 8/7/20 12:40 PM, Adrian Klaver wrote:
On 8/7/20 12:27 PM, Scott Ribe wrote:
On Aug 7, 2020, at 1:08 PM, Adrian Klaver
wrote:
"Using this command, it is possible to either add privileges or
restrict one's privileges. If the session user role has the INHERIT
attribute, then it automaticall
On 8/7/20 12:27 PM, Scott Ribe wrote:
On Aug 7, 2020, at 1:08 PM, Adrian Klaver wrote:
"Using this command, it is possible to either add privileges or restrict one's
privileges. If the session user role has the INHERIT attribute, then it
automatically has all the privileges of every role that
Scott Ribe writes:
> So it would only have removed privs if I had used set role in the session,
> which I am not.
Yes, you are. It looks like what you actually issued is
ALTER USER akanzler SET role confidential_read_only;
but that would have the effect that subsequent session starts would
au
> On Aug 7, 2020, at 1:08 PM, Adrian Klaver wrote:
>
> "Using this command, it is possible to either add privileges or restrict
> one's privileges. If the session user role has the INHERIT attribute, then it
> automatically has all the privileges of every role that it could SET ROLE to;
> in t
On 8/7/20 11:56 AM, Scott Ribe wrote:
On Aug 7, 2020, at 12:45 PM, Tom Lane wrote:
If I'm reading this correctly, you have set things up so that any
session logging in as akanzler will immediately do "SET ROLE
confidential_read_only", after which it's the privileges of that
role not akanzler th
> On Aug 7, 2020, at 12:45 PM, Tom Lane wrote:
>
> If I'm reading this correctly, you have set things up so that any
> session logging in as akanzler will immediately do "SET ROLE
> confidential_read_only", after which it's the privileges of that
> role not akanzler that determine what happens.
Scott Ribe writes:
> On Aug 7, 2020, at 12:27 PM, Adrian Klaver wrote:
>> So what privileges does role 'confidential_read_only' have?
> read on everything
... including usage on the schema in question?
If I'm reading this correctly, you have set things up so that any
session logging in as akan
On Aug 7, 2020, at 12:27 PM, Adrian Klaver wrote:
>
> So what privileges does role 'confidential_read_only' have?
read on everything
I tried creating a new user without it, just doing the same grants otherwise as
for akanzler, that worked. Then I added that user to confidential_read_only,
sti
On 8/7/20 11:25 AM, Scott Ribe wrote:
On Aug 7, 2020, at 12:17 PM, Adrian Klaver wrote:
Well if this for the same line as before it represents table privileges. The
problem is with schema access. Continuing grasping at straws:
select * from pg_roles where rolname = 'aakanzler';
rolname | r
> On Aug 7, 2020, at 12:17 PM, Adrian Klaver wrote:
>
> Well if this for the same line as before it represents table privileges. The
> problem is with schema access. Continuing grasping at straws:
>
> select * from pg_roles where rolname = 'aakanzler';
rolname | rolsuper | rolinherit | rolcre
On 8/7/20 10:39 AM, Scott Ribe wrote:
On Aug 7, 2020, at 11:31 AM, Scott Ribe wrote:
Wondering if there's a code path somewhere that lets the default take
precedence???
So, I changed the defaults, now I see akanzler=arwdDxt/srv_risk, problem
persists
Well if this for the same line as bef
> On Aug 7, 2020, at 11:31 AM, Scott Ribe wrote:
>
> Wondering if there's a code path somewhere that lets the default take
> precedence???
So, I changed the defaults, now I see akanzler=arwdDxt/srv_risk, problem
persists
>
> What happens if you do?:
>
> select has_schema_privilege('akanzler', 'zoewang', 'usage');
risk_oltp_prod=# select has_schema_privilege('akanzler', 'zoewang', 'usage');
has_schema_privilege
--
t
(1 row)
> In psql what does
>
> \ddp
>
> show?
risk_oltp_prod=# \ddp
On 8/7/20 9:23 AM, Scott Ribe wrote:
Further update:
create a new user, grant all on schema & the table, works
reboot of server did not change anything, so the problem is in persistent state
What happens if you do?:
select has_schema_privilege('akanzler', 'zoewang', 'usage');
In psql what
Further update:
create a new user, grant all on schema & the table, works
reboot of server did not change anything, so the problem is in persistent state
>
> The main problem here is that "Amazon Aurora" is not PostgreSQL.
> If I understand Amazon's documentation, what you are using is
> officially named "Amazon Aurora with PostgreSQL Compatibility",
> and that sums is up quite nicely: Aurora is a database engine
> developed at Amazon - and it's in
Thank you Adam and Christoph,
You are totally right, that AWS support is the one to help me with this
problem.
I am in contact with them for quite some time on this problem and as there
was no progress on resolving this,
I tried to find some insight or trick that I missed here. It's a long shot
(:
## Chris Borckholder (chris.borckhol...@bitpanda.com):
> We are experiencing a strange situation with an AWS Aurora postgres
> instance.
The main problem here is that "Amazon Aurora" is not PostgreSQL.
If I understand Amazon's documentation, what you are using is
officially named "Amazon Aurora w
I would highly suggest you reach out to AWS support for Aurora questions,
that's part of what you're paying for, support.
For reasons you mentioned and more, it's pretty hard to debug issues
because it isn't actually Postgres.
>
Thanks for your insight!
I cannot find any errors related to archiving in the logs that are
accessible to me.
It's definitely something that I will forward to the support team of the
managed database.
Best Regards
Chris
On Thu, Aug 6, 2020 at 3:18 AM Mohamed Wael Khobalatte <
mkhobala...@grubhub
Thank you for your insight Seenu!
That is a good point, unfortunately we do not have access to the
server/file system as the database is a managed service.
Access to the file system from postgres like pg_ls_dir is also blocked.
Are you aware of another, creative way to infer the wal file size fro
24 matches
Mail list logo
