On Fri, 2022-04-29 at 10:46 +0530, Bharath Rupireddy wrote:
> It's not just the flush ptr, without no wait mode, the functions
> would
> wait if start/input lsn is, say current flush lsn - 1 or 2 or more
> (before the previous record) bytes. If the functions were to wait, by
> how much time should
On Thu, Apr 28, 2022 at 8:41 AM Jeff Davis wrote:
>
> On Thu, 2022-04-28 at 12:11 +1200, Thomas Munro wrote:
> >
> > Another option might be to abandon this whole no-wait concept and
> > revert 2258e76f's changes to xlogutils.c. pg_walinspect already does
> > preliminary checks that LSNs are in r
On Thu, 2022-04-28 at 12:11 +1200, Thomas Munro wrote:
>
> Another option might be to abandon this whole no-wait concept and
> revert 2258e76f's changes to xlogutils.c. pg_walinspect already does
> preliminary checks that LSNs are in range, so you can't enter a value
> that will wait indefinitely
On Wed, Apr 27, 2022 at 10:22 PM Bharath Rupireddy
wrote:
> Here's v2 patch (up on Thomas's v1 at [1]) using private_data to set
> the end of the WAL flag. Please have a look at it.
I don't have a strong view on whether it's better to use a NULL error
for this private communication between pg_wal
On Wed, 2022-04-27 at 13:47 +0530, Bharath Rupireddy wrote:
> I found an easy way to reproduce this consistently (I think on any
> server):
>
> I basically generated huge WAL record (I used a fun extension that I
> wrote - https://github.com/BRupireddy/pg_synthesize_wal, but one can
> use pg_logic
On Wed, Apr 27, 2022 at 1:47 PM Bharath Rupireddy
wrote:
> > >
> > > I've now done several runs with your patch and not seen the test failure.
> > > However, I think we ought to rethink this API a bit rather than just
> > > apply the patch as-is. Even if it were documented, relying on
> > > error
On Wed, Apr 27, 2022 at 8:57 AM Bharath Rupireddy
wrote:
>
> On Wed, Apr 27, 2022 at 8:45 AM Tom Lane wrote:
> >
> > I wrote:
> > > Thomas Munro writes:
> > >> BTW If you had your local change from debug.patch (upthread), that'd
> > >> defeat the patch. I mean this:
> >
> > >> +if(!*err
On Wed, Apr 27, 2022 at 8:45 AM Tom Lane wrote:
>
> I wrote:
> > Thomas Munro writes:
> >> BTW If you had your local change from debug.patch (upthread), that'd
> >> defeat the patch. I mean this:
>
> >> +if(!*errormsg)
> >> + *errormsg = "decode_queue_head is null";
>
> > Oh! O
I wrote:
> Thomas Munro writes:
>> BTW If you had your local change from debug.patch (upthread), that'd
>> defeat the patch. I mean this:
>> +if(!*errormsg)
>> + *errormsg = "decode_queue_head is null";
> Oh! Okay, I'll retry without that.
I've now done several runs with your
Thomas Munro writes:
> BTW If you had your local change from debug.patch (upthread), that'd
> defeat the patch. I mean this:
> +if(!*errormsg)
> + *errormsg = "decode_queue_head is null";
Oh! Okay, I'll retry without that.
regards, tom lane
Thomas Munro writes:
> Ok, that's the same for me. Next question: why does the patch I
> posted not help?
I improved the instrumentation a bit, and it looks like what is
happening is that loc > read_upto, causing that code to "break"
independently of wait_for_wal. success.log is from "make inst
On Wed, Apr 27, 2022 at 1:54 PM Thomas Munro wrote:
> On Wed, Apr 27, 2022 at 1:47 PM Tom Lane wrote:
> > Thomas Munro writes:
> > > Hrmph... Are you sure you rebuilt the contrib module? Assuming so,
> > > maybe it's failing in a different way for you and me. For me, it
> > > always fails af
Thomas Munro writes:
> On Wed, Apr 27, 2022 at 12:25 PM Tom Lane wrote:
>> Not sure what we're doing differently, but plain "make check" in
>> contrib/pg_walinspect fails pretty consistently for me on gcc23.
>> I tried it again just now and got five failures in five attempts.
> I tried on the /h
On Wed, Apr 27, 2022 at 1:47 PM Tom Lane wrote:
> Thomas Munro writes:
> > Hrmph... Are you sure you rebuilt the contrib module? Assuming so,
> > maybe it's failing in a different way for you and me. For me, it
> > always fails after this break is reached in xlogutil.c:
>
> > /* I
Thomas Munro writes:
> Hrmph... Are you sure you rebuilt the contrib module? Assuming so,
> maybe it's failing in a different way for you and me. For me, it
> always fails after this break is reached in xlogutil.c:
> /* If asked, let's not wait for future WAL. */
> if
On Wed, Apr 27, 2022 at 12:25 PM Tom Lane wrote:
> Thomas Munro writes:
> > I think it's a bug in pg_walinspect, so I'll move the discussion back
> > here. Here's one rather simple way to fix it, that has survived
> > running the test a thousand times (using a recipe that failed for me
> > quite
Thomas Munro writes:
> I think it's a bug in pg_walinspect, so I'll move the discussion back
> here. Here's one rather simple way to fix it, that has survived
> running the test a thousand times (using a recipe that failed for me
> quite soon, after 20-100 attempts or so; I never figured out how
On Tue, Apr 26, 2022 at 5:36 PM Michael Paquier wrote:
> On Tue, Apr 26, 2022 at 01:25:14AM -0400, Tom Lane wrote:
> > I've been wondering if the issue could be traced to topminnow's unusual
> > hardware properties, specifically that it has MAXALIGN 8 even though
> > it's only a 32-bit machine per
On Tue, Apr 26, 2022 at 01:25:14AM -0400, Tom Lane wrote:
> I've been wondering if the issue could be traced to topminnow's unusual
> hardware properties, specifically that it has MAXALIGN 8 even though
> it's only a 32-bit machine per sizeof(void *). I think the only
> other active buildfarm anim
Michael Paquier writes:
> Could this be an issue related to the addition of the circular WAL
> decoding buffer, aka 3f1ce97?
I already whined about this at [1].
I've been wondering if the issue could be traced to topminnow's unusual
hardware properties, specifically that it has MAXALIGN 8 even t
Hi Jeff,
On Fri, Apr 08, 2022 at 07:27:44AM +, Jeff Davis wrote:
> Add contrib/pg_walinspect.
>
> Provides similar functionality to pg_waldump, but from a SQL interface
> rather than a separate utility.
The tests of pg_walinspect look unstable:
https://buildfarm.postgresql.org/cgi-bin/show_l
21 matches
Mail list logo
