is particular customer which take more
than 20 seconds. The content of the document in those cases are similar to:
User Name Kees postgresstreet Amsterdam 1000 AA user.n...@gmail.com 1234
Are we doing something wrong? I find the I/O timings quite high, does this
mean that it took 4000MS to read the 9752 blocks from the disk?
Any other tips and or suggestions are welcome.
Kind regards,
Lars Vonk
).
As a last question, do you know if this is also the case with logical
replication as well, or is what happened here an "expected outcome" when a
logical replica misses a WAL?
Lars
On Thu, Dec 24, 2020 at 5:52 PM Adrian Klaver
wrote:
> On 12/23/20 1:40 AM, Lars Vonk wrote:
> >
M Adrian Klaver
wrote:
> On 12/22/20 9:10 AM, Lars Vonk wrote:
> > Did you have some other replication running on the 11 instance?
> >
> >
> > Yes the 11 instance also had another (11) replica running. (But these
> > logs are from the 12 instance)
>
> Th
onfiguration parameter "max_wal_size".
2020-12-10 13:26:43 UTC::@:[5537]:LOG: checkpoint starting: wal
Lars
On Mon, Dec 21, 2020 at 11:51 PM Adrian Klaver
wrote:
> On 12/21/20 2:42 PM, Lars Vonk wrote:
> > What was being run when the above ERROR was triggered?
> >
e are more ERROR's on different WAL
segments missing. Each missing wal segment is logged as ERROR a couple of
times and then no more. After a couple of hours no errors are logged.
Lars
On Mon, Dec 21, 2020 at 10:23 PM Adrian Klaver
wrote:
> On 12/21/20 12:26 PM, Lars Vonk wrote:
>
logical replication (like hotstandy)
that when a WAL file is missing that it stops with further replication
Regards,
Lars
On Sun, Dec 20, 2020 at 6:58 PM Adrian Klaver
wrote:
> On 12/20/20 8:33 AM, Lars Vonk wrote:
> > Hi,
> >
> > Just wondering if someone knows how this coul
ny help or tips are appreciated.
Thanks in advance,
Lars
On Fri, Dec 18, 2020 at 4:42 PM Lars Vonk wrote:
> Hi,
>
> We migrated from postgres 11 to 12 using logical replication (over local
> network). Today we noticed that one table is missing 1252 rows after the
> replication fini
at 11:38:09AM +0100, Lars Vonk wrote:
> > Hi,
> >
> > Yesterday I tried (twice) to report an issue / ask a question on Postgres
> > logical replication on this user group, but both emails didn't appear in
> > this mailing list.
>
> https://www.postgresql.org
Hi,
Yesterday I tried (twice) to report an issue / ask a question on Postgres
logical replication on this user group, but both emails didn't appear in
this mailing list.
What could be the cause of that?
Thanks in advance,
Lars
Hi,
We migrated from postgres 11 to 12 using logical replication (over local
network). Today we noticed that one table is missing 1252 rows after the
replication finished and we flipped to the new primary (we still have the
old master database so we can recover).
We see that these rows were inser
Hi,
We migrated from postgres 11 to 12 using logical replication. Today we
noticed that one table is missing 1252 rows after the replication finished
and we flipped to the new primary (we still have the old so we can recover).
We see that these rows were inserted in the table after starting the
i
-- Lars
On Thu, Dec 10, 2020 at 9:12 AM Lars Vonk wrote:
> Hi,
>
> - on the receiving side, avoid creating indexes on the tables: create just
>> a necessary PK or UK, wait for the initial load to complete and then add
>> all the rest ones
>>
>
> Thanks, this is a
mizing load on the queue during initial
replication.
On to the next try.
Lars
On Wed, Dec 9, 2020 at 6:45 PM Victor Yegorov wrote:
> ср, 9 дек. 2020 г. в 10:21, Lars Vonk :
>
>> We are doing a logical postgres replication from Postgres 11 to 12. Our
>> database is around 700GB (8
Hi,
We are doing a logical postgres replication from Postgres 11 to 12. Our
database is around 700GB (8 cpu's, 32 GB).
During the replication process, at some point, we see a huge performance
penalty on a particular table. This table acts as a queue with lots of
inserts and deletes happening throu
14 matches
Mail list logo
