Re: Mysterious performance degradation in exceptional cases

El día miércoles, septiembre 14, 2022 a las 07:19:31a. m. -0700, Adrian Klaver escribió: > On 9/14/22 01:31, Matthias Apitz wrote: > > > > We have a C-written application server which uses ESQL/C on top > > of PostgreSQL 13.1 on Linux. The application in question always serves > > the same searc

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

Bryn Llewellyn writes: > I just confirmed that, if it suits me, I can revoke "execute" from "public" > on all overloads of the humble length() function. Maybe I should refer to it > as "pg_catalog.length()" to emphasize another point that had escaped me. Yup. For even more fun, try revoking pr

Re[2]: CVE-2022-2625

All business processes are hooked on postgresql 9.5. There is no way to update. Unfortunately, I don't have the proper qualifications to change it.   >Четверг, 15 сентября 2022, 1:58 +09:00 от Laurenz Albe >: >  >On Wed, 2022-09-14 at 17:02 +0300, misha1966 misha1966 wrote: >> Tell me, is there

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

> gogala.mla...@gmail.com wrote: > >> b...@yugabyte.com 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 >>

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

Mladen Gogala writes: > ... This doesn't look like a big problem because > applications usually don't contain code for killing other user's > sessions. I am not sure that GTA is running on top of Postgres database. Yeah, I meant to comment on that further but forgot. I don't particularly buy t

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

Mladen Gogala writes: > Tom, I did the same thing on 14.5, and it behaves as Bryn alleges: Looks to me like you made the same mistake as Bryn. You revoked the permission in the postgres database: > postgres=# select proacl from pg_proc where proname = > 'pg_terminate_backend'; >   

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

On 9/13/22 00:49, Tom Lane wrote: 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

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

On 9/12/22 18:51, 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: www.postgresql.org/docs/

Re: massive update on gin index

Em qua., 14 de set. de 2022 às 16:55, Tom Lane escreveu: > GIN does have a "pending list" of insertions not yet pushed into the main > index structure, and search performance will suffer if that gets too > bloated. I don't recall much about how to control that, but I think > vacuuming the table

Re: massive update on gin index

Marcos Pegoraro writes: > I know I have other options, and possibly better, but I was trying to > understand what happens with gin indexes, just that. GIN does have a "pending list" of insertions not yet pushed into the main index structure, and search performance will suffer if that gets too blo

Re: massive update on gin index

> > Did you try a simple array of phone numbers? If you really care about > mobile,work,home prepend the number with one of HMW. Easily stripped off > as necessary. I've had decent performance with arrays in the past. > I know I have other options, and possibly better, but I was trying to unders

Re: massive update on gin index

On 9/14/22 13:38, Guyren Howe wrote: You might consider defining a phone type that includes your “type” information, and just having an array of those, if you really want to do something like this. But a related table instead would be the obvious answer. Did you try a simple array of phone n

Re: massive update on gin index

You might consider defining a phone type that includes your “type” information, and just having an array of those, if you really want to do something like this. But a related table instead would be the obvious answer. > On Sep 14, 2022, at 12:33 , Marcos Pegoraro > wro

massive update on gin index

In a table with people's info I have 3 phone numbers, mobile, work and home. But then some have 2 mobiles, some have 2 work numbers, so decided to test it as an array of json. I know I could have another table for that, but I was just testing. So my original table had Mobile, Work, Home and all of

Re: CVE-2022-2625

On Wed, 2022-09-14 at 17:02 +0300, misha1966 misha1966 wrote: > Tell me, is there a CVE-2022-2625 vulnerability in posgresql 9.5? > If so, who knows how to patch it? Patches from version 10 are not suitable at > all... Yes, that vulnerability exists in 9.5. To patch that, you'd have to try and b

understand pg_ndistinct type && Why with(autovacuum_enabled=off) some query estimate 100, some is 200.

source: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob_plain;f=src/test/regress/expected/stats_ext.out;h=431b3fa3de1f4f87205e7e27a99ef1cf337f1590;hb=676887a3b0b8e3c0348ac3f82ab0d16e9a24bd43 -- n-distinct tests CREATE TABLE ndistinct ( filler1 TEXT, filler2 NUMERIC, a INT,

Re: Mysterious performance degradation in exceptional cases

Matthias Apitz writes: > To fulfill the search, the application server has to do some 100 > ESQL/C calls and all this should not take longer than 1-2 seconds, and > normally it does not take longer. But, in some situations it takes > longer than 180 seconds, in 10% of the cases. The other 90% are

Re: Mysterious performance degradation in exceptional cases

On 9/14/22 01:31, Matthias Apitz wrote: We have a C-written application server which uses ESQL/C on top of PostgreSQL 13.1 on Linux. The application in question always serves the same search in a librarian database, given to the server as commands over the network, login into the application and

CVE-2022-2625

Good afternoon to everyone! Tell me, is there a CVE-2022-2625 vulnerability in posgresql 9.5? If so, who knows how to patch it? Patches from version 10 are not suitable at all...

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

Am Wed, Sep 14, 2022 at 10:10:30AM +0200 schrieb Karsten Hilbert: > Am Tue, Sep 13, 2022 at 05:10:58PM -0400 schrieb Tom Lane: > > > (I recall that somewhere we have some code that warns about no-op > > grants. I wonder if issuing a warning for no-op revokes would be > > helpful.) > > Surely, in

Mysterious performance degradation in exceptional cases

We have a C-written application server which uses ESQL/C on top of PostgreSQL 13.1 on Linux. The application in question always serves the same search in a librarian database, given to the server as commands over the network, login into the application and doing a search: SLNPServerInit User:zfl

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

Am Tue, Sep 13, 2022 at 05:10:58PM -0400 schrieb Tom Lane: > (I recall that somewhere we have some code that warns about no-op > grants. I wonder if issuing a warning for no-op revokes would be > helpful.) Surely, in the light of security a no-op revoke is potentially more dangerous than a no-op

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

Le mer. 14 sept. 2022 à 00:35, Bryn Llewellyn a écrit : > > *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

Re: Postgresql acid components

Hi Adrian Thanks for your valuable reply. On Wed, 14 Sep, 2022, 01:11 Adrian Klaver, wrote: > 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.postgre