After DB upgrade from PG13 to PG15 showing error

Dear Team, We have upgraded PostgreSQL DB from version 13 to 15 version . We are facing issue in PG15 we not enable any parameter related to AUTOVACUUM , but still running on PG15 data base. Below process showing : 2313192 | 02:10:01.283176 || myLava | active | autovacuum:

Re: After DB upgrade from PG13 to PG15 showing error

Hi On Tue, Aug 27, 2024 at 1:50 PM Ram Pratap Maurya < ram.mau...@lavainternational.in> wrote: > Dear Team, > > > > We have upgraded PostgreSQL DB from version 13 to 15 version . > > We are facing issue in PG15 we not enable any parameter related to > AUTOVACUUM , but still running on PG15 data b

Analytics on PostgresQL Advisory

Hi, We’re developing tools for Verifiable Analytics on shielded sensitive data in data ecosystems. While we’re still in the early stages and not selling anything yet, our goal is to build something truly valuable. We’d love to hear how you use Postgres databases with sensitive data to: • Perfo

Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

On Tue, 27 Aug 2024 at 18:00, Justin Clift wrote: > As a general thought, seeing that this might be an actual problem > should some kind of automated testing be added that checks for > performance regressions like this? We normally try to catch these sorts of things with regression tests. Of cour

Re: Using PQsocketPoll() for PIPELINE mode

On Wed, Aug 14, 2024 at 2:50 PM Dominique Devienne wrote: > Hi. I've now used successfully the new PQsocketPoll() API > in the context of waiting for notifications, using beta2 and 3. > > But now I'm looking into using it in the context of PIPELINE mode. > Where I suppose both forRead and forWrite

Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

On Tue, 27 Aug 2024 at 14:03, Tom Lane wrote: > Yeah, I got that same result by bisecting. It seems like it's > somehow related to the cast to information_schema.sql_identifier: > we are able to get rid of that normally but seem to fail to do so > in this query. In case it saves you a bit of tim

Re: Using PQsocketPoll() for PIPELINE mode

On Tue, Aug 27, 2024 at 12:23 PM Dominique Devienne wrote: > On Wed, Aug 14, 2024 at 2:50 PM Dominique Devienne > wrote: > > Hi. I've now used successfully the new PQsocketPoll() API > > in the context of waiting for notifications, using beta2 and 3. > > > > But now I'm looking into using it in

Re: Using PQsocketPoll() for PIPELINE mode

On Tue, Aug 27, 2024 at 9:20 AM Dominique Devienne wrote: > Once again, this is late, although my original questions are now 2 weeks > old. > After all, PQsocketPoll() has not been released yet officially. Thanks, > --DD > As this is so new, you might have better luck on -hackers than here. I've

Re: After DB upgrade from PG13 to PG15 showing error

On 8/27/24 01:50, Ram Pratap Maurya wrote: Dear Team, We have upgraded PostgreSQL DB from version 13 to 15 version . We are facing issue in PG15 we not enable any parameter related to AUTOVACUUM , but still running on PG15 data base. You need to provide more detail about the above. What par

Strange behaviors with ranges

Hello, I have 2 very confusing behaviors when using ranges. It all started with this query:     WITH rangespaliers AS (     SELECT numrange( qtep1+1   , qtep2,  '[]') AS rangep FROM paliers JOIN tmp_limitcontrats USING(idcontrat) --    SELECT numrange( qtep1+1   , qtep2,  '[]') AS rang

Re: Strange behaviors with ranges

On 8/27/24 10:29 AM, Jean-Christophe Boggio wrote: Hello, I have 2 very confusing behaviors when using ranges. It all started with this query:     WITH rangespaliers AS (     SELECT numrange( qtep1+1   , qtep2,  '[]') AS rangep FROM paliers JOIN tmp_limitcontrats USING(idcontrat) -- 

Re: Strange behaviors with ranges

What does: SELECT numrange( qtep1+1   , qtep2,  '[]') AS rangep FROM paliers WHERE idcontrat=1003 return? It returns: (,) (as expected)

Re: Strange behaviors with ranges

I guess this query comes back non-empty: SELECT * FROM paliers JOIN tmp_limitcontrats USING(idcontrat) WHERE qtep1 >= qtep2 This would then lead somewhere to this expression numrange(3,2) Check out idpalier=805 On Tue, Aug 27, 2024 at 7:37 PM Adrian Klaver wrote: > > > On 8/27/24 10:29 AM, J

Re: Strange behaviors with ranges

On 8/27/24 10:29, Jean-Christophe Boggio wrote: I have 2 very confusing behaviors when using ranges. It all started with this query:     WITH rangespaliers AS (     SELECT numrange( qtep1+1   , qtep2,  '[]') AS rangep FROM paliers JOIN tmp_limitcontrats USING(idcontrat) --    SELECT

Re: Strange behaviors with ranges

Le 27/08/2024 à 19:51, Torsten Förtsch a écrit : I guess this query comes back non-empty: SELECT * FROM paliers JOIN tmp_limitcontrats USING(idcontrat) WHERE qtep1 >= qtep2 Yes, it is empty if I keep tmp_limitcontrats to idcontrat=1003 Otherwise, you are right, there are irregular data but n

Re: Strange behaviors with ranges

On 8/27/24 11:13 AM, Jean-Christophe BOGGIO wrote: Le 27/08/2024 à 19:51, Torsten Förtsch a écrit : I guess this query comes back non-empty: SELECT * FROM paliers JOIN tmp_limitcontrats USING(idcontrat) WHERE qtep1 >= qtep2 Yes, it is empty if I keep tmp_limitcontrats to idcontrat=1003 O

Re: Strange behaviors with ranges

On 8/27/24 11:16 AM, Adrian Klaver wrote: On 8/27/24 11:13 AM, Jean-Christophe BOGGIO wrote: Le 27/08/2024 à 19:51, Torsten Förtsch a écrit : I guess this query comes back non-empty: SELECT * FROM paliers JOIN tmp_limitcontrats USING(idcontrat) WHERE qtep1 >= qtep2 Yes, it is empty if

Re: Strange behaviors with ranges

Paul, Le 27/08/2024 à 20:11, Paul Jungwirth a écrit : The issue is the order-of-operations used by the planner. If I put EXPLAIN on your last query, I see:  Hash Join  (cost=16.64..109.90 rows=2410 width=64)    Hash Cond: (tmp_limitcontrats.idcontrat = paliers.idcontrat)    ->  Seq Scan on tmp

tsvector limitations - why and how

Hey! I just spent some time extensively documenting a draft e-mail I planned to send over here to report what I thought was a bug. I was playing around with tsvector and full text search for a pet project of mine, ingesting books' content. I was aware of the limitations of FTS

Re: tsvector limitations - why and how

Stanislav Kozlovski writes: > I was aware of the limitations of > FTS and tried > to ensure I didn't hit any - but what I missed was that the maximum allowed > lexeme position was 16383 and everything above silently gets set to 163

Ghost data from failed FDW transactions?

Hi there! We have a setup where, for compliance reasons, we hoist a portion of data from several "tenant" databases into a "root" / common / untenanted DB. Through the magic of postgres_fdw, row triggers, and distributed transactions, we automatically hoist the needed columns into the untenanted D

Pgbackrest specifying the default DB necessary/correct way ?

List, I have configured the pgbackrest on a live DB server and a Repo Server. ( EPAS 16, RHEL 9.4 and Pgbackrest 2.52.1 ) On DB Server I have ## [root@db1 ~]# cd [root@db1 ~]# cat /etc/pgbackrest/pgbackrest.conf [Demo_Repo] pg1-path=/data/edb/as16/data pg1-port=5444

Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

On 2024-08-27 20:14, David Rowley wrote: On Tue, 27 Aug 2024 at 18:00, Justin Clift wrote: As a general thought, seeing that this might be an actual problem should some kind of automated testing be added that checks for performance regressions like this? We normally try to catch these sorts o