Re: margay fails assertion in stats/dsa/dsm code
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Marcel Hofstetter <hofstetter@jomasoft.ch>
Date: 2022-06-30T16:02:21Z
Lists: pgsql-hackers
On Wed, Jun 29, 2022 at 12:01 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> As for whether PostgreSQL needs to do anything, perhaps we should
> ereport for this unexpected error as a matter of self-preservation, to
> avoid the NULL dereference you'd presumably get on a non-cassert build
> with the current coding? Maybe just:
>
> - if (errno != EEXIST)
> + if (op == DSM_OP_ATTACH || errno != EEXIST)
> ereport(elevel,
> (errcode_for_dynamic_shared_memory(),
> errmsg("could not open shared
> memory segment \"%s\": %m",
>
> margay would probably still fail until that underlying problem is
> addressed, but less mysteriously on our side at least.
That seems like a correct fix, but maybe we should also be checking
the return value of dsm_impl_op() e.g. define dsm_impl_op_error() as
an inline function that does if (!dsm_impl_op(..., ERROR)) elog(ERROR,
"the author of dsm.c is not as clever as he thinks he is").
--
Robert Haas
EDB: http://www.enterprisedb.com
Commits
-
Fix lock assertions in dshash.c.
- eed959a457ea 16.0 landed
- 53df1e28d2f7 15.0 landed
- cd26139a3056 11.17 landed
- 4f88dbac22a8 12.12 landed
- 7cdd0c2d7cdf 13.8 landed
- 5e7608e81ebb 14.5 landed
-
Default to dynamic_shared_memory_type=sysv on Solaris.
- 94ebf8117c93 16.0 landed
- a2b0719cc22d 15.0 landed
-
Harden dsm_impl.c against unexpected EEXIST.
- 389869af59da 16.0 landed
- b436047dc692 13.8 landed
- f7b69b1e31ee 12.12 landed
- facfd04678ec 11.17 landed
- 22b9afaf5cc0 10.22 landed
- fb81a93a6442 14.5 landed
- fef8c7a0c577 15.0 landed