Обсуждение: error I don't understand
could not open shared memory segment "/PostgreSQL.3631378696": No such file or directory Context is in parallel workers. Does this just mean that I don't have enough shmem allocated for the PG config that I setup? -- Scott Ribe scott_ribe@elevated-dev.com https://www.linkedin.com/in/scottribe/
Scott Ribe <scott_ribe@elevated-dev.com> writes:
> could not open shared memory segment "/PostgreSQL.3631378696": No such file or directory
That looks like cascading failure from some earlier problem. Is there
really no other nearby complaint in your log?
regards, tom lane
2022年7月28日(木) 0:35 Scott Ribe <scott_ribe@elevated-dev.com>: > > could not open shared memory segment "/PostgreSQL.3631378696": No such file or directory > > Context is in parallel workers. Does this just mean that I don't have enough shmem allocated for the PG config that I setup? If you are using a Systemd-enabled Linux, check that "RemoveIPC" is set to "no". See: https://wiki.postgresql.org/wiki/Systemd Regards Ian Barwick > -- > Scott Ribe > scott_ribe@elevated-dev.com > https://www.linkedin.com/in/scottribe/ > > > > >
> On Jul 27, 2022, at 11:30 AM, Ian Lawrence Barwick <barwick@gmail.com> wrote: > > If you are using a Systemd-enabled Linux, check that "RemoveIPC" is > set to "no". That was the answer. I checked other servers, they had it set. But they are much older OSs (overdue for updates, RSN), differentinstallers. I have step-by-step notes documenting their installs, no mention of RemoveIPC. So sometime ~6 years ago I ran installersthat set that to "no". Then we come to today, Ubuntu 22, and I needed to set it, or use a system user. Thanks!
Scott Ribe <scott_ribe@elevated-dev.com> writes:
> On Jul 27, 2022, at 11:30 AM, Ian Lawrence Barwick <barwick@gmail.com> wrote:
>> If you are using a Systemd-enabled Linux, check that "RemoveIPC" is
>> set to "no".
> That was the answer. I checked other servers, they had it set. But they are much older OSs (overdue for updates,
RSN),different installers.
I looked at this on my own machines and was interested to find that
RHEL8 defaults it to "no", although the upstream default is evidently
"yes" and Fedora follows that. Not sure what to make of that,
except that OS-vendor opinion isn't universal that this is a great
idea.
regards, tom lane
> On Jul 27, 2022, at 9:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > ...OS-vendor opinion isn't universal that this is a great > idea. And I think that Canonical's opinion changed somewhere along the line
On Wed, Jul 27, 2022 at 11:26:44PM -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Scott Ribe <scott_ribe@elevated-dev.com> writes: > > On Jul 27, 2022, at 11:30 AM, Ian Lawrence Barwick <barwick@gmail.com> wrote: > >> If you are using a Systemd-enabled Linux, check that "RemoveIPC" is > >> set to "no". > > > That was the answer. I checked other servers, they had it set. But they are much older OSs (overdue for updates, RSN),different installers. > > I looked at this on my own machines and was interested to find that > RHEL8 defaults it to "no", although the upstream default is evidently > "yes" and Fedora follows that. Not sure what to make of that, > except that OS-vendor opinion isn't universal that this is a great > idea. > > regards, tom lane It is not a great idea. On Debian, I had a postgres user cronjob, and occasionally, systemd in its infinite wisdom would decide that the end of the cronjob meant that the postgres user had logged out and needed to have its IPC resources deleted, even though the IPC resources in question were created by a different long-running postgres user "session" that was still running (i.e., the database server). The consequence was error messages from the database claiming that the database was corrupt. Very scary. It wasn't corrupt. It just needed systemd to stop deleting its stuff. cheers, raf