fix side-effect in get_qual_for_list()

Started by Jeevan Ladhealmost 9 years ago6 messageshackers
Jump to latest
#1Jeevan Ladhe
jeevan.ladhe@enterprisedb.com

Hi,

While working on one of the crash reported on default partition for list
partitioning table[1]*/messages/by-id/CAOgcT0PLPge=5U6=GU5SnC3_8yutCbWWOiUva3Cw94M9zpbvgQ@mail.gmail.com </messages/by-id/CAOgcT0PLPge=5U6=GU5SnC3_8yutCbWWOiUva3Cw94M9zpbvgQ@mail.gmail.com&gt;* I found some strange behavior in get_qual_for_list()
while
I tried to call it from the new code I wrote for default partition.

After debugging, I noticed that the function get_qual_for_list() is
implicitly
manipulating the (PartitionBoundSpec) spec->listdatums list. AFAICU, this
manipulation is needed just to construct a list of datums to be passed to
ArrayExpr, and this should be done without manipulating the original list.
The function name is get_qual_for_list(), which implies that this function
returns something and does not modify anything.

I have made this change in attached patch, as I think this is useful for
future
developments, as there may be a need in future to call get_qual_for_list()
from
other places, and the caller might not expect that PartitionBoundSpec gets
modified.

PFA.

[1]: */messages/by-id/CAOgcT0PLPge=5U6=GU5SnC3_8yutCbWWOiUva3Cw94M9zpbvgQ@mail.gmail.com </messages/by-id/CAOgcT0PLPge=5U6=GU5SnC3_8yutCbWWOiUva3Cw94M9zpbvgQ@mail.gmail.com&gt;*
</messages/by-id/CAOgcT0PLPge=5U6=GU5SnC3_8yutCbWWOiUva3Cw94M9zpbvgQ@mail.gmail.com&gt;*

Regards,
Jeevan Ladhe

Attachments:

fix_listdatums_get_qual_for_list.patchapplication/octet-stream; name=fix_listdatums_get_qual_for_list.patchDownload+6-14
#2Ashutosh Bapat
ashutosh.bapat@enterprisedb.com
In reply to: Jeevan Ladhe (#1)
Re: fix side-effect in get_qual_for_list()

On Thu, May 25, 2017 at 3:12 PM, Jeevan Ladhe
<jeevan.ladhe@enterprisedb.com> wrote:

Hi,

While working on one of the crash reported on default partition for list
partitioning table[1] I found some strange behavior in get_qual_for_list()
while
I tried to call it from the new code I wrote for default partition.

After debugging, I noticed that the function get_qual_for_list() is
implicitly
manipulating the (PartitionBoundSpec) spec->listdatums list. AFAICU, this
manipulation is needed just to construct a list of datums to be passed to
ArrayExpr, and this should be done without manipulating the original list.
The function name is get_qual_for_list(), which implies that this function
returns something and does not modify anything.

I have made this change in attached patch, as I think this is useful for
future
developments, as there may be a need in future to call get_qual_for_list()
from
other places, and the caller might not expect that PartitionBoundSpec gets
modified.

Thanks for catching this. For now this isn't a problem since
generate_partition_qual() is crafting PartitionBoundInfo which it
doesn't use anywhere else. But if the function gets used where the
PartitionBoundSpec is being used somewhere else as well. While you are
at it, can we use castNode() in place of
PartitionBoundSpec *spec = (PartitionBoundSpec *) bound; Or do you
think it should be done separately?

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Jeevan Ladhe
jeevan.ladhe@enterprisedb.com
In reply to: Ashutosh Bapat (#2)
Re: fix side-effect in get_qual_for_list()

Hi Ashutosh,

Thanks for catching this. For now this isn't a problem since

generate_partition_qual() is crafting PartitionBoundInfo which it
doesn't use anywhere else. But if the function gets used where the
PartitionBoundSpec is being used somewhere else as well.

Yes, this behavior currently does not affect adversely, but I think this
function is quite useful for future enhancements and should be fixed.

While you are

at it, can we use castNode() in place of
PartitionBoundSpec *spec = (PartitionBoundSpec *) bound; Or do you
think it should be done separately?

I have made this change at couple of places applicable.

PFA.

Regards,
Jeevan Ladhe

Attachments:

fix_listdatums_get_qual_for_list_v2.patchapplication/octet-stream; name=fix_listdatums_get_qual_for_list_v2.patchDownload+8-16
#4Jeevan Ladhe
jeevan.ladhe@enterprisedb.com
In reply to: Jeevan Ladhe (#3)
Re: fix side-effect in get_qual_for_list()

Hi,

I have rebased the patch on recent commit.

With recent commits, some of the hunks in the v2 patch related to
castNode, are not needed.

PFA.

Regards,
Jeevan Ladhe

On Sat, May 27, 2017 at 1:16 AM, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com

Show quoted text

wrote:

Hi Ashutosh,

Thanks for catching this. For now this isn't a problem since

generate_partition_qual() is crafting PartitionBoundInfo which it
doesn't use anywhere else. But if the function gets used where the
PartitionBoundSpec is being used somewhere else as well.

Yes, this behavior currently does not affect adversely, but I think this
function is quite useful for future enhancements and should be fixed.

While you are

at it, can we use castNode() in place of
PartitionBoundSpec *spec = (PartitionBoundSpec *) bound; Or do you
think it should be done separately?

I have made this change at couple of places applicable.

PFA.

Regards,
Jeevan Ladhe

Attachments:

fix_listdatums_get_qual_for_list_v3.patchapplication/octet-stream; name=fix_listdatums_get_qual_for_list_v3.patchDownload+6-14
#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jeevan Ladhe (#4)
Re: fix side-effect in get_qual_for_list()

Jeevan Ladhe <jeevan.ladhe@enterprisedb.com> writes:

I have rebased the patch on recent commit.

Pushed with some further tweaking.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#6Jeevan Ladhe
jeevan.ladhe@enterprisedb.com
In reply to: Tom Lane (#5)
Re: fix side-effect in get_qual_for_list()

On Mon, May 29, 2017 at 11:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Jeevan Ladhe <jeevan.ladhe@enterprisedb.com> writes:

I have rebased the patch on recent commit.

Pushed with some further tweaking.

Thanks Tom for taking care of this.

Regards,
Jeevan Ladhe