That's a little too vague of a question, but yes, Postgres should be able
to handle things just fine. The amount of SAP tools and SAP-supporting ETL
tools that also support Postgres should be a strong encouragement. I'd
recommend looking at the specific tools you would use and confirming they
have
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 doing any pg_start_backup/pg_stop_backup ?
>
Safe, yes[*], but not particularly recomm
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
Yeah, going here:
https://bitnami.com/tag/postgresql
gets a 404 page.
--
Adrian K
>
> possible that a single update statement could spill over as multiple CDC
> update records by pgoutput / postgres ?
Basically, no. If I understand your questions correctly, the answer seems
to point to your application making multiple updates, which will lead to
multiple UPDATE records in the
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
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 doing any pg_start_backup/pg_stop_backup ?
>
> It seems like it should be, so long as I
If I take an instantaneous filesystem-level snapshot of the postgres
data directory underneath a running postgres server, is that a safe
backup without doing any pg_start_backup/pg_stop_backup ?
It seems like it should be, so long as I get an atomic snapshot that
includes both data and wal, becaus
On Mon, Aug 11, 2025 at 3:34 AM Laurenz Albe wrote:
>
> On Fri, 2025-08-08 at 09:20 +0800, Charles Qi wrote:
> > Let me clarify the question, when the BEFORE ROW UPDATE trigger is presented
> > Q. Why do we need to set the XMAX of the new tuple to the current xid?
>
> Because the row gets locked,
