Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

On Thu, Mar 16, 2023 at 6:48 AM Laurenz Albe wrote: > As we wrote, some of us think that cursors are useful, and we tried to > explain why we think that. If you don't think that cursors are useful, > don't use them. We are not out to convince you otherwise. > Perhaps OT (I only skimed this thr

Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

čt 16. 3. 2023 v 9:18 odesílatel Dominique Devienne napsal: > On Thu, Mar 16, 2023 at 6:48 AM Laurenz Albe > wrote: > >> As we wrote, some of us think that cursors are useful, and we tried to >> explain why we think that. If you don't think that cursors are useful, >> don't use them. We are no

Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

On Thu, Mar 16, 2023 at 9:23 AM Pavel Stehule wrote: > čt 16. 3. 2023 v 9:18 odesílatel Dominique Devienne > napsal: > >> [...] depends on what you value in a particular situation, latency or >> throughput. --DD >> > > cursors are optimized for minimal cost of first row, queries are optimized >

Re: pg_upgrade Only the install user can be defined in the new cluster

> On 15 Mar 2023, at 16:39, Dávid Suchan wrote: > > It prints out: > count > --- > 1 I have a feeling the cluster you tried to upgrade to doesn't match this one, as the check that failed will fail on values other than 1. Did you create them equally? If you try to upgrade into this cl

Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

čt 16. 3. 2023 v 9:55 odesílatel Dominique Devienne napsal: > On Thu, Mar 16, 2023 at 9:23 AM Pavel Stehule > wrote: > >> čt 16. 3. 2023 v 9:18 odesílatel Dominique Devienne >> napsal: >> >>> [...] depends on what you value in a particular situation, latency or >>> throughput. --DD >>> >> >> cu

Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

On Thu, Mar 16, 2023 at 11:15 AM Pavel Stehule wrote: > čt 16. 3. 2023 v 9:55 odesílatel Dominique Devienne > napsal: > >> On Thu, Mar 16, 2023 at 9:23 AM Pavel Stehule >> wrote: >> >>> čt 16. 3. 2023 v 9:18 odesílatel Dominique Devienne >>> napsal: >>> [...] depends on what you value in

Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

čt 16. 3. 2023 v 11:52 odesílatel Dominique Devienne napsal: > On Thu, Mar 16, 2023 at 11:15 AM Pavel Stehule > wrote: > >> čt 16. 3. 2023 v 9:55 odesílatel Dominique Devienne >> napsal: >> >>> On Thu, Mar 16, 2023 at 9:23 AM Pavel Stehule >>> wrote: >>> čt 16. 3. 2023 v 9:18 odesílatel D

Re: valgrind a background worker

On 2/10/23 9:08 PM, Jon Erdman wrote: > On 2/10/23 3:05 PM, Tom Lane wrote: >> Jeffrey Walton writes: >>> On Fri, Feb 10, 2023 at 10:04 AM Tom Lane wrote: You have to valgrind the whole cluster AFAIK.  Basically, start the postmaster under valgrind with --trace-children=yes. For l

Aw: Re: Removing trailing zeros (decimal places) from a numeric (pre trim_scale()) with unexpected behaviour

Hello Erik, many thanks for the feedback (Oracle) and the second option to get rid of the decimal separator character. The case is closed. Kind regards Juergen > Gesendet: Mittwoch, 15. März 2023 um 17:50 Uhr > Von: "Erik Wienhold" > An: magog...@web.de, pgsql-general@lists.postgresql.org > B

RE: EXTERNAL: Re: "No Free extents", table using all allocated space but no rows!

I messed up and confused issues. The error is : ERROR: Could not extend pg_tblspc/16555/PG_13_20200// No space left on device HINT: Check free disk space So the schema is "full" and the offender is this one table. I can't TRUNCATE as there needs to be space to perform the action.

Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

On 3/15/23 18:41, Bryn Llewellyn wrote: adrian.kla...@aklaver.com wrote: I have a hard time fathoming why someone who writes documentation does not actually read documentation. Ouch. In fact, I had read the whole of the "43.7. Cursors" section in the "PL/pg

Re: pg_upgrade Only the install user can be defined in the new cluster

So I tried upgrading into this brand new cluster I created(using initdb -D /somedatapathichose). Running the upgrade with --check worked, it returned message that the clusters are identical. Then I stopped the new cluster, and ran the pg_upgrade without --check, which resulted in another: Checki

Re: pg_upgrade Only the install user can be defined in the new cluster

=?Windows-1252?Q?D=E1vid_Suchan?= writes: > The ' SELECT COUNT(*) FROM pg_catalog.pg_roles WHERE rolname !~ '^pg_'; ' > prints count 4 4? That would be the problem all right. What are those, that is what do you get from SELECT rolname FROM pg_catalog.pg_roles WHERE rolname !~ '^pg_'; on the

Re: pg_upgrade Only the install user can be defined in the new cluster

> On 16 Mar 2023, at 15:56, Dávid Suchan wrote: > > So I tried upgrading into this brand new cluster I created(using initdb -D > /somedatapathichose). Running the upgrade with --check worked, it returned > message that the clusters are identical. Then I stopped the new cluster, and > ran the p

Re: EXTERNAL: Re: "No Free extents", table using all allocated space but no rows!

On Thu, 2023-03-16 at 13:20 +, Dolan, Sean wrote: > I messed up and confused issues.   The error is :  > ERROR: Could not extend pg_tblspc/16555/PG_13_20200//  No space left > on device > HINT: Check free disk space > > So the schema is "full" and the offender is this one table. > I

Many logical replication synchronization worker threads kicking off for ONE table

The initial email below was the end result of something "run-away" in my logical replication. PostGres 13.6, RedHat 7.9 Database A is the publisher; Database B is the subscriber.Within Database A are multiple schemas and the publication ensures that all the schemas and its tables are added

src/test/examples/testlibpq2.c where the HAVE_SYS_SELECT_H is defined.

Hi, playing around with $[0] testlibpq2.c example. I wondered where HAVE_SYS_SELECT_H is defined? I searched on the internet, founded that people also asked the same question in $[1]. In my machine, I do have . system version: Ubuntu 22.04.1 LTS gcc version: gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.