From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Steve Singer <steve(at)ssinger(dot)info> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: assertion in 9.4 with wal_level=logical |
Date: | 2014-04-17 20:40:01 |
Message-ID: | 20140417204000.GW5822@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 any replication slots to get this.
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.
Andres told me on IM that there's another weird thing going on (which is
how the catalog tuple gets a multixact in the first place) which is that
Slony does a SELECT FOR SHARE in the catalog tuple.
One simple approach would be to just disable that particular assert when
in a critical section.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2014-04-17 20:44:21 | DISCARD ALL (Again) |
Previous Message | Andres Freund | 2014-04-17 20:39:20 | Re: Clock sweep not caching enough B-Tree leaf pages? |