Re: Questions about the continuity of WAL archiving

Here’s a scenario: The latest WAL file on the primary node is 000100AF, and the standby node has also received up to 000100AF. However, the latest WAL file that has been successfully archived from the primary is only 000100A1 (WAL files from A2 to AE

Re: When UPDATE a row in a table with BEFORE ROW UPDATE trigger, the XMAX of new tuple is set to current XID

On Mon, 2025-08-11 at 11:34 +0800, Charles Qi wrote: > The trigger function in example is doing nothing but return new, the > row is actually locked by the trigger itself (trigger.c > > ExecBRUpdateTriggers > GetTupleForTrigger) > > You mentioned a very important behavior: > > A multixact is only n

Re: Questions about the continuity of WAL archiving

On Tue, Aug 12, 2025 at 10:24 PM px shi wrote: > How often does your primary node crash, and then not recover due to WALs >> corruption or WALs not existing? >> >> If it's _ever_ happened, you should _fix that_ instead of rolling your >> own WAL archival.process. >> > > I once encountered a case

Re: Questions about the continuity of WAL archiving

> > How often does your primary node crash, and then not recover due to WALs > corruption or WALs not existing? > > If it's _ever_ happened, you should _fix that_ instead of rolling your own > WAL archival.process. > I once encountered a case where the recovery process failed to restore to the la

Re: Questions about the continuity of WAL archiving

How often does your primary node crash, and then not recover due to WALs corruption or WALs not existing? If it's _ever_ happened, you should _fix that_ instead of rolling your own WAL archival.process. On Tue, Aug 12, 2025 at 10:05 PM px shi wrote: > Hi, Adrian > > Given that you are using a l

Re: Questions about the continuity of WAL archiving

Hi, Adrian Given that you are using a less then capable storage solution(S3) why do > you think pushing the WAL from the standby to S3 would perform any > better then what is happening with the primary WAL? > I mean that archive_mode is set to on in primary and set to always in standby. This way,

Re: Questions about the continuity of WAL archiving

On 8/12/25 10:40, Bob Jolliffe wrote: On Tue, 12 Aug 2025 at 17:14, Adrian Klaver > wrote: The solution is to use a more capable storage platform. That is an interesting point you make Adrian.  S3 seems quite popular for this type of archiving.  What wou

Re: Backups with filesystem snapshots

On Mon, Aug 11, 2025 at 12:41:12PM -0400, Greg Sabino Mullane wrote: > On Mon, Aug 11, 2025 at 9:01 AM Nick Cleaton wrote: > > If I take an instantaneous filesystem-level snapshot of the postgres > data directory underneath a running postgres server, is that a safe > backup without do

Re: Questions about the continuity of WAL archiving

On Tue, Aug 12, 2025 at 4:37 AM px shi wrote: > Bog-standard PgBackRest retains all WAL files required for a full backup >> set and its associated differential/incremental backups. > > Yes, WAL files are continuous under normal circumstances. However, if the > primary node crashes under high load

Re: Questions about the continuity of WAL archiving

On Tue, 12 Aug 2025 at 17:14, Adrian Klaver wrote: > On 8/12/25 01:24, px shi wrote: > > > > 1) What is the current archiving setup on the primary and why is > > lagging? > > > > The archive command uses pgBackRest to archive to S3. Because it is > > uploaded to S3, the archiving speed

Re: Questions about the continuity of WAL archiving

On 8/12/25 01:24, px shi wrote: 1) What is the current archiving setup on the primary and why is lagging?  The archive command uses pgBackRest to archive to S3. Because it is uploaded to S3, the archiving speed is slow, which has caused lagging. 2) Have you looked at archiving o

Re: Inquiry: Using PostgreSQL as a Staging Database for SAP ERP Data Export

On 8/12/25 08:13, Ron Johnson wrote: This link says that there's an ADBC driver for Postgresql: https:// arrow.apache.org/adbc/current/driver/status.html arrow.apache.org/adbc/current/driver/status.html> I believe that is a different beast. See: https://help.sap.com/doc/abapdocu_753_index_htm

Re: Inquiry: Using PostgreSQL as a Staging Database for SAP ERP Data Export

This link says that there's an ADBC driver for Postgresql: https://arrow.apache.org/adbc/current/driver/status.html You should probably research _IT_ and SAP as to why your SAP installation does not have the PG driver. On Tue, Aug 12, 2025 at 10:36 AM Ian Huang wrote: > Hi Greg, > > Thanks for

Re: Inquiry: Using PostgreSQL as a Staging Database for SAP ERP Data Export

Hi Greg, Thanks for your feedback. I’ve tried connecting to PostgreSQL using the ADBC method, but unfortunately the SAP Kernel doesn’t have the corresponding .os (DBMS) file, so the connection could not be established. May I ask if connecting via ADBC is actually feasible in this case? Best regar

Re: Bitnami deprecation

> On 11 Aug 2025, at 17:49, Adrian Klaver wrote: > On 8/11/25 08:33, Smith wrote: >> Not sure where to post this but the Postgres team should consider pulling >> the promotion for Bitnami on the downloads page. >> See: >> https://github.com/bitnami/charts/issues/35164 Reading that doesn't make

Re: Questions about the continuity of WAL archiving

> > Bog-standard PgBackRest retains all WAL files required for a full backup > set and its associated differential/incremental backups. Yes, WAL files are continuous under normal circumstances. However, if the primary node crashes under high load, the archived WAL logs on S3 may be discontinuous.

Re: Questions about the continuity of WAL archiving

> > I'm still not clear on what the problem here is, other than your archiving > not keeping up. In my scenario, archive_mode is not set to always on the replicas, it may cause interruptions in the archived WAL logs. You can set archive_mode=always on the replicas to help with this. Yes, it can

Re: Questions about the continuity of WAL archiving

> 1) What is the current archiving setup on the primary and why is lagging? The archive command uses pgBackRest to archive to S3. Because it is uploaded to S3, the archiving speed is slow, which has caused lagging. 2) Have you looked at archiving off the standby node while it is in standby > per