On 7/16/21 1:07 AM, Mark Dilger wrote:
On Jul 15, 2021, at 3:32 PM, Tomas Vondra
wrote:
I think it's mostly futile to list all the possible issues this
might have caused - if you skip arbitrary decoded changes, that can
trigger pretty much any bug in reorder buffer. But those bugs can
be
> On Jul 15, 2021, at 3:32 PM, Tomas Vondra
> wrote:
>
> I think it's mostly futile to list all the possible issues this might have
> caused - if you skip arbitrary decoded changes, that can trigger pretty much
> any bug in reorder buffer. But those bugs can be triggered by various other
>
Hi,
I think it's mostly futile to list all the possible issues this might
have caused - if you skip arbitrary decoded changes, that can trigger
pretty much any bug in reorder buffer. But those bugs can be triggered
by various other issues, of course.
It's hard to say what was the cause, but
> On Jul 15, 2021, at 1:51 PM, Mark Dilger wrote:
>
> one common error I see
Another common error is of the form
ERROR: could not map filenode "base/16384/16413" to relation OID
resulting from a ddl statement having not been written correctly, I think.
This, too, has shown up in
> On Jul 15, 2021, at 1:03 PM, Mark Dilger wrote:
>
> Skipping some writes while not others easily creates a variety of failures,
> and for brevity I won't post a patch to demonstrate that here.
If anybody is curious, one common error I see when simulating a close()
skipping partial changes
Hackers,
I believe there is a hazard in reorderbuffer.c if a call to write() buffers
data rather than flushing it to disk, only to fail when flushing the data
during close(). The relevant code is in ReorderBufferSerializeTXN(), which
iterates over changes for a transaction, opening transient f
