From: | Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Tidy up GetMultiXactIdMembers()'s behavior on error |
Date: | 2021-06-17 12:57:51 |
Message-ID: | E1ltrah-00011U-ER@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Tidy up GetMultiXactIdMembers()'s behavior on error
One of the error paths left *members uninitialized. That's not a live
bug, because most callers don't look at *members when the function
returns -1, but let's be tidy. One caller, in heap_lock_tuple(), does
"if (members != NULL) pfree(members)", but AFAICS it never passes an
invalid 'multi' value so it should not reach that error case.
The callers are also a bit inconsistent in their expectations.
heap_lock_tuple() pfrees the 'members' array if it's not-NULL, others
pfree() it if "nmembers >= 0", and others if "nmembers > 0". That's
not a live bug either, because the function should never return 0, but
add an Assert for that to make it more clear. I left the callers alone
for now.
I also moved the line where we set *nmembers. It wasn't wrong before,
but I like to do that right next to the 'return' statement, to make it
clear that it's always set on return.
Also remove one unreachable return statement after ereport(ERROR), for
brevity and for consistency with the similar if-block right after it.
Author: Greg Nancarrow with the additional changes by me
Backpatch-through: 9.6, all supported versions
Branch
------
REL_10_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/7ecdc7b675432ac473e64c559e52c53b59b6c159
Modified Files
--------------
src/backend/access/transam/multixact.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2021-06-17 14:41:43 | pgsql: Update plpython_subtransaction alternative expected files |
Previous Message | Amit Kapila | 2021-06-17 11:58:06 | Re: pgsql: Document a few caveats in synchronous logical replication. |