Re: crash with sql language partition support function

Hi, On 2018-04-13 15:08:30 -0300, Alvaro Herrera wrote: > I think this is a good improvement. On top of that, I propose a new > file partitioning/partdefs.h with the following approximate contents. > This reduces cross-inclusion of headers to the minimum. I'm dealing > with the fallout from

Re: crash with sql language partition support function

I think this is a good improvement. On top of that, I propose a new file partitioning/partdefs.h with the following approximate contents. This reduces cross-inclusion of headers to the minimum. I'm dealing with the fallout from this now, will post a complete patch shortly.

Re: crash with sql language partition support function

Amit Langote wrote: > On 2018/04/13 6:58, Alvaro Herrera wrote: > > After going over your patch, I think you went slightly overboard here. > > Or maybe not, but this patch is so large that it's hard to form an > > opinion about it. > > It's mostly code movement, but there are some other changes

Re: crash with sql language partition support function

On 2018/04/13 3:10, Alvaro Herrera wrote: > Alvaro Herrera wrote: > >> I'm dealing with this now -- will push shortly. The sane thing to do is >> backpatch my previous memcxt fixes, since your patch introduces a >> problem that we discussed with that other patch, namely that you would >> leak

Re: crash with sql language partition support function

I wonder what prompted people to #include "catalog/partition.h" in executor.h. Amit Langote wrote: > Anyway, after reading your replies, I thought of taking a stab at unifying > the partitioning information that's cached by relcache.c. After going over your patch, I think you went slightly

Re: crash with sql language partition support function

Robert Haas wrote: > On Thu, Apr 12, 2018 at 8:55 AM, Alvaro Herrera > wrote: > > Amit Langote wrote: > >> Anyway, after reading your replies, I thought of taking a stab at unifying > >> the partitioning information that's cached by relcache.c. > > > > Wow. Now that's

Re: crash with sql language partition support function

Alvaro Herrera wrote: > I'm dealing with this now -- will push shortly. The sane thing to do is > backpatch my previous memcxt fixes, since your patch introduces a > problem that we discussed with that other patch, namely that you would > leak the whole memory context if there is a problem while

Re: crash with sql language partition support function

On Thu, Apr 12, 2018 at 8:55 AM, Alvaro Herrera wrote: > Amit Langote wrote: >> Anyway, after reading your replies, I thought of taking a stab at unifying >> the partitioning information that's cached by relcache.c. > > Wow. Now that's one large patch. I'm going to run

Re: crash with sql language partition support function

Amit Langote wrote: > Since this bug also exists in the released PG 10 branch, I also created a > patch for that. It's slightly different than the one for PG 11dev, > because there were some changes recently to how the memory context is > manipulated in RelationBuildPartitionKey. That's >

Re: crash with sql language partition support function

Amit Langote wrote: > Anyway, after reading your replies, I thought of taking a stab at unifying > the partitioning information that's cached by relcache.c. Wow. Now that's one large patch. I'm going to run with this for HEAD, but I think we should do a minimal fix for PG10. Did you detect

Re: crash with sql language partition support function

Alvaro Herrera writes: > Ashutosh Bapat wrote: >> On Tue, Apr 10, 2018 at 1:44 PM, Amit Langote >> wrote: >>> Attached fixes it. It teaches RelationBuildPartitionKey() to use >>> fmgr_info_cxt and pass rd_partkeycxt to it. >> The patch is

Re: crash with sql language partition support function

Ashutosh Bapat wrote: > On Tue, Apr 10, 2018 at 1:44 PM, Amit Langote > wrote: > > > > Attached fixes it. It teaches RelationBuildPartitionKey() to use > > fmgr_info_cxt and pass rd_partkeycxt to it. > > The patch is using partkeycxt and not rd_partkeycxt.

Re: crash with sql language partition support function

On Tue, Apr 10, 2018 at 1:44 PM, Amit Langote wrote: > > Attached fixes it. It teaches RelationBuildPartitionKey() to use > fmgr_info_cxt and pass rd_partkeycxt to it. The patch is using partkeycxt and not rd_partkeycxt. Probably a typo in the mail. But a wider

Re: crash with sql language partition support function

I have added this in the Older Bugs section of open items page. https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items#Older_Bugs Thanks, Amit

crash with sql language partition support function

Hi. I noticed that RelationBuildPartitionKey() is not doing the right thing with respect to which context it passes to fmgr.c to set a the (cached) partition support function's FmgrInfo's fn_mcxt. I noticed a crash while trying to change partition pruning tests to use manually created hash