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
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
> 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-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.
> >
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 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.
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 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 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 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 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, 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,
12 matches
Mail list logo
