Dear Adrian,
We are using "pg_log_archive" for Point-in-Time Recovery and DR replication.
Regards,
Ram Pratap.
-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@aklaver.com]
Sent: 21 April 2022 21:35
To: Ram Pratap Maurya ;
pgsql-gene...@postgresql.org
Subject: Re: Huge ar
On Thu, Apr 21, 2022 at 8:15 PM Senor wrote:
>
> Are the autovacuum_vacuum_cost_* settings handled any differently for
> 'to avoid wraparound' vacuums?
> I understand that it won't give up a lock
> but I was expecting it to still back off due to cost and allow the query
> with conflicting lock
On Thu, Apr 21, 2022 at 8:14 PM Senor wrote:
> Are the autovacuum_vacuum_cost_* settings handled any differently for
> 'to avoid wraparound' vacuums? I understand that it won't give up a lock
> but I was expecting it to still back off due to cost and allow the query
> with conflicting lock to proc
Thank you both Laurenz and Peter.
Laurenz - It was an article you posted a couple years ago introducing
the V13 feature that got me thinking about the insert-only situation I had.
Peter - I had been improperly holding anti-wraparound and aggressive in
my mind as related in a way they are not.
Whenever geospatial functions such as St_intersects or recursive query
used, the Postgres/PostGIS appears to spawn away to many child queries and
just obliterate the CPU. Nothing finishes.
That forced me to try out to do the some tasks on the FME server.
I tried to use this http://blog.cleverele
On Thu, Apr 21, 2022 at 08:42:10AM -0500, Alex Aquino
wrote:
> You mentioned testing, and reminds me of another benefit. Way faster, more
> reliable, cheaper to test on the DB side. Testing logic in SPs or SQL is
> much easier, especially when testing requires a sequence of calls for a use
> c
Hello all,
We're stuck at a wrong plan that the planner insists on.(pg 14.2)
It's an aggregation over a single table.
The planner always goes for an extra scan over a partial index.
We have set statistics on the relevant columns to the max of 1 and
could not get correct row estimates. None of t
On 4/19/22 21:31, Ram Pratap Maurya wrote:
Dear Adrian,
We are using binary replication and par day *pg_log_archive* total size
is increase after upgrade for PG11 to PG13.
So what is pruning the WAL's in pg_log_archive?
Or to put it another way what is the purpose of pg_log_archive and how
On 4/21/22 02:13, Thomas, Richard wrote:
Adrian (all),
Thanks for your suggestions. Running the equivalent pg_dump commands at the command line instead of in a script works fine and generates no errors/warnings/McAfee messages in the Windows Event Viewer or on stdout/stderr. (Most days the backu
You mentioned testing, and reminds me of another benefit. Way faster, more
reliable, cheaper to test on the DB side. Testing logic in SPs or SQL is
much easier, especially when testing requires a sequence of calls for a use
case. It is easier because of the DBs support for transactions. With
tr
On Wed, 2022-04-20 at 23:06 +, senor wrote:
> I'm apparently needing an education on how this "to avoid wraparound" vacuum
> differs from
> any other. I've seen it referenced as "more aggressive" but I'd like details.
The difference is twofold, as far as I know:
- it will not skip any pages
> We are occasionally seeing heavy CPU contention with hundreds of processes
> active but waiting on a lightweight lock - usually lock manager or buffer
> mapping it seems. This is happening with VMs configured with about 64 CPUs,
> 350GBs ram, and while we would typically only have 30-100 concu
Adrian (all),
Thanks for your suggestions. Running the equivalent pg_dump commands at the
command line instead of in a script works fine and generates no
errors/warnings/McAfee messages in the Windows Event Viewer or on
stdout/stderr. (Most days the backup script itself completes running multip
13 matches
Mail list logo
