pgsql 17.5 on Red Hat Enterprise Linux release 8.10 (Ootpa)
The query is run from one of our php applications.
On Fri, Nov 7, 2025 at 8:59 PM Laurenz Albe
wrote:
> On Fri, 2025-11-07 at 19:18 +0530, Ashish Mukherjee wrote:
> > I have a query like this showing up on my production
Hello,
I have a query like this showing up on my production database -
s05=> SELECT pid, user, usename, application_name, client_addr,
client_hostname, client_port, datname, now() - query_start as "runtime",
state, wait_event_type, wait_event,
substr(query, 0, 100)
FROM pg_stat_activity
WHERE
I think the conclusion is to do a more thorough testing before the upgrade
next time. Have updated our playbook for upgrades to include more thorough
testing.
On Tue, Sep 30, 2025 at 8:17 PM Adrian Klaver
wrote:
> On 9/30/25 01:23, Ashish Mukherjee wrote:
> > Thank you all for yo
. Cybertec's technology is one
route, the other is EDB. I am happy to hear experiences of folks here with
pgsql encryption options for v17 on large databases (2.5T in our case).
On Mon, Sep 29, 2025 at 5:10 AM Merlin Moncure wrote:
> On Fri, Sep 26, 2025 at 8:16 AM Ashish Mukherjee <
>
Hello,
Thank you to the group members for the responses to my previous questions
about TDE problems with PgSQL 17.
I would like to enquire that based on the anecdotal experience of group
members, which TDE solution works best for PgSQL 17 databases. The scenario
I have is of a large number of tab
Thank you, Laurenz.
Yes, I say binary dump/restore would be faster because of the -j option.
Well, I suppose there's no certainty of what might break without going
through the whole process.
On Fri, Sep 26, 2025 at 7:57 PM Laurenz Albe
wrote:
> On Fri, 2025-09-26 at 17:48 +0530
:
> On 9/25/25 04:36, Ashish Mukherjee wrote:
> > Hello,
> >
> > I recently upgraded from pgsql 12 to pgsql 17. It's a Percona TDE
> > enabled database. However, after the upgrade the query planning time has
> > shot up by 10x when I check explain analyze output.
>
Hello,
I have a strange requirement to downgrade from pgsql 17 to pgsql 12. This
is because we found in production certain incompatibilities between both
versions for our database. It should have been caught in testing but was
not.
The clean way seems to be text file dump and restore but this wou
Hello,
I recently upgraded from pgsql 12 to pgsql 17. It's a Percona TDE enabled
database. However, after the upgrade the query planning time has shot up by
10x when I check explain analyze output.
The difference in planning time is visible here. The first case is pgsql 17
with TDE. The second ca
