On Tue, 2022-12-27 at 00:48 -0600, Ron wrote:
> If it really is a critical production database, you will have a CAT/UAT
> (customer/user acceptance testing)
> server on which you rigorously run regression tests on a point release for a
> month before updating the production server.
>
> Otherwise,
> On Jan 5, 2023, at 21:28, Laurenz Albe wrote:
>
> On Tue, 2023-01-03 at 16:03 +, Zwettler Markus (OIZ) wrote:
>> We are using a DIY Postgres backup:
>> ---
>> psql -c "select pg_start_backup ('Full');"
>> save -s "${NSR_SERVER}" -g "${NSR_POOL}" "${PGDATA}"
>> psql -c "select pg_stop_bac
On Tue, 2023-01-03 at 16:03 +, Zwettler Markus (OIZ) wrote:
> We are using a DIY Postgres backup:
> ---
> psql -c "select pg_start_backup ('Full');"
> save -s "${NSR_SERVER}" -g "${NSR_POOL}" "${PGDATA}"
> psql -c "select pg_stop_backup();"
> ---
> The pg_wal directory is not saved with it beca
> On Jan 5, 2023, at 19:38, Bhautik Chudasama
> wrote:
>
> Does it mean when we commit transaction, client will wait until all replicas
> successfully committed the transaction.
It depends. If all the settings are the defaults, no, the client won't wait
for the replicas to acknowledge the
> On Jan 5, 2023, at 16:03, Ron wrote:
>
> Even in asynchronous replication?
Yes. Asynchronous replication controls when the client doing the transaction
is told that the transaction is complete; it doesn't allow for dirty reads on
either the primary or secondary.
On 1/5/23 14:09, Christophe Pettus wrote:
On Jan 5, 2023, at 12:07, Louis Laborde wrote:
Are PG replicas updated atomically following the same transactions boundaries
as the source DB ?
Yes. The same transactional guarantees apply to the replica as do to the
original transactions on the pri
> On Jan 5, 2023, at 12:07, Louis Laborde wrote:
>
> Are PG replicas updated atomically following the same transactions boundaries
> as the source DB ?
Yes. The same transactional guarantees apply to the replica as do to the
original transactions on the primary.
Are PG replicas updated atomically following the same transactions
boundaries as the source DB ?
For example, if 2 rows from a named table are updated atomically (with a
transaction) in the source DB, is there a guarantee that both
changes will be done atomically in a replica, or is there a time wi
On 2023-01-05 12:34:08 +0100, Karsten Hilbert wrote:
> > Von: "Peter J. Holzer"
> > On 2023-01-04 09:34:42 -0600, Ron wrote:
> > > I don't think VACUUM FULL (copy the table, create new indices and other
> > > metadata all in one command) actually vacuums tables. It's a misleading
> > > name.
> >
> Von: "Peter J. Holzer"
> On 2023-01-04 09:34:42 -0600, Ron wrote:
> > I don't think VACUUM FULL (copy the table, create new indices and other
> > metadata all in one command) actually vacuums tables. It's a misleading
> > name.
>
> Move all the stuff from the living room to the bedroom and the
On 2023-01-04 09:34:42 -0600, Ron wrote:
> I don't think VACUUM FULL (copy the table, create new indices and other
> metadata all in one command) actually vacuums tables. It's a misleading
> name.
Move all the stuff from the living room to the bedroom and then jettison
the living room.
Isn't tha
On 1/4/2023 9:34 AM, Ron wrote:
I don't think VACUUM FULL (copy the table, create new indices and
other metadata all in one command) actually vacuums tables. It's a
misleading name.
Something like REBUILD TABLE would be a better name.
Well s***.
That explains a lot. Thanks for clearing th
12 matches
Mail list logo
