From: | Jeremy Finzel <finzelj(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Postgres-BDR and pglogical Mailing List <bdr-list(at)2ndquadrant(dot)com> |
Subject: | Re: No such file or directory in pg_replslot |
Date: | 2018-12-09 00:34:49 |
Message-ID: | CAMa1XUjmXmzvxQFyaXRSjUeu44qA9o1K+O=1s1FWnGjmafi9bQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Dec 8, 2018 at 1:21 PM Jeremy Finzel <finzelj(at)gmail(dot)com> wrote:
> That doesn't indicate an error. You need to provide more details what
>> made you consider things wedged...
>>
>> Andres
>>
>
> Thank you very much for the reply. We typically see no visible
> replication delay over 5 minutes ever. Today we saw a delay of over 3
> hours, and no obvious increase in workload either on the provider or the
> subscriber. I also did not see the LSN advancing whatsoever in terms of
> applying changes.
>
> I first checked for long-running transactions on the master but there was
> nothing too unusual except an ANALYZE which I promptly killed, but with no
> improvement to the situation.
>
> I found the messages above using strace after canceling the subscription
> and finding that the process was taking extremely long to cancel. There
> are 2.1 million files in pg_replslot which I don't think is normal? Any
> ideas as to where I should be looking or what could cause this?
>
> Thanks,
> Jeremy
>
I have very good news in that waiting it out for several hours, it resolved
itself. Thank you, your input steered us in the right direction!
Jeremy
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2018-12-09 00:54:14 | min_parallel_table_size and inheritence |
Previous Message | Noah Misch | 2018-12-09 00:16:01 | Too-short timeouts in test code |