On Fri, Jan 31, 2020 at 12:35 AM Alvaro Herrera
wrote:
>
> On 2019-Jul-26, Andres Freund wrote:
>
> > Petr, Simon, see the potential issue related to fast forward at the
> > bottom.
>
> I think we neglected this bit. I looked at the patch Simon submitted
> downthread, and while I vaguely understa
On 2019-Jul-26, Andres Freund wrote:
> Petr, Simon, see the potential issue related to fast forward at the
> bottom.
I think we neglected this bit. I looked at the patch Simon submitted
downthread, and while I vaguely understand that we need to process
NEW_CID records during fast-forwarding, I d
Hi,
On 2019-09-13 16:42:47 -0300, Alvaro Herrera wrote:
> On 2019-Sep-10, Alvaro Herrera from 2ndQuadrant wrote:
>
> > Here's a couple of patches.
> >
> > always_decode_assignment.patch is Masahiko Sawada's patch, which has
> > been confirmed to fix the assertion failure.
>
> I pushed this one
On 2019-Sep-10, Alvaro Herrera from 2ndQuadrant wrote:
> Here's a couple of patches.
>
> always_decode_assignment.patch is Masahiko Sawada's patch, which has
> been confirmed to fix the assertion failure.
I pushed this one to all branches. Thanks Ildar for reporting and
Sawada-san for fixing, a
Hello,
On 2019-Sep-06, Andres Freund wrote:
> On 2019-08-19 08:51:43 -0700, Andres Freund wrote:
> > On August 19, 2019 7:43:28 AM PDT, Alvaro Herrera
> > wrote:
> > >Never mind. I was able to reproduce it later, and verify that Andres'
> > >proposed strategy doesn't seem to fix the problem.
Hi,
On 2019-08-19 08:51:43 -0700, Andres Freund wrote:
> On August 19, 2019 7:43:28 AM PDT, Alvaro Herrera
> wrote:
> >On 2019-Aug-19, Masahiko Sawada wrote:
> >
> >> On Tue, Aug 13, 2019 at 6:36 AM Alvaro Herrera
> > wrote:
> >
> >> > BTW I wrote the code as suggested and it passes all the test
Hi,
On August 19, 2019 7:43:28 AM PDT, Alvaro Herrera
wrote:
>On 2019-Aug-19, Masahiko Sawada wrote:
>
>> On Tue, Aug 13, 2019 at 6:36 AM Alvaro Herrera
> wrote:
>
>> > BTW I wrote the code as suggested and it passes all the tests ...
>but I
>> > then noticed that the unpatched code doesn't fail
On 2019-Aug-19, Masahiko Sawada wrote:
> On Tue, Aug 13, 2019 at 6:36 AM Alvaro Herrera
> wrote:
> > BTW I wrote the code as suggested and it passes all the tests ... but I
> > then noticed that the unpatched code doesn't fail Ildar's original
> > pgbench-based test for me, either. So maybe my
On Tue, Aug 13, 2019 at 6:36 AM Alvaro Herrera wrote:
>
> On 2019-Aug-07, Andres Freund wrote:
>
> > I think we would need to do this for all values of
> > SnapBuildCurrentState() - after all the problem occurs because we
> > *previously* didn't assign subxids to the toplevel xid. Compared to the
On 2019-Aug-07, Andres Freund wrote:
> I think we would need to do this for all values of
> SnapBuildCurrentState() - after all the problem occurs because we
> *previously* didn't assign subxids to the toplevel xid. Compared to the
> cost of catalog changes, ReorderBufferAssignChild() is really c
Hi,
On 2019-08-07 16:19:13 -0400, Alvaro Herrera wrote:
> On 2019-Jul-26, Andres Freund wrote:
>
> > 2) We could simply assign the subtransaction to the parent using
> >ReorderBufferAssignChild() in SnapBuildProcessNewCid() or it's
> >caller. That ought to also fix the bug
> >
> >I a
On 2019-Jul-26, Andres Freund wrote:
> 2) We could simply assign the subtransaction to the parent using
>ReorderBufferAssignChild() in SnapBuildProcessNewCid() or it's
>caller. That ought to also fix the bug
>
>I also has the advantage that we can save some memory in transactions
>
On Mon, 29 Jul 2019 at 00:09, Petr Jelinek wrote:
> Given that we don't process any other records in this function besides
> XLOG_HEAP2_MULTI_INSERT and XLOG_HEAP2_NEW_CID, it seems like simplest
> fix is to just remove the first check for fast forward and keep the one
> in XLOG_HEAP2_MULTI_INSE
Hi,
On 27. 07. 19 3:15, Andres Freund wrote:
Hi,
Petr, Simon, see the potential issue related to fast forward at the
bottom.
[..snip..]
This actually made me look at the nearby changes due to
commit 9c7d06d60680c7f00d931233873dee81fdb311c6
Author: Simon Riggs
Date: 2018-01-17 11:38:34 +00
Hi,
Petr, Simon, see the potential issue related to fast forward at the
bottom.
On 2019-07-26 18:46:35 -0400, Alvaro Herrera wrote:
> On 2019-Jul-09, Masahiko Sawada wrote:
>
> > I think the cause of this bug would be that a ReorderBufferTXN entry
> > of sub transaction is created as top-level t
On 2019-Jul-09, Masahiko Sawada wrote:
> I think the cause of this bug would be that a ReorderBufferTXN entry
> of sub transaction is created as top-level transaction. And this
> happens because we skip to decode ASSIGNMENT during the state of
> snapshot builder < SNAPBUILD_FULL.
That explanation
On Mon, Jul 8, 2019 at 11:46 PM Masahiko Sawada wrote:
>
> On Mon, Jul 8, 2019 at 9:00 AM Thomas Munro wrote:
> >
> > On Wed, Jun 26, 2019 at 2:46 AM Ildar Musin wrote:
> > > Attached is a simple patch that uses subxid instead of top-level xid
> > > in ReorderBufferAddNewTupleCids() call. It see
On Mon, Jul 8, 2019 at 9:00 AM Thomas Munro wrote:
>
> On Wed, Jun 26, 2019 at 2:46 AM Ildar Musin wrote:
> > Attached is a simple patch that uses subxid instead of top-level xid
> > in ReorderBufferAddNewTupleCids() call. It seems to fix the bug, but
> > i'm not sure that this is a valid change.
On Wed, Jun 26, 2019 at 2:46 AM Ildar Musin wrote:
> Attached is a simple patch that uses subxid instead of top-level xid
> in ReorderBufferAddNewTupleCids() call. It seems to fix the bug, but
> i'm not sure that this is a valid change. Can someone please verify it
> or maybe suggest a better solu
Hi hackers,
I believe we found a bug in logical decoding. It only occures with
casserts enabled. It was originally discovered and reproduced by Murat
Kabilov and Ildus Kurbangaliev. Here is the stacktrace we've got:
#0 0x7facc66ef82f in raise () from /usr/lib/libc.so.6
#1 0x7facc66da672
20 matches
Mail list logo
