Thanks for the thoughts, Tomas.
I suspected storage only because data was missing. Everything I've looked
at is not showing any indication of this.
Here's the tuple data for each. Appears to look normal to me.
ISSUE table:
PRIMARY:
issuedb=#=# SELECT ctid, xmin, xmax, issue_id as issue_id
On 1/15/25 19:50, Tim Gerber wrote:
> Hi All,
>
>...
>
> Archive mode is on. I ran pg_amcheck and everything came back clean. I
> know synchronous replication is an option, but it feels like something
> else is going on and would like to get to the bottom of it.
>
> Any ideas on what could be ca
Hi All,
We have run into an issue where the data for a primary and standby Postgres
instances are out of sync. We are using streaming physical replication. We
have encountered this issue several times over the last year on different
Postgres Clusters. Postgres indicates everything is in sync but
Il 15/01/25 17:03, Adrian Klaver ha scritto:
On 1/14/25 23:46, Enrico Schenone wrote:
Which environment did you run the recent prolonged test against?
The first one: Distinct application server and DB server on distinct
subnets.
Is that the same as where you saw the errors?
Yes.
*Enric
On 1/14/25 23:46, Enrico Schenone wrote:
Which environment did you run the recent prolonged test against?
The first one: Distinct application server and DB server on distinct
subnets.
Is that the same as where you saw the errors?
*Enrico Schenone*
Software Architect
--
Adrian Klaver
adr
Hello Tom,
The max_connections =200 and max_files_per_process =1000 as you mentioned.
So should a max_files_per_process =500 helps?
I could see from the number of connections to the databaseis not
exceeding 20. But still these 20 are causing all the damage or using up
all the openfiles quot
