On Sat, 2025-09-27 at 01:45 +0530, veem v wrote:
> If we want to identify, what exact query inside a procedure is taking a
> longer time:
> - Using any pg_* views, Is there an easy way to tie the query_id of the
> procedure
> with the query_ids of the internal sqls(those are executed within the
On Fri, Sep 26, 2025 at 4:15 PM veem v wrote:
> Thank you so much for the quick response. I have a follow up question on
> this as below,
>
> If we want to identify, what exact query inside a procedure is taking a
> longer time:- Using any pg_* views, Is there an easy way to tie the
> query_id of
On 9/24/25 16:03, Adrian Klaver wrote:
On 9/24/25 10:02, Samuel Marks wrote:
On Wed, Sep 24, 2025 at 10:13 AM Adrian Klaver
I don't have enough experience with below to come up with an off the top
of my head examples, but they look like they may offer alternatives.
MERGE:
https://www.postg
Thank you so much for the quick response. I have a follow up question on
this as below,
If we want to identify, what exact query inside a procedure is taking a
longer time:- Using any pg_* views, Is there an easy way to tie the
query_id of the procedure with the query_ids of the internal sqls(thos
Ashish Mukherjee writes:
> When I do dump/restore like this for a test table, I get the following
> errors during restore but the table gets restored fine.
> pg_restore: error: while PROCESSING TOC:
> error: pg_restore: error: pg_restore: from TOC entry 17168; 1259
> 58572315 TABLE pkgs s14
Adrian Klaver writes:
> On 9/26/25 05:18, Ashish Mukherjee wrote:
>> 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 w
On 9/26/25 05:18, Ashish Mukherjee wrote:
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.
What are the in
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, Ashish Mukherj
On Fri, Sep 26, 2025 at 10:27 AM Laurenz Albe
wrote:
> On Fri, 2025-09-26 at 17:48 +0530, Ashish Mukherjee wrote:
>
[snip]
> > pg_restore: error: while PROCESSING TOC:
> > error: pg_restore: error: pg_restore: from TOC entry 17168; 1259
> 58572315 TABLE pkgs s14
> > pg_restore: error: pg_re
On Fri, 2025-09-26 at 17:48 +0530, Ashish Mukherjee wrote:
> 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
Yes, PgSQL 12 also had TDE
The upgrade was done by taking a complete dump of the schema + data from
v12 instance and then restoring to v17. Used pg_dump and pg_restore
respectively.
Yes, Vacuum analyze was also run on the new instance.
On Fri, Sep 26, 2025 at 12:40 AM Adrian Klaver
wrote:
> On
On Thu, Jul 31, 2025 at 2:34 PM Dominique Devienne wrote:
> On Thu, Jun 5, 2025 at 4:57 AM Tom Lane wrote:
> > Dominique Devienne writes:
> > > Unfortunately, digging into this is not something I can do right away.
> > > v18 is still a few months out, I do hope I can investigate before that.
> >
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
On Fri, Sep 26, 2025 at 8:06 AM Dan Mahoney (Gushi)
wrote:
> Hey folks,
>
> In the interest of automation, I've set up a pgpass file for my
> pg_basebackup between master and standby. This all works, thusly:
>
> pg_basebackup -d
> 'postgres://[email protected]:5432/foo?sslmode=verify-ca' -F p
> -
Hey folks,
In the interest of automation, I've set up a pgpass file for my
pg_basebackup between master and standby. This all works, thusly:
pg_basebackup -d
'postgres://[email protected]:5432/foo?sslmode=verify-ca' -F p
--wal-method=stream -P -R -D /var/db/postgres/data17-test3
However, i
Hello,
We want to have monitoring on three things 1) If the database restarted or
went down in the last few hours? 2)If the connections are high 3) High
tablespace growth . Want to understand , if we can utilize below queries
for the same or any flaws in this strategy?
1)SELECT
CASE
WHEN now
16 matches
Mail list logo
