Re: [HACKERS] assertion in 9.4 with wal_level=logical
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 and...@2ndquadrant.com wrote: It's this (older) assertion in HeapTupleHeaderGetCmax(): Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(tup))); That can allocate memory if xmax is a multixact... Does anybody have a better idea to solve this than adding a CritSectionCount == 0 in there? Blech. Isn't that just nerfing the assertion? Well, that's exactly the point. Most of the time, HeapTupleHeaderGetCmax gets called in a non-critical section, and we want to run the assertion in that case. But it's not huge trouble if the assertion is not run in the rare case where HeapTupleHeaderGetCmax is being used to write a Xlog record. 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. Since nobody seemed to have a better idea I've proceeded in doing so... Not pretty. I've verified that the assertion could be triggered before, but not after by doing something like: S1: CREATE TABLE a(); BEGIN; SELECT * FROM pg_class WHERE relname = 'a' FOR SHARE; S2: BEGIN; SELECT * FROM pg_class WHERE relname = 'a' FOR SHARE; COMMIT; S1: ALTER TABLE a RENAME to b; ALTER TABLE b RENAME to a; -- this triggered the assertion That seems a tad too obscure for its own isolationtester test. Thanks for the report, Steve! Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] assertion in 9.4 with wal_level=logical
On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund and...@2ndquadrant.com 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 palloc'ing in a critical section. It's this (older) assertion in HeapTupleHeaderGetCmax(): Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(tup))); That can allocate memory if xmax is a multixact... Does anybody have a better idea to solve this than adding a CritSectionCount == 0 in there? Blech. Isn't that just nerfing the assertion? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] assertion in 9.4 with wal_level=logical
Robert Haas wrote: On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund and...@2ndquadrant.com 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 palloc'ing in a critical section. It's this (older) assertion in HeapTupleHeaderGetCmax(): Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(tup))); That can allocate memory if xmax is a multixact... Does anybody have a better idea to solve this than adding a CritSectionCount == 0 in there? Blech. Isn't that just nerfing the assertion? Well, that's exactly the point. Most of the time, HeapTupleHeaderGetCmax gets called in a non-critical section, and we want to run the assertion in that case. But it's not huge trouble if the assertion is not run in the rare case where HeapTupleHeaderGetCmax is being used to write a Xlog record. 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. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] assertion in 9.4 with wal_level=logical
On 2014-04-18 16:44:55 +0200, Robert Haas wrote: On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund and...@2ndquadrant.com 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 palloc'ing in a critical section. It's this (older) assertion in HeapTupleHeaderGetCmax(): Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(tup))); That can allocate memory if xmax is a multixact... Does anybody have a better idea to solve this than adding a CritSectionCount == 0 in there? Blech. Isn't that just nerfing the assertion? Not precicisely sure what you mean, but the only memory allocation in HeapTupleHeaderGetCmax() and log_heap_new_cid() is that Assert(). And that's the only forbidden thing in that codepath. Now, we could alternatively restructure the codepaths so they pass in xmax from outside the critical section, but I had a quick look and the risk/complications from that seems bigger than the assertion buys us there. I don't have a better idea unfortunately :( Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] assertion in 9.4 with wal_level=logical
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 second we could just allocate something during startup based on max_connections (+ other possible backends), but I think that won't work because of subtransactions? Yeah, I don't think the number of members in a multixact is bound. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] assertion in 9.4 with wal_level=logical
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 something during startup based on max_connections (+ other possible backends), but I think that won't work because of subtransactions? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] assertion in 9.4 with wal_level=logical
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 slony (2.2) I don't need to establish any replication slots to get this. Uh, that's somewhat nasty... You probably only get that because of slony's habit of share locking catalogs. Could that be? For now, to circumvent the problem you could just revert 4a170ee9e0ebd7021cb1190fabd5b0cbe2effb8e for now. I'll look into fixing it properly. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] assertion in 9.4 with wal_level=logical
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 Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] assertion in 9.4 with wal_level=logical
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 in HeapTupleHeaderGetCmax(): Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(tup))); That can allocate memory if xmax is a multixact... Does anybody have a better idea to solve this than adding a CritSectionCount == 0 in there? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] assertion in 9.4 with wal_level=logical
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 replicating a table with normal slony (2.2) I don't need to establish any replication slots to get this. Uh, that's somewhat nasty... You probably only get that because of slony's habit of share locking catalogs. Could that be? Yes slony does a select from pg_catalog and pg_namespace in the stored function just before doing the truncate. For now, to circumvent the problem you could just revert 4a170ee9e0ebd7021cb1190fabd5b0cbe2effb8e for now. I'll look into fixing it properly. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers