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

Bryn Llewellyn writes: > I can't agree with you about risks and probability, though. The general > literature of security threats often makes the point that disgruntled > employees (current or very recently former) who know the code in question do > sometimes wreak havoc—sometimes just for spor

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

Bryn Llewellyn writes: > 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: regression=# revoke execute on function pg_terminate_backend from pub

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: >> >> The implication is that every client program must follow every database call >> with defensive code to detect error "57P01" and programmatically re-try. > > That situation exists even without the ability for a role to kill other > ses

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

> On Sep 12, 2022, at 20:44, Bryn Llewellyn wrote: > Version 16? Thus might be the clue, then. It behaves as David describes on: PostgreSQL 14.5 on x86_64-apple-darwin19.6.0, compiled by Apple clang version 12.0.0 (clang-1200.0.32.29), 64-bit

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

> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> revoke execute on function pg_terminate_backend(int, bigint) from public; > > I just did this very thing in v16 (head-ish) and it worked as expected, > preventing the non-superuser role from executing the function: > > Ses

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

On Mon, Sep 12, 2022 at 6:08 PM Bryn Llewellyn wrote: > > *revoke execute on function pg_terminate_backend(int, bigint) from public;* > I just did this very thing in v16 (head-ish) and it worked as expected, preventing the non-superuser role from executing the function: Session 1 - superuser po

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

> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> …I'm troubled by the notion that (as it seems) one session that authorizes >> as the role "r1" can easily list all other concurrent sessions that are also >> authorized as "r1"—and kill them all without restriction. (The do

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

> On Sep 12, 2022, at 15:51, Bryn Llewellyn wrote: > The implication is that every client program must follow every database call > with defensive code to detect error "57P01" and programmatically re-try. That situation exists even without the ability for a role to kill other sessions author

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

On Mon, Sep 12, 2022 at 3:51 PM Bryn Llewellyn wrote: > I'll use "kill" here a shorthand for using the "pg_terminate_backend()" > built-in function. I read about it in the "Server Signaling Functions" > section of the enclosing "System Administration Functions" section of the > current doc: > > w

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

I'll use "kill" here a shorthand for using the "pg_terminate_backend()" built-in function. I read about it in the "Server Signaling Functions" section of the enclosing "System Administration Functions" section of the current doc: www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADM

Re: how to check specific user_name have “SELECT ON ALL TABLES IN SCHEMA ” privilege or not ?

On 9/11/22 12:03, David G. Johnston wrote: On Sunday, September 11, 2022, yanliang lei > wrote: Dear everyone， how to check specific   have “SELECT ON ALL TABLES IN SCHEMA ”  privilege or not ? This is not an appropriate list to ask general usage questions

Re: unable to install pldebugger

Thank you Julien! It worked On Mon, 12 Sep, 2022, 10:19 pm Julien Rouhaud, wrote: > On Mon, Sep 12, 2022 at 10:14:20PM +0530, shashidhar Reddy wrote: > > Hello Julien, > > > > Can I use this link to install in community edition postgres or is it > > specific to enterpriseDB > > It should work wi

Re: pgBackRest on MacOS

Greetings, * Ron (ronljohnso...@gmail.com) wrote: > On 9/10/22 07:31, Marc wrote: > >Has anybody pgbackrest running on MacOS ( Monterey ? ) > > > >If yes are you willing to share the how to ? > > > >Or can anybody guide us to an “easy” how to ? > > It's written in Perl, so installation from sourc

Re: unable to install pldebugger

On Mon, Sep 12, 2022 at 10:14:20PM +0530, shashidhar Reddy wrote: > Hello Julien, > > Can I use this link to install in community edition postgres or is it > specific to enterpriseDB It should work with the standard community edition.

Re: Missing query plan for auto_explain.

On Mon, Sep 12, 2022 at 05:34:37PM +0100, Matheus Martin wrote: > Understood. I have run a prepared statement with the query in question > through `psql` and JIT was not used (see plan below), however please note > that the long response times were never reproducible from `psql`, they only > happen

Re: unable to install pldebugger

Hello Julien, Can I use this link to install in community edition postgres or is it specific to enterpriseDB On Mon, 12 Sep, 2022, 7:01 pm Julien Rouhaud, wrote: > Hi, > > On Mon, Sep 12, 2022 at 06:49:21PM +0530, shashidhar Reddy wrote: > > > > I am in a process of upgrading postgres 12 to 13

Re: Missing query plan for auto_explain.

Understood. I have run a prepared statement with the query in question through `psql` and JIT was not used (see plan below), however please note that the long response times were never reproducible from `psql`, they only happen from our JDBC application. QUER

Re: Support for dates before 4713 BC

Simon Riggs writes: > On Mon, 12 Sept 2022 at 16:00, Tom Lane wrote: >> No, it applies because we aren't sure that the math would operate >> correctly with negative Julian day numbers --- for instance, division >> roundoffs might happen in the wrong direction. If somebody wanted to go >> through

Re: Support for dates before 4713 BC

On Mon, 12 Sept 2022 at 16:00, Tom Lane wrote: > > Simon Riggs writes: > > On Sun, 21 Aug 2022 at 19:04, Tom Lane wrote: > >> There are existing equations for calculating Gregorian month/day/year from > >> Julian day count [1]. They work back to Julian day zero, at least if > >> you grant that

Re: Resolving host to IP address

Hi Sebastien: On Mon, 12 Sept 2022 at 16:40, Sebastien Flaesch wrote: > I think I got it: PostgreSQL should listen to the real, non-loopback network > interface. Not really. Your problem is not where postgres listens, but where your host line resolves, the 127.0.1.1 stuff, plus your rules. I

Re: Support for dates before 4713 BC

Simon Riggs writes: > On Sun, 21 Aug 2022 at 19:04, Tom Lane wrote: >> There are existing equations for calculating Gregorian month/day/year from >> Julian day count [1]. They work back to Julian day zero, at least if >> you grant that proleptic Gregorian dates are sensible that far back. >> Nob

Re: Resolving host to IP address

Thank you all for your comments. I think I got it: PostgreSQL should listen to the real, non-loopback network interface. Just for info (local dev config, not prod): sf@toro:/opt3/dbs/pgs/14.1-openssl/data$ grep listen_addresses postgresql.conf listen_addresses = 'localhost,toro.strasbourg.4js.

Re: Support for dates before 4713 BC

On Sun, 21 Aug 2022 at 19:04, Tom Lane wrote: > > "Watzinger, Alexander" writes: > > Any chance to add support for dates before 4713 BC? We really would > > appreciate that. > > I'm a little skeptical of the value of applying the Gregorian calendar > before 1582 AD, let alone thousands of years

Re: Resolving host to IP address

A little off topic but may be useful for someone: On Mon, 12 Sept 2022 at 16:11, Tom Lane wrote: ... > Linux doesn't seem to show its routing of the loopback domain in netstat > output, but it's probably much like what macOS shows explicitly: Among other things it can be shown by "ip route show"

Re: Resolving host to IP address

On Mon, 12 Sept 2022 at 14:23, Sebastien Flaesch wrote: > I managed to establish the secure connection, by using > DN=root.strasbourg.4js.com for the self-signed root CA, and > DN=toro.strasbourg.4js.com for the server certificate, DN=pgsuser for the > client certificate. > I have created my cl

Re: Resolving host to IP address

Sebastien Flaesch writes: > $ psql > 'postgresql://toro.strasbourg.4js.com:5437/test1?user=pgsuser&sslmode=verify-ca&sslrootcert=./root.crt&sslcert=./client.crt&sslkey=./client.key' > psql: error: connection to server at "toro.strasbourg.4js.com" (127.0.1.1), > port 5437 failed: FATAL: no pg_hb

Re: lippq client library and openssl initialization: PQinitOpenSSL()

Daniel Gustafsson writes: > On 12 Sep 2022, at 13:21, Peter Eisentraut > wrote: >> AFAICT, RHEL 7 ships with an older version. I think that's still pretty >> widespread. > Fair enough. That doesn't however IMO prevent us from adding a note that > 1.1.0 > and onwards are different. The attac

Re: unable to install pldebugger

Hi, On Mon, Sep 12, 2022 at 06:49:21PM +0530, shashidhar Reddy wrote: > > I am in a process of upgrading postgres 12 to 13 on ubuntu. When I am > running the test getting error could not load library > "$libdir/plugin_debugger": ERROR: could not load library > "/usr/lib/postgresql/13/lib/plugin_d

Re: unable to install pldebugger

Hi po 12. 9. 2022 v 15:19 odesílatel shashidhar Reddy < shashidharreddy...@gmail.com> napsal: > Hello, > > I am in a process of upgrading postgres 12 to 13 on ubuntu. When I am > running the test getting error could not load library > "$libdir/plugin_debugger": ERROR: could not load library > "/

unable to install pldebugger

Hello, I am in a process of upgrading postgres 12 to 13 on ubuntu. When I am running the test getting error could not load library "$libdir/plugin_debugger": ERROR: could not load library "/usr/lib/postgresql/13/lib/plugin_debugger.so": /usr/lib/postgresql/13/lib/plugin_debugger.so: undefined sym

Re: Support for dates before 4713 BC

Dear Adrian, Thank you for your insights and taking the time. It is always very interesting to see where other software projects limitations come from. All the best, Alex -- Alexander Watzinger Austrian Academy of Sciences Austrian Centre for Digital Humanities and Cultural Heritage Bäckerst

Resolving host to IP address

Hi! I am playing with PostgreSQL TLS/SSL connections using OpenSSL, with server and client certificates. I managed to establish the secure connection, by using DN=root.strasbourg.4js.com for the self-signed root CA, and DN=toro.strasbourg.4js.com for the server certificate, DN=pgsuser for the

Re: lippq client library and openssl initialization: PQinitOpenSSL()

> On 12 Sep 2022, at 13:21, Peter Eisentraut > wrote: > On 11.09.22 23:43, Daniel Gustafsson wrote: >>> On 11 Sep 2022, at 23:35, Tom Lane wrote: >>> Should we document these functions as obsolete when using >>> OpenSSL >= 1.1.0 ? >> Given that 1.1.0+ is very common, it's probably not a bad ide

Re: lippq client library and openssl initialization: PQinitOpenSSL()

On 11.09.22 23:43, Daniel Gustafsson wrote: On 11 Sep 2022, at 23:35, Tom Lane wrote: Daniel Gustafsson writes: On 11 Sep 2022, at 17:08, Tom Lane wrote: Don't believe so. The HAVE_CRYPTO_LOCK stuff is all obsolete and not compiled if you built against 1.1.0. The only thing left that will