Re: runtime error copying oids field

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Zhihong Yu <zyu(at)yugabyte(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: runtime error copying oids field
Date: 2020-11-30 23:01:39
Message-ID: 20201130230139.GA10581@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-Nov-30, Zhihong Yu wrote:

> This was the line runtime error was raised:
>
> memcpy(part_oids, partdesc->oids, sizeof(Oid) * nparts);
>
> From RelationBuildPartitionDesc we can see that:
>
> if (nparts > 0)
> {
> PartitionBoundInfo boundinfo;
> int *mapping;
> int next_index = 0;
>
> result->oids = (Oid *) palloc0(nparts * sizeof(Oid));
>
> The cause was oids field was not assigned due to nparts being 0.
> This is verified by additional logging added just prior to the memcpy call.
>
> I want to get the community's opinion on whether a null check should be
> added prior to the memcpy() call.

As far as I understand, we do want to avoid memcpy's of null pointers;
see [1].

In this case I think it'd be sane to skip the complete block, not just
the memcpy, something like

diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index ca24620fd0..d35deb433a 100644
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -1163,15 +1163,17 @@ DefineIndex(Oid relationId,

if (partitioned)
{
+ PartitionDesc partdesc;
+
/*
* Unless caller specified to skip this step (via ONLY), process each
* partition to make sure they all contain a corresponding index.
*
* If we're called internally (no stmt->relation), recurse always.
*/
- if (!stmt->relation || stmt->relation->inh)
+ partdesc = RelationGetPartitionDesc(rel);
+ if ((!stmt->relation || stmt->relation->inh) && partdesc->nparts > 0)
{
- PartitionDesc partdesc = RelationGetPartitionDesc(rel);
int nparts = partdesc->nparts;
Oid *part_oids = palloc(sizeof(Oid) * nparts);
bool invalidate_parent = false;

[1] https://www.postgresql.org/message-id/flat/20200904023648.GB3426768%40rfd.leadboat.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-11-30 23:04:34 Re: Printing backtrace of postgres processes
Previous Message Tom Lane 2020-11-30 22:29:51 Re: [BUG] orphaned function