On Tue, Aug 10, 2021 at 8:15 PM Ha Ka wrote:
>
> sob., 19 cze 2021 o 12:14 Amit Kapila napisał(a):
>
> We increased logical_decoding_work_mem for our production database
> from 64 to 192 MB and it looks like the issue still persists. The
> frequency with which replication hangs has remained the
sob., 19 cze 2021 o 12:14 Amit Kapila napisał(a):
>
> On Fri, Jun 18, 2021 at 11:22 AM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 17 Jun 2021 12:56:42 -0400, Alvaro Herrera
> > wrote in
> > > On 2021-Jun-17, Kyotaro Horiguchi wrote:
> > >
> > > > I don't see a call to hash_*seq*_search there.
On Fri, Jun 18, 2021 at 11:22 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 17 Jun 2021 12:56:42 -0400, Alvaro Herrera
> wrote in
> > On 2021-Jun-17, Kyotaro Horiguchi wrote:
> >
> > > I don't see a call to hash_*seq*_search there. Instead, I see one in
> > > ReorderBufferCheckMemoryLimit().
> >
> >
At Thu, 17 Jun 2021 12:56:42 -0400, Alvaro Herrera
wrote in
> On 2021-Jun-17, Kyotaro Horiguchi wrote:
>
> > I don't see a call to hash_*seq*_search there. Instead, I see one in
> > ReorderBufferCheckMemoryLimit().
>
> Doh, of course -- I misread.
>
> ReorderBufferCheckMemoryLimit is new in
On 2021-Jun-17, Kyotaro Horiguchi wrote:
> I don't see a call to hash_*seq*_search there. Instead, I see one in
> ReorderBufferCheckMemoryLimit().
Doh, of course -- I misread.
ReorderBufferCheckMemoryLimit is new in pg13 (cec2edfa7859) so now at
least we have a reason why this workload
On Thu, Jun 17, 2021 at 7:28 AM Kyotaro Horiguchi
wrote:
>
> At Wed, 16 Jun 2021 18:28:28 -0400, Alvaro Herrera
> wrote in
> > On 2021-Jun-16, Ha Ka wrote:
> > # Children Self Command Shared Object Symbol
> > # .
> >
At Wed, 16 Jun 2021 18:28:28 -0400, Alvaro Herrera
wrote in
> On 2021-Jun-16, Ha Ka wrote:
> # Children Self Command Shared Object Symbol
>
> # .
> ..
> #
>100.00% 0.00%
On 2021-Jun-16, Ha Ka wrote:
> Here is the upload with generated reports: https://easyupload.io/p38izx
> passwd: johS5jeewo
OK, so I downloaded that and this is the interesting entry in the
profile for the broken case:
# Samples: 5K of event 'cpu-clock'
# Event count (approx.): 59989898390
#
#
> Hello, thanks, I downloaded the files but since you sent the perf.data
> files there's not much I can do to usefully interpret them. Can you
> please do "perf report -g > perf_report.txt" on each subdir with a
> perf.data file and upload those text files? (You don't need to rerun
> the test
On 2021-Jun-16, Ha Ka wrote:
> śr., 16 cze 2021 o 12:31 Lukasz Biegaj
> napisał(a):
> > On 04.05.2021 16:35, Alvaro Herrera wrote:
> > > I would suggest to do that by running the problematic
> > > workload in the test system under "perf record -g"
> > We'll go with both propositions. I expect to
śr., 16 cze 2021 o 12:31 Lukasz Biegaj
napisał(a):
> On 04.05.2021 16:35, Alvaro Herrera wrote:
> > I would suggest to do that by running the problematic
> > workload in the test system under "perf record -g"
> We'll go with both propositions. I expect to come back to you with
> results in about
On 04.05.2021 16:35, Alvaro Herrera wrote:
I would suggest to do that by running the problematic
workload in the test system under "perf record -g"
> [..]
> you could ensure that in pg10 the same workload
> does not cause the problem.
We'll go with both propositions. I expect to come back to
Hi Lukasz, thanks for following up.
On 2021-May-04, Lukasz Biegaj wrote:
> The problem is as described in
> https://www.postgresql.org/message-id/flat/8bf8785c-f47d-245c-b6af-80dc1eed40db%40unitygroup.com
>
> It does occur on two separate production clusters and one test cluster - all
>
Hey, thanks for reaching out and sorry for the late reply - we had few
days of national holidays.
On 29.04.2021 15:55, Alvaro Herrera wrote:
https://www.postgresql.org/message-id/flat/CANDwggKYveEtXjXjqHA6RL3AKSHMsQyfRY6bK%2BNqhAWJyw8psQ%40mail.gmail.com
Cc'ing Lukasz Biegaj because of the pgsql-general thread.
On 2021-Apr-29, Amit Kapila wrote:
> On Wed, Apr 28, 2021 at 7:36 PM Alvaro Herrera
> wrote:
> > ... It's strange that replication worked for them on pg10 though and
> > broke on 13. What did we change anything to make it so?
>
> No
On Wed, Apr 28, 2021 at 7:36 PM Alvaro Herrera wrote:
>
> On 2021-Apr-28, Amit Kapila wrote:
>
> > On Wed, Apr 28, 2021 at 6:48 AM Alvaro Herrera
> > wrote:
>
> > > Hmm ... On what does it depend (other than plain git conflicts, which
> > > are aplenty)? On a quick look to the commit, it's
On 2021-Apr-28, Amit Kapila wrote:
> On Wed, Apr 28, 2021 at 6:48 AM Alvaro Herrera
> wrote:
> > Hmm ... On what does it depend (other than plain git conflicts, which
> > are aplenty)? On a quick look to the commit, it's clear that we need to
> > be careful in order not to cause an ABI break,
On Wed, Apr 28, 2021 at 6:48 AM Alvaro Herrera wrote:
>
> On 2021-Apr-14, Amit Kapila wrote:
>
> > On Tue, Apr 13, 2021 at 1:18 PM Krzysztof Kois
> > wrote:
> > >
> > > Hello,
> > > After upgrading the cluster from 10.x to 13.1 we've started getting a
> > > problem describe pgsql-general:
> > >
On 2021-Apr-14, Amit Kapila wrote:
> On Tue, Apr 13, 2021 at 1:18 PM Krzysztof Kois
> wrote:
> >
> > Hello,
> > After upgrading the cluster from 10.x to 13.1 we've started getting a
> > problem describe pgsql-general:
> >
On Tue, Apr 13, 2021 at 1:18 PM Krzysztof Kois
wrote:
>
> Hello,
> After upgrading the cluster from 10.x to 13.1 we've started getting a problem
> describe pgsql-general:
> https://www.postgresql.org/message-id/8bf8785c-f47d-245c-b6af-80dc1eed40db%40unitygroup.com
> We've noticed similar issue
Hello,
After upgrading the cluster from 10.x to 13.1 we've started getting a problem
describe pgsql-general:
https://www.postgresql.org/message-id/8bf8785c-f47d-245c-b6af-80dc1eed40db%40unitygroup.com
We've noticed similar issue being described on this list in
21 matches
Mail list logo
