Re: unexpected pageaddr in WAL segment

Maybe disk block corruption, try to delete it in standby if it has been applied. Best regards, Steven On Wed, May 14, 2025 at 12:22 AM Luca Ferrari wrote: > In one physical replica running version 17.4 I'm seeing this entries > repeated in the logs: > > unexpected pageaddr 0/400 in WAL segm

Re: How to have a smooth migration

On 5/15/25 09:29, veem v wrote: This is what Sqitch(https://sqitch.org/ ) was designed for. The biggest issue is that the data will be incrementing while you do the structural changes. How you handle that is going to depend on the question raised by

Re: How to have a smooth migration

> > > > This is what Sqitch(https://sqitch.org/) was designed for. > > The biggest issue is that the data will be incrementing while you do the > structural changes. How you handle that is going to depend on the > question raised by Peter J. Holzer: > Is this being done in place on one Postgres in

Re: How to have a smooth migration

On 5/14/25 23:09, veem v wrote: Hi, Its postgres database behind the scenes. We have a use case in which the customer is planning to migrate data from an older version (V1) to a newer version (V2). For V2, the tables will be new, but their structure will be similar to the V1 version with few

Re: where to find pg coverage report of history release

"=?ISO-8859-1?B?bWlv?=" <850455...@qq.com> writes: > In https://coverage.postgresql.org, there is only the coverage report for the > latest pg release. where can i find report of historical versions? We don't track that. It's not very hard to make your own though: https://www.postgresql.org/doc

where to find pg coverage report of history release

Hi: In https://coverage.postgresql.org, there is only the coverage report for the latest pg release. where can i find report of historical versions?     regards, mio

Re: How to have a smooth migration

On 5/15/25 07:09, veem v wrote: Hi, Its postgres database behind the scenes. We have a use case in which the customer is planning to migrate data from an older version (V1) to a newer version (V2). For V2, the tables will be new, but their structure will be similar to the V1 version with fe

Re: How to have a smooth migration

On 2025-05-15 11:39:39 +0530, veem v wrote: > Hi, > Its postgres database behind the scenes. > > We have a use case in which the customer is planning to migrate data from an > older version (V1) to a newer version (V2). For V2, the tables will be new, > but > their structure will be similar to th