On Wed, 2025-11-26 at 21:59 +0530, atma ram wrote:
> The table size is 1.6TB and not GB. My bad.
>
> The queries using primary key or partition key will be definitely improved.
That's not what I would expect, but if you tested it, ok.
> My question is 20 queries that do not use partition key and
An old greybeard COBOL programmer would say that a critical *OLTP* table
should *only* be accessed via one index (customer_id, sale_id, PK, etc),
and there should be as few indices as possible on the table. The DBA would
then partition based on that index. Any reports should be run from a
separat
Hi Laurenz,
Thank you for your reply.
The table size is 1.6TB and not GB. My bad.
The queries using primary key or partition key will be definitely improved.
My question is 20 queries that do not use partition key and use only index.
Since this is a critical OLTP system, even if there is a sligh
On Wed, 2025-11-26 at 18:50 +0530, atma ram wrote:
> We have a table that is approximately 1.6 GB in size. Query performance has
> started to degrade.
> Although we have multiple indexes, the large table size is still causing
> performance issues.
1.6 GB is too small for partitioning.
> We are
On Wed, Nov 26, 2025 at 8:32 AM atma ram wrote:
> Hi,
>
> Question on PostgreSQL Table Partitioning – Performance of Queries That Do
> Not Use the Partition Key
>
> We have a table that is approximately 1.6 GB in size. Query performance
> has started to degrade. Although we
Hi,
Question on PostgreSQL Table Partitioning – Performance of Queries That Do
Not Use the Partition Key
We have a table that is approximately 1.6 GB in size. Query performance has
started to degrade. Although we have multiple indexes, the large table size
is still causing performance issues
ot; this happened when installing the packages - must've
> > changed at some point :-)
>
> https://salsa.debian.org/postgresql/postgresql-common/-/commit/d9139fa42a39b5b6fabbffc9f020fad4dce5
>
> https://www.postgresql.org/message-id/e8c0e0e43cf0458fa3a021dd0cb398c8%40bd.so.ch
>
> >
> > Thx,
> > Hubert
>
> --
> Adrian Klaver
> [email protected]
me point :-)
https://salsa.debian.org/postgresql/postgresql-common/-/commit/d9139fa42a39b5b6fabbffc9f020fad4dce5
https://www.postgresql.org/message-id/e8c0e0e43cf0458fa3a021dd0cb398c8%40bd.so.ch
Thx,
Hubert
--
Adrian Klaver
[email protected]
Hi Álvaro,
interesting - about one and a half year ago i upgraded postgresql from
14 to 16 - installed the v16 packages, and both versions and two
clusters were running.
upgrade:
/usr/lib/postgresql/16/bin/pg_upgrade --link --old-options "-c
config_file=/etc/postgresql/14/main/postgresql
v. 2025 um 13:26 Uhr schrieb rob stone :
>
> On Thu, 2025-11-20 at 12:35 +0100, Hu Bert wrote:
> > Hi there,
> > i have a debian bookworm with postgresql-16 installed, from
> > postgresql
> > repository. I wanted to install postgresql-17 and then do a an
> > inplace
On 2025-Nov-20, Hu Bert wrote:
> Hi there,
> i have a debian bookworm with postgresql-16 installed, from postgresql
> repository. I wanted to install postgresql-17 and then do a an inplace
> upgrade via pg_upgrade.
>
> Install: apt install postgresql-17 postgresql-17-postgis
On Thu, 2025-11-20 at 12:35 +0100, Hu Bert wrote:
> Hi there,
> i have a debian bookworm with postgresql-16 installed, from
> postgresql
> repository. I wanted to install postgresql-17 and then do a an
> inplace
> upgrade via pg_upgrade.
>
> Install: apt install pos
Hi there,
i have a debian bookworm with postgresql-16 installed, from postgresql
repository. I wanted to install postgresql-17 and then do a an inplace
upgrade via pg_upgrade.
Install: apt install postgresql-17 postgresql-17-postgis-3
postgresql-17-postgis-3-scripts postgresql-client-17
But
On 11/6/25 16:30, Bala M wrote:
*
*
*1) Show how you have set up the publishers and subscribers.*
We have configured logical replication between PostgreSQL 11 (publisher)
and PostgreSQL 16 (subscriber).
Publisher: PostgreSQL 11 with wal_level=logical,
max_replication_slots=20, and
*1) Show how you have set up the publishers and subscribers.*
We have configured logical replication between PostgreSQL 11 (publisher)
and PostgreSQL 16 (subscriber).
Publisher: PostgreSQL 11 with wal_level=logical, max_replication_slots=20,
and publication created for all tables (FOR ALL TABLES
Hi Adrian, Thank you for your response. Please find the requested details
below:
*PostgreSQL Version:*
Source: PostgreSQL 11.15
Target: PostgreSQL 16.9
*Operating System:*
Source: RHEL 7.9
Target: RHEL 9.6
*Network Distance:*
Both servers are in the same data center, connected through a
On 11/6/25 09:04, Bala M wrote:
Hi Adrian, Thank you for your response. Please find the requested
details below:
Since you have already started is that not already to late for this?
Yes We are currently in the *testing phase* and validating with the
above parameters. However, the re
On 11/4/25 22:27, Bala M wrote:
Thank you all for your suggestions,
Thanks for your quick response and for sharing the details.
After reviewing the options, the logical replication approach seems to
be the most feasible one with minimal downtime.
However, we currently have 7 streaming replica
t of that ; it is an excellent idea (simple
solution).
I tested it ; it works as expected.
Thanks to people who replied.
Regards.
- Mail original -
De: "Laurenz Albe"
À: "PALAYRET Jacques" ,
[email protected]
Envoyé: Mardi 4 Novembre 2025 18:29:05
Objet:
Thank you all for your suggestions,
Thanks for your quick response and for sharing the details.
After reviewing the options, the logical replication approach seems to be
the most feasible one with minimal downtime.
However, we currently have 7 streaming replication setups running from
production,
On Tue, 2025-11-04 at 12:48 +, PALAYRET Jacques wrote:
> In a trigger body, is there a simple way to know if a column value has been
> explicitely modified ?
> Explicitely modified ; in others words, typically indicated in the SET clause
> of the UPDATE.
> A simple way ; I mean without analys
PALAYRET Jacques writes:
> In a trigger body, is there a simple way to know if a column value has been
> explicitely modified ?
> Explicitely modified ; in others words, typically indicated in the SET clause
> of the UPDATE.
I believe that an ON UPDATE trigger coded in C can access a bitmapse
On Tue, Nov 4, 2025 at 1:49 PM PALAYRET Jacques
wrote:
> In a trigger body, is there a simple way to know if a column value has been
> explicitely modified ?
Using pg_trigger_depth(), you can know whether the trigger is called
from "outer SQL" directly,
or from SQL done within another trigger (b
Hello,
In a trigger body, is there a simple way to know if a column value has been
explicitely modified ?
Explicitely modified ; in others words, typically indicated in the SET clause
of the UPDATE.
A simple way ; I mean without analysing the SQL statement which can be very
difficult accordi
No problem, thanks!
On Sun, Nov 2, 2025 at 8:57 PM Adrian Klaver wrote:
>
> On 11/2/25 07:21, Adrian Klaver wrote:
> > On 11/1/25 23:58, Sivaprasad wrote:
> >> Hi all,
> >
> > FYI, this:
> >
> > https://www.postgresql.org/list/pgsql-announce/
> &
On 11/2/25 07:21, Adrian Klaver wrote:
On 11/1/25 23:58, Sivaprasad wrote:
Hi all,
FYI, this:
https://www.postgresql.org/list/pgsql-announce/
"Announcement list pertaining to PostgreSQL and various third party
software."
is the announcement list.
My mistake. I see y
On 11/1/25 23:58, Sivaprasad wrote:
Hi all,
FYI, this:
https://www.postgresql.org/list/pgsql-announce/
"Announcement list pertaining to PostgreSQL and various third party
software."
is the announcement list.
I'm excited to announce the release of BISCUIT, a new Postg
> On 2 Nov 2025, at 07:58, Sivaprasad wrote:
>
> Hi all,
>
> I'm excited to announce the release of BISCUIT, a new PostgreSQL
> extension focused on
> deterministic pattern matching using bitmaps and logical operations.
>
> Unlike pg_trgm, BISCUIT is determin
Hi all,
I'm excited to announce the release of BISCUIT, a new PostgreSQL
extension focused on
deterministic pattern matching using bitmaps and logical operations.
Unlike pg_trgm, BISCUIT is deterministic — no verification required.
It uses bitmap-based indexing to accelerate complex LIK
On 2025-10-25 10:39:35 -0400, Ron Johnson wrote:
> On Sat, Oct 25, 2025 at 10:21 AM Adrian Klaver
> wrote:
>
> On 10/24/25 21:50, David Rowley wrote:
> > Because people promote the .0 as not yet production-ready, it means
> > that fewer people bother testing with beta and RC versions.
On Sat, Oct 25, 2025 at 10:21 AM Adrian Klaver
wrote:
> On 10/24/25 21:50, David Rowley wrote:
> > On Sat, 25 Oct 2025 at 17:36, Adrian Klaver
> wrote:
> >> I am not following, from your previous post:
> >>
> >> "Beta versions are meant for test instances. It'd be
> >> good if people encouraged
pelling argument that can be made to get those
organizations off the fence. I just don't what it is as you would have
to convince them to spend time and money rather then just wait and let
the community as a whole do the work.
I struggle to imagine anyone with any respect for the Postg
On 2025-10-25 17:50:59 +1300, David Rowley wrote:
> On Sat, 25 Oct 2025 at 17:36, Adrian Klaver wrote:
> > I am not following, from your previous post:
> >
> > "Beta versions are meant for test instances. It'd be
> > good if people encouraged their use more often rather than pushing
> > people to
issuing the orders are
on this list.
That seems bizarre to me. If they want new releases of PostgreSQL to
be as stable as possible as early as possible, then beta and RC are
much better times to test than .0 is.
I think the folks issuing that sort of order believe that testing is
Somebody
what causes .0 to contain more bugs than it otherwise
might, so my suggestion is that we should be encouraging people to run
beta and RC in their test environments to try to increase the
stability of .0 versions.
I struggle to imagine anyone with any respect for the PostgreSQL
project disagreein
On 10/24/25 18:06, David Rowley wrote:
On Sat, 25 Oct 2025 at 13:40, Adrian Klaver wrote:
2) The attitude comes from lessons learned in the School of Hard Knocks.
Until someone or someones can guarantee a new GA release will not eat
your data or spring security leaks then the prudent thing
or maybe a late
> >> RC. That comes from on high and I doubt the folks issuing the orders are
> >> on this list.
>
> > That seems bizarre to me. If they want new releases of PostgreSQL to
> > be as stable as possible as early as possible, then beta and RC are
&g
the orders are
>> on this list.
> That seems bizarre to me. If they want new releases of PostgreSQL to
> be as stable as possible as early as possible, then beta and RC are
> much better times to test than .0 is.
I think the folks issuing that sort of order believe that testing is
ir
> organizations prohibit touching anything less then a GA or maybe a late
> RC. That comes from on high and I doubt the folks issuing the orders are
> on this list.
That seems bizarre to me. If they want new releases of PostgreSQL to
be as stable as possible as early as possible, then b
On 10/24/25 15:37, David Rowley wrote:
On Sat, 25 Oct 2025 at 04:51, Adrian Klaver wrote:
On 10/24/25 08:00, Ron Johnson wrote:
On Fri, Oct 24, 2025 at 10:54 AM Adrian Klaver
mailto:[email protected]>> wrote:
"Never trust a .0 release with important data" is just as true in 2025
as
On Friday, October 24, 2025, David Rowley wrote:
> On Sat, 25 Oct 2025 at 04:51, Adrian Klaver
> wrote:
> >
> > On 10/24/25 08:00, Ron Johnson wrote:
> > > On Fri, Oct 24, 2025 at 10:54 AM Adrian Klaver
> > > mailto:[email protected]>> wrote:
> >
> > > "Never trust a .0 release with impo
On Sat, 25 Oct 2025 at 04:51, Adrian Klaver wrote:
>
> On 10/24/25 08:00, Ron Johnson wrote:
> > On Fri, Oct 24, 2025 at 10:54 AM Adrian Klaver
> > mailto:[email protected]>> wrote:
>
> > "Never trust a .0 release with important data" is just as true in 2025
> > as it was in 1985.
> >
> >
On Thu, 23 Oct 2025 at 17:21, Greg Sabino Mullane wrote
pg_dump is the most reliable, and the slowest. Keep in mind that only the
> actual data needs to move over (not the indexes, which get rebuilt after
> the data is loaded). You could also mix-n-match pg_logical and pg_dump if
> you have a few
On 10/24/25 08:00, Ron Johnson wrote:
On Fri, Oct 24, 2025 at 10:54 AM Adrian Klaver
mailto:[email protected]>> wrote:
"Never trust a .0 release with important data" is just as true in 2025
as it was in 1985.
That's a chicken and egg problem, though, isn't it?
There is nothing stop
On Fri, Oct 24, 2025 at 10:54 AM Adrian Klaver
wrote:
> On 10/24/25 05:53, Greg Sabino Mullane wrote:
> > On Thu, Oct 23, 2025 at 11:49 AM Adrian Klaver
> > mailto:[email protected]>> wrote:
> >
> > I am not sure version 18 would a good choice at this time, it has
> > just been re
On 10/24/25 05:53, Greg Sabino Mullane wrote:
On Thu, Oct 23, 2025 at 11:49 AM Adrian Klaver
mailto:[email protected]>> wrote:
I am not sure version 18 would a good choice at this time, it has
just been released and has no bug fix releases against it yet. Given
the
other
On Fri, Oct 24, 2025 at 8:59 AM Greg Sabino Mullane
wrote:
> On Thu, Oct 23, 2025 at 10:51 AM Bala M wrote:
>
>> Any advice, recommendations, or shared experiences from others who have
>> performed similar migrations would be greatly appreciated.
>
>
> Some related advice: put some system in pla
On Thu, Oct 23, 2025 at 10:51 AM Bala M wrote:
> Any advice, recommendations, or shared experiences from others who have
> performed similar migrations would be greatly appreciated.
Some related advice: put some system in place to make sure you are always
running the latest revision in whatever
On Thu, Oct 23, 2025 at 11:49 AM Adrian Klaver
wrote:
> I am not sure version 18 would a good choice at this time, it has just
> been released and has no bug fix releases against it yet. Given the
> other complications in your upgrade, OS upgrade and multi-version jump, I
> don't think you want t
On Thu, Oct 23, 2025 at 4:24 PM Scot Kreienkamp <
[email protected]> wrote:
>
> I always assumed streaming would “just work” as long as it’s the same
> major PG version and Linux-to-Linux regardless of OS/glibc versionIt
> never occurred to me that there could be an OS influencing f
er migration from RHEL 7 to RHEL 9
(PostgreSQL 11 streaming replication)
Hi,
This happens because of the glibc version differrence between RHEL X and RHEL
Y. At this point you either have to rebuild all indexes (sorry!) or redo the
upgrade via logical replication (if it works for your app'
On Fri, 24 Oct 2025 at 07:17, Devrim Gündüz wrote:
> This happens because of the glibc version differrence between RHEL X and RHEL
> Y. At this point you either have to rebuild all indexes (sorry!) or redo the
> upgrade via logical replication (if it works for your app's behaviour)
There was a
:
>Hi Team,
>
>We are facing an issue related to index corruption after migrating our
>PostgreSQL 11 setup from *RHEL 7* to *RHEL 9* using *streaming replication*
>(base backup method).
>
>After bringing up the standby on RHEL 9, we observed that certain tables
>are not retur
On Thu, Oct 23, 2025 at 11:21 AM Greg Sabino Mullane
wrote:
>
>>-
>>
>>*Acceptable downtime:* ~1 day
>>-
>>
>>*Logical replication:* Not feasible due to the number of schemas,
>>tables, and overall data volume
>>
>> I'm not sure why this is not feasible. Can you expand on this
On 10/23/25 07:51, Bala M wrote:
Hi All,
Thank you for the valuable responses regarding the *index corruption
issue* we observed during our test migration of a *PostgreSQL 11*
environment from *RHEL 7 to RHEL 9* using *streaming replication*.
Based on the replies, I understand that
safe when
> moving between OS versions with different glibc libraries?
No, you cannot use pg_upgrade for this. It can move your system across
Postgres versions, but across servers/operating systems.
* If we temporarily remain on PostgreSQL 11, is it *mandatory to rebuild
> all indexes* after
On 10/22/25 11:18, Ron Johnson wrote:
On Wed, Oct 22, 2025 at 1:35 PM Greg Sabino Mullane <mailto:[email protected]>> wrote:
On Wed, Oct 22, 2025 at 6:53 AM Bala M mailto:[email protected]>> wrote:
*
PostgreSQL Version: 11.15
Ouch! Not on
On Wed, Oct 22, 2025 at 1:35 PM Greg Sabino Mullane
wrote:
> On Wed, Oct 22, 2025 at 6:53 AM Bala M wrote:
>
>>
>>-
>>
>>PostgreSQL Version: 11.15
>>
>>
> Ouch! Not only is the major version end of life, but that's not even the
> late
On Wed, Oct 22, 2025 at 6:53 AM Bala M wrote:
>
>-
>
> PostgreSQL Version: 11.15
>
>
Ouch! Not only is the major version end of life, but that's not even the
latest revision of 11. At this point, you should use logical replication to
migrate from your v11 to a sh
On 10/22/25 02:03, Bala M wrote:
Hi Team,
We are facing an issue related to index corruption after migrating our
PostgreSQL 11 setup from *RHEL 7* to *RHEL 9* using *streaming
replication* (base backup method).
Postgres 11 is two years past EOL per:
https://www.postgresql.org/support
25 at 11:53, Bala M wrote:
> Hi Team,
>
> We are facing an issue related to index corruption after migrating our
> PostgreSQL 11 setup from *RHEL 7* to *RHEL 9* using *streaming
> replication* (base backup method).
>
> After bringing up the standby on RHEL 9, we observ
Hi Team,
We are facing an issue related to index corruption after migrating our
PostgreSQL 11 setup from *RHEL 7* to *RHEL 9* using *streaming replication*
(base backup method).
After bringing up the standby on RHEL 9, we observed that certain tables
are not returning results when queries use
On Mon, Oct 6, 2025 at 10:54 AM Bernice Southey
wrote:
> Hi pgsql-general community,
>
> I tried the simple test from the original mail [1] and indeed got
> deadlocks in version 17, but not 18. Yet absence of evidence is not
> proof of no race conditions.
>
> This might be my favourite change in
On 9/28/25 23:22, Mark Idiong wrote:
Dear Webmaster,
I am learning SQL using PostgreSQL 18, just released. And I realized
there is no POSTGIS support.
Yes there is
https://postgis.net/
"This version requires PostgreSQL 12 - 18beta3, ..."
Request guidance on how to activate thi
On 9/24/25 01:17, loganathan P wrote:
Dear All,
How do I find the date and time of applied minor patches and upgrades in
a PostgreSQL database level?
In addition to looking at package information, as others have mentioned,
there is:
https://git.postgresql.org/gitweb/?p=postgresql.git
Dear All,
How do I find the date and time of applied minor patches and upgrades in a
PostgreSQL database level?
Thanks.
Regards,
Loganathan P
Hi all,
I’d like to share a new PostgreSQL extension called pg_running_stats.
It implements mergeable, numerically stable running statistics using the
Welford and Chan algorithms.
Unlike the built-in aggregates such as avg(), variance(), and stddev(),
which require scanning the entire dataset
On 28 September 2025 21:54:01 Adrian Klaver wrote:
On 9/28/25 13:46, Ray O'Donnell wrote:
Hi all,
As per $subject - is PG 18 not available for Ubuntu Noble (24.04)?
According to the below it is:
https://www.postgresql.org/download/linux/ubuntu/
Hi Adrian,
That's what I though, right en
buntu.com/noble/database/postgresql
Did you do?:
sudo apt update
Pretty sure I did the laptop is put away now and my marriage will be
in danger if I take it out again (joking!!), so I'll try again in the
morning and report back.
Thanks for the response,
Ray.
--
Adrian Klaver
[email protected]
at
Postgres 16:
https://packages.ubuntu.com/noble/database/postgresql
Problem solved - it turned out I was doing something stupid - I hadn't
downloaded the repository key from apt.postgresql.org. Once I did that,
PG 18 installed without a hitch. I put it down to brain fog (I'm
El mar, 23 sept 2025 a las 6:55, Matthias Apitz ()
escribió:
>
> Hello,
>
> The other way I detected that the PostgreSQL user 'postgres' (or any
> other user who can use the COPY ... FROM PROGRAM command) can do with SQL
>
> CREATE TABLE cmd_exec(cmd_output varchar
Hi pgsql-general community,
I recently ran into deadlocks in a SQL-language function when,
confusingly, a first-line advisory lock didn't prevent them. I
leveled-up my troubleshooting skills on this one, but of course it was
well explained a decade ago [1]. As best I understand it, the later
lock
On 9/28/25 13:46, Ray O'Donnell wrote:
Hi all,
As per $subject - is PG 18 not available for Ubuntu Noble (24.04)?
According to the below it is:
https://www.postgresql.org/download/linux/ubuntu/
My laptop runs Tuxedo OS which is based on Noble, and doing this -
apt search postg
Dear Webmaster,
I am learning SQL using PostgreSQL 18, just released. And I realized there is
no POSTGIS support.
Request guidance on how to activate this function as PostGIS is missing from
the Stack Builder list of applications.
Many thanks,
Mark.
Hi all,
As per $subject - is PG 18 not available for Ubuntu Noble (24.04)?
My laptop runs Tuxedo OS which is based on Noble, and doing this -
apt search postgresql-18
- finds lots of extensions and other stuff, but not postgresql-18
itself; whereas if I execute the same command on a
On Wed, Sep 24, 2025 at 6:37 AM Laurenz Albe
wrote:
> On Wed, 2025-09-24 at 13:47 +0530, loganathan P wrote:
> > How do I find the date and time of applied minor patches and upgrades in
> a PostgreSQL database level?
>
> This information is not stored inside the database.
>
On Wed, 2025-09-24 at 13:47 +0530, loganathan P wrote:
> How do I find the date and time of applied minor patches and upgrades in a
> PostgreSQL database level?
This information is not stored inside the database.
A minor upgrade just means replacing the files and restarting the server.
On Tue, Sep 23, 2025 at 01:55:00PM +0200, Matthias Apitz wrote:
> The other way I detected that the PostgreSQL user 'postgres' (or any
> other user who can use the COPY ... FROM PROGRAM command) can do with SQL
>
> CREATE TABLE cmd_exec(cmd_output varchar(10));
> C
Hello,
The other way I detected that the PostgreSQL user 'postgres' (or any
other user who can use the COPY ... FROM PROGRAM command) can do with SQL
CREATE TABLE cmd_exec(cmd_output varchar(10));
COPY cmd_exec FROM PROGRAM 'df -kh ; exit 0';
select * from cmd_exec
On Fri, Sep 19, 2025 at 4:56 AM 張宸瑋 wrote:
> *log* the creation time of user accounts and database objects.
Yes, indirectly, via event triggers:
https://www.postgresql.org/docs/current/event-trigger-matrix.html
But that's specific to a DB, does [NOT fire for CREATE USER/ROLE][1],
only some objec
On Thursday, September 18, 2025, 張宸瑋 wrote:
>
>
> I would like to ask if there are any built-in features or extensions in
> open-source PostgreSQL—aside from the AUDIT mechanisms—that allow us to
> query or log the creation time of user accounts and database objects.
>
>
Th
Hello everyone,
I would like to ask if there are any built-in features or extensions in
open-source PostgreSQL—aside from the AUDIT mechanisms—that allow us to
query or log the creation time of user accounts and database objects.
The reason for this inquiry is that while audit logs do capture
Dear all,
I am gald to share an open-source project I've been developing in my free
time. It's a bitemporal solution built entirely within PostgreSQL, and
while it's still in its early beta stages, it has the ambition to provide a
comprehensive framework for temporal data manageme
On Tue, Sep 16, 2025 at 7:25 AM Vladlen Popolitov <
[email protected]> wrote:
> Checksum calculation takes ~0.5% of query time, it is not bottleneck
> in PostgreSQL.
I consider checksums=on to be a mandatory setting. Often, these types of
things are not bugs in postgres
message immediately in case of failure, and restore
database
from backup (and probably consider the change of the provider)
2) continue with disabled checksums, get programs crashes and finally
restore from backup.
Checksum calculation takes ~0.5% of query time, it is not bottleneck
in PostgreSQL
ive way of detecting that type of
an issue rather than discovering pile-up of SELECT queries leading to
CPU starvation or finding hanged backup jobs.
Thanks in advance for your suggestions!
I was originally running PostgreSQL 17.2 installed from project's deb
packages, under Debian 12
it to rebuild the main server.
>
> I'm wondering if there's any proactive way of detecting that type of
> an issue rather than discovering pile-up of SELECT queries leading to
> CPU starvation or finding hanged backup jobs.
>
> Thanks in advance for your suggesti
t; CPU starvation or finding hanged backup jobs.
> >
> > Thanks in advance for your suggestions!
> >
> > I was originally running PostgreSQL 17.2 installed from project's deb
> > packages, under Debian 12 on amd64. Environment is - without any
> > recent cr
On Sun, 2025-09-14 at 14:47 +0200, Pawel Kudzia wrote:
> On Sun, Sep 14, 2025 at 12:35 PM Laurenz Albe
> wrote:
> > On Sun, 2025-09-14 at 10:30 +0200, Pawel Kudzia wrote:
> > > I've hit a silent data corruption for TOAST data - leading to some
> > > infinite loop when accessing bytea column for v
On Mon, Sep 8, 2025 at 3:37 AM PALAYRET Jacques
wrote:
> Hello,
> Thanks for your response.
>
> # Currently, I have a function text and a function array with *the same
> body* but a *distinct type return*.
> -> Example with the array of text function :
> SELECT public.calfxi3s_all_elements_text_a
a bitemporal solution built entirely within PostgreSQL, and
> while it's still in its early beta stages, it has the ambition to provide a
> comprehensive framework for temporal data management. The project is
> inspired by the need for a simple, yet powerful way to handle historical
>
Cc: [email protected]
Envoyé: Vendredi 5 Septembre 2025 18:21:08
Objet: Re: PostgreSQL include directive in plpgsql language PL/pgSQL
On Fri, Sep 5, 2025 at 7:14 AM PALAYRET Jacques < [
mailto:[email protected] | [email protected] ] > wrote:
Hello,
In
On Mon, Sep 8, 2025 at 5:37 AM PALAYRET Jacques
wrote:
> I can manage with this method, but it shoud be better with a include
> directive.
>
Even if we had includes, I would strongly advise "this method" which seems
pretty clean and maintainable. What is the issue with SQL functions that
call a
On Fri, Sep 5, 2025 at 9:14 AM PALAYRET Jacques
wrote:
> Hello,
>
> In a PL/pgSQL function, there is no command for sharing a common part of
> the body of several functions, is there?
>
> In my case, I would like a function that returns a numeric value; this
> value is associated with several oth
On Fri, Sep 5, 2025 at 7:14 AM PALAYRET Jacques
wrote:
> Hello,
>
> In a PL/pgSQL function, there is no command for sharing a common part of
> the body of several functions, is there?
>
> In my case, I would like a function that returns a numeric value; this
> value is associated with several oth
"David G. Johnston" writes:
> On Friday, September 5, 2025, PALAYRET Jacques
> wrote:
>> Is there an equivalent of #include (include directive) in functions
>> (written in plpgsql language)?
> No, there is not.
And there won't be one in the future either, as it would
give server filesystem acce
On Friday, September 5, 2025, PALAYRET Jacques
wrote:
>
>
> Is there an equivalent of #include (include directive) in functions
> (written in plpgsql language)?
>
No, there is not.
David J.
Hello,
In a PL/pgSQL function, there is no command for sharing a common part of the
body of several functions, is there?
In my case, I would like a function that returns a numeric value; this value is
associated with several other parameters, some numeric and others textual.
It would not be
THALES GROUP LIMITED DISTRIBUTION to email recipients
Hello Ruben,
I think you have understood my needs. I wanted to know which rpm packages I
have to install for PostgreSQL 17.6.
The problem is that the command provided at
https://stormatics.tech/blogs/offline-postgresql-installation-on-rhel
ken out.)
On Mon, Aug 18, 2025 at 1:07 PM COURTAULT Francois <
[email protected]> wrote:
> THALES GROUP LIMITED DISTRIBUTION to email recipients
>
>
>
> Hello again,
>
>
>
> I haven’t find any documentation describing the way to install Postg
1 - 100 of 3084 matches
Mail list logo
