On 2021-06-14 08:10:58 -0400, Dave Cramer wrote:
> On Sun, 13 Jun 2021 at 19:32, Avi Weinberg wrote:
>
>
> I need to take actions when Postgres streaming replication failover
> occurred. Is there a way to be notified when Postgres slave becomes
> master?
>
> On the surface this seem
Hi again,
thank you for pinpointing the issue.
I have now updated the table with "ALTER TABLE $table SET LOGGED" (actually
it's a partitioned table and I've altered both the main table and the
partitions).
I wanted to double-check the result and what I found out using "select
relpersistenc
Please ignore this email. I could not reproduce it after all.
--
Dr. Manuel Holtgrewe, Dipl.-Inform.
Bioinformatician
Core Unit Bioinformatics – CUBI
Berlin Institute of Health / Max Delbrück Center for Molecular Medicine in the
Helmholtz Association / Charité – Universitätsmedizin Berlin
Visit
Yeah it is latest.
I am using Postgres 9.6.
Thanks!
Sudhakaran
On Tue, 15 Jun 2021 at 10:42 PM, Mateusz Henicz
wrote:
> Do you have "recovery_target_timeline=latest" configured in your
> recovery.conf or postgresql.conf? Depending on the version you are using,
> up to 11 recovery.conf and pos
On Wed, 16 Jun 2021 at 18:29, Atul Kumar wrote:
> QUERY PLAN
> Limit (cost=0.43..5529.03 rows=10 width=37) (actual
> time=0.974..12911.087 rows=10 loops=1)
> Output: items._id
> Buffers: shared hit=4838 read=3701
> -> Subquery Scan on items (cost=0.43..1622646.30 rows=2935
> width=37) (ac
On 2021-06-16 14:39:19 +0800, Julien Rouhaud wrote:
> On Wed, Jun 16, 2021 at 12:02:52PM +0530, Atul Kumar wrote:
> > Sometimes I run a Postgres query it takes 30 seconds. Then, I
> > immediately run the same query and it takes 2 seconds.
[...]
> > Can I force all caches to be cleared for tuning pu
In a heavily used production database prod, running a `psql prod` takes
seconds. Once the connection is established, performance of queries is
fine. There are ~2 new usually short-lived connections / second, and a
couple of long-running analytical queries. Connecting to other databases on
the same
Marcin Barczynski writes:
> It's always /opt/prod/pg/9.6/base/18370/1108887031. Unfortunately, no trace
> of it in pg_class:
It's probably a mapped system catalog, which will have relfilenode = 0.
Try
SELECT relname FROM pg_class WHERE pg_relation_filenode(oid) = 1108887031;
My guess is that wh
Thanks for the immediate reply.
It turned out to be pg_attribute. It was bloated probably due to the large
number of temp tables created.
Are there any recommendations on how to prevent such a bloat from happening?
On Wed, Jun 16, 2021 at 4:10 PM Tom Lane wrote:
> Marcin Barczynski writes:
> >
Marcin Barczynski writes:
> It turned out to be pg_attribute. It was bloated probably due to the large
> number of temp tables created.
> Are there any recommendations on how to prevent such a bloat from happening?
You could perhaps apply more aggressive autovacuum settings to that
catalog. That
Are there performance issues with the choice of 'text' vs. varchar and some
character limit? For instance, if I have a table with ten million records and
text fields that may range in length from 15 to 150, can I expect a measurable
improvement in response time for using varchar(150) or will t
Martin Mueller writes:
> Are there performance issues with the choice of 'text' vs. varchar and some
> character limit? For instance, if I have a table with ten million records
> and text fields that may range in length from 15 to 150, can I expect a
> measurable improvement in response time f
Hi,
I had a cascade serverA->serverB->serverC->serverD of Postgres 10.14
servers connected with streaming replication.
There was no archive shipping set up, but there was an empty directory
/data/pg_archive/10/dedupe_shard1_10/ mentioned in config for it on each
of the servers.
When I promot
What is your recovery_target_timeline set to on replicas ?
I just did a primary -> replica -> cascading replica setup. and then
promoted replica as new primary.
cascading replica was working fine, no restarts required.
for me recovery_target_timeline was set to 'latest'
i have pg14beta installed
I had it "latest" as well.
I'll try to reproduce it again tomorrow.
On 16/06/2021 17:20, Vijaykumar Jain wrote:
What is your recovery_target_timeline set to on replicas ?
I just did a primary -> replica -> cascading replica setup. and then
promoted replica as new primary.
cascading replica was
15 matches
Mail list logo
