On 2014-04-18 11:50:55 -0300, Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund
> > wrote:
> > > It's this (older) assertion in HeapTupleHeaderGetCmax():
> > >
> > >
> > > Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(
On 2014-04-18 11:50:55 -0300, Alvaro Herrera wrote:
> It's a bit painful that HeapTupleHeaderGetUpdateXid allocates memory,
> but to fix that we would have to remove all allocations from
> GetMultiXactIdMembers which doesn't sound feasible.
I was thinking for a second we could just allocate someth
Andres Freund wrote:
> On 2014-04-18 11:50:55 -0300, Alvaro Herrera wrote:
> > It's a bit painful that HeapTupleHeaderGetUpdateXid allocates memory,
> > but to fix that we would have to remove all allocations from
> > GetMultiXactIdMembers which doesn't sound feasible.
>
> I was thinking for a sec
On 2014-04-18 16:44:55 +0200, Robert Haas wrote:
> On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund
> wrote:
> > On 2014-04-17 17:40:01 -0300, Alvaro Herrera wrote:
> >> For once, this looks more like a problem in logical decoding, which is
> >> trying to assert about the tuple being updated; the
Robert Haas wrote:
> On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund
> wrote:
> > On 2014-04-17 17:40:01 -0300, Alvaro Herrera wrote:
> >> For once, this looks more like a problem in logical decoding, which is
> >> trying to assert about the tuple being updated; the assertion failing is
> >> the
On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund wrote:
> On 2014-04-17 17:40:01 -0300, Alvaro Herrera wrote:
>> For once, this looks more like a problem in logical decoding, which is
>> trying to assert about the tuple being updated; the assertion failing is
>> the one added a week ago about not p
On 04/17/2014 04:33 PM, Andres Freund wrote:
Hi,
On 2014-04-17 16:23:54 -0400, Steve Singer wrote:
With master/9.4 from today (52e757420fa98a76015c2c88432db94269f3e8f4)
I am getting an assertion when doing a truncate via SPI when I have
wal_level=logical.
Stack trace is below.
I am just repl
On 2014-04-17 17:40:01 -0300, Alvaro Herrera wrote:
> For once, this looks more like a problem in logical decoding, which is
> trying to assert about the tuple being updated; the assertion failing is
> the one added a week ago about not palloc'ing in a critical section.
It's this (older) assertion
Steve Singer wrote:
> With master/9.4 from today (52e757420fa98a76015c2c88432db94269f3e8f4)
>
> I am getting an assertion when doing a truncate via SPI when I have
> wal_level=logical.
>
> Stack trace is below.
>
> I am just replicating a table with normal slony (2.2) I don't need
> to establish
Hi,
On 2014-04-17 16:23:54 -0400, Steve Singer wrote:
> With master/9.4 from today (52e757420fa98a76015c2c88432db94269f3e8f4)
>
> I am getting an assertion when doing a truncate via SPI when I have
> wal_level=logical.
>
> Stack trace is below.
>
> I am just replicating a table with normal slon
With master/9.4 from today (52e757420fa98a76015c2c88432db94269f3e8f4)
I am getting an assertion when doing a truncate via SPI when I have
wal_level=logical.
Stack trace is below.
I am just replicating a table with normal slony (2.2) I don't need to
establish any replication slots to get this
11 matches
Mail list logo