Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> guilla...@lelarge.info wrote: > > This won't answer your question It has been answered now. See my "case closed" email here: www.postgresql.org/message-id/B33C40D9-2B79-44C7-B527-86E672BEA71A%40yugabyte.com > …but still… I usually really like your scripts, it's nicely written, but this > par

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> jer...@musicsmith.net wrote: > >> b...@yugabyte.com wrote: >> >> I say this only to emphasize that there are always things that are critical >> that are elided in a testcase that tries to be minimal. >> >> So it seems that there's something critical about my env that I'm failing to >> tell y

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role? >> CASE CLOSED

x...@thebuild.com wrote: > >> t...@sss.pgh.pa.us wrote: >> >> Perhaps you'd already revoked from public in this database? > > Very possible! You all forgot to tell me to put this aside and go out for a walk. I just told myself to do that. And it struck me then. Tom just said it here—albeit pa

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> On Sep 13, 2022, at 14:10, Tom Lane wrote: > > Perhaps you'd already revoked from public in this database? Very possible!

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Christophe Pettus writes: > It works correctly for me, on MacOS: > swift-239:~ xof$ psql > psql (14.5) > Type "help" for help. > xof=# create user r1; > CREATE ROLE > xof=# revoke execute on function pg_terminate_backend from r1; > REVOKE > xof=# > \q > swift-239:~ xof$ psql -U r1 xof > psql (1

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

I say this only to emphasize that there are always things that are critical > that are elided in a testcase that tries to be minimal. > > So it seems that there's something critical about my env that I'm failing > to tell you all. But what can it be? > > Removing permissions also works for me. In

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Hi, This won't answer your question but still... I usually really like your scripts, it's nicely written, but this part seems really weird to me: Le mar. 13 sept. 2022 à 20:23, Bryn Llewellyn a écrit : > > > > > > > > > > > > > > > > > > *-- No errordo $body$declare p int not null := 0;begin

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> x...@thebuild.com wrote: > >> b...@yugabyte.com wrote: >> >> What are you seeing that I'm failing to? > > It works correctly for me, on MacOS: > > create user r1; > revoke execute on function pg_terminate_backend from r1; > > (reconnect as r1) > > select pg_terminate_backend(123); > > ERRO

get user info on log

When using set role or set session authorization and an error occurs I get user name which logged in and not the one I´ve changed to. There is a way to get session_user and current_user on log ? Thanks Marcos

Re: Postgresql acid components

On 9/12/22 09:34, Rama Krishnan wrote: Hi all, In ACID property which postgresql components is supporting it The database as whole is ACID compliant per: https://www.postgresql.org/about/ "...has been ACID-compliant since 2001...". From what I remember there are some commands that do not

How to Build NLS Files

I'm building Postgres 14.5 on Windows and want to build the nls files that go in share/locale. According to this page I need the gettext software: Gettext is required to build with NLS support, and can be downloaded from http:

Postgresql acid components

Hi all, In ACID property which postgresql components is supporting it

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> On Sep 13, 2022, at 11:39, Bryn Llewellyn wrote: > > What are you seeing that I'm failing to? It works correctly for me, on MacOS: swift-239:~ xof$ psql psql (14.5) Type "help" for help. xof=# create user r1; CREATE ROLE xof=# revoke execute on function pg_terminate_backend from r1; REVOK

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> x...@thebuild.com wrote: > >> b...@yugabyte.com wrote: >> >> There must be some-or-other non-standard setting in my environment that >> results in the behavior that I see and that other's don't. > > From the documentation: > >> superuser status: A database superuser bypasses all permission c

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> On Sep 13, 2022, at 11:23, Bryn Llewellyn wrote: > > There must be some-or-other non-standard setting in my environment that > results in the behavior that I see and that other's don't. From the documentation: > superuser status > A database superuser bypasses all permission checks,

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> t...@sss.pgh.pa.us wrote: > >> b...@yugabyte.com wrote: >> >> My non-superuser normalrole with direct login, "u1", is *still* able to >> invoke pg_terminate_backend() and kill other "u1" sessions—even after this >> (as a super-user): > > Really? I did this in 14.5: > > revoke execute on fu

Aw: Re: toast useless

Gesendet: Dienstag, 13. September 2022 um 19:13 Uhr Von: "Ron" An: pgsql-general@lists.postgresql.org Betreff: Re: toast useless On 9/13/22 08:18, Simon Riggs wrote: On Tue, 13 Sept 2022 at 13:29, Marcos Pegoraro wrote: What problem do they cause you? They don't cause any problem, I wa

Re: toast useless

On 9/13/22 08:18, Simon Riggs wrote: On Tue, 13 Sept 2022 at 13:29, Marcos Pegoraro wrote: What problem do they cause you? They don't cause any problem, I was just trying to get my database as clean as possible. I have some thousands of these toast tables with 8k bytes, so I was trying to e

Re: toast useless

On Tue, 13 Sept 2022 at 13:29, Marcos Pegoraro wrote: >> >> What problem do they cause you? > > > They don't cause any problem, I was just trying to get my database as clean > as possible. > I have some thousands of these toast tables with 8k bytes, so I was trying to > eliminate them > But if t

Re: toast useless

> > What problem do they cause you? > They don't cause any problem, I was just trying to get my database as clean as possible. I have some thousands of these toast tables with 8k bytes, so I was trying to eliminate them But if there is no way, ok

Re: toast useless

On Tue, 13 Sept 2022 at 12:45, Marcos Pegoraro wrote: > So, there is a way to eliminate these useless toast tables ? What problem do they cause you? -- Simon Riggshttp://www.EnterpriseDB.com/

toast useless

create table test(x integer, y integer, w varchar(50), z varchar(80)); When a table has well defined sizes all their data is stored on heap, so they doesn´t need to be toasted, and no toast table is created. Fine. But then I want to store last modification of that record, so I do ... alter table t