1
0
mirror of https://github.com/postgres/postgres.git synced 2025-05-28 05:21:27 +03:00
Andres Freund 80a8f95b3b Remove support for background workers without BGWORKER_SHMEM_ACCESS.
Background workers without shared memory access have been broken on
EXEC_BACKEND / windows builds since shortly after background workers have been
introduced, without that being reported. Clearly they are not commonly used.

The problem is that bgworker startup requires to be attached to shared memory
in EXEC_BACKEND child processes. StartBackgroundWorker() detaches from shared
memory for unconnected workers, but at that point we already have initialized
subsystems referencing shared memory.

Fixing this problem is not entirely trivial, so removing the option to not be
connected to shared memory seems the best way forward. In most use cases the
advantages of being connected to shared memory far outweigh the disadvantages.

As there have been no reports about this issue so far, we have decided that it
is not worth trying to address the problem in the back branches.

Per discussion with Alvaro Herrera, Robert Haas and Tom Lane.

Author: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20210802065116.j763tz3vz4egqy3w@alap3.anarazel.de
2021-08-13 05:49:26 -07:00
..
2020-07-05 15:37:57 +02:00
2020-09-10 14:15:26 +02:00
2021-07-16 12:39:45 +02:00
2020-10-26 19:17:05 -04:00
2021-07-01 21:29:34 +02:00
2020-02-26 13:05:30 -08:00
2020-03-29 11:15:11 +02:00
2021-01-29 14:09:41 +13:00
2020-07-18 22:43:35 +09:00
2021-04-07 13:52:26 +02:00
2020-10-19 13:48:00 +02:00
2021-07-16 12:39:45 +02:00
2020-06-07 13:18:36 +02:00
2021-07-05 09:36:11 +05:30
2020-07-18 22:43:35 +09:00
2021-07-16 12:39:45 +02:00
2021-07-05 09:36:11 +05:30
2019-10-25 20:39:41 +02:00
2021-07-16 12:39:45 +02:00
2020-07-18 22:43:35 +09:00
2020-10-19 19:28:54 +03:00
2021-07-16 12:39:45 +02:00
2021-01-02 13:06:25 -05:00
2021-08-13 10:32:17 +02:00
2019-09-08 10:27:29 +02:00
2021-03-15 18:13:42 -03:00
2021-07-16 12:39:45 +02:00
2021-01-05 14:26:37 -05:00
2020-08-28 08:19:12 +02:00
2021-07-16 12:39:45 +02:00
2020-12-23 09:33:20 -05:00
2021-07-05 09:36:11 +05:30
2021-03-18 18:22:18 +01:00
2021-06-28 11:31:16 -04:00
2021-06-28 11:31:16 -04:00
2021-08-06 20:55:59 +02:00
2019-09-08 10:27:29 +02:00
2019-03-27 23:10:23 +01:00
2021-07-16 12:39:45 +02:00
2019-09-08 10:27:29 +02:00

<!-- doc/src/sgml/README.links -->

Linking within DocBook documents can be confusing, so here is a summary:


Intra-document Linking
----------------------

<xref>
	use to get chapter/section number from the title of the target
	link, or xreflabel if defined at the target, or refentrytitle if target
        is a refentry;  has no close tag
	http://www.oasis-open.org/docbook/documentation/reference/html/xref.html

linkend=
	controls the target of the link/xref, required

endterm=
	for <xref>, allows the text of the link/xref to be taken from a
	different link target title

<link>
	use to supply text for the link, only uses linkend, requires </link>
	http://www.oasis-open.org/docbook/documentation/reference/html/link.html
	can be embedded inside of <command>, unlike <xref>


External Linking
----------------

<ulink>
	like <link>, but uses a URL (not a document target);  requires
	</ulink>; if no text is specified, the URL appears as the link
	text
	http://www.oasis-open.org/docbook/documentation/reference/html/ulink.html

url=
	used by <ulink> to specify the URL, required


Guidelines
----------

- For an internal link, if you want to supply text, use <link>, else
  <xref>.

- Specific nouns like GUC variables, SQL commands, and contrib modules
  usually have xreflabels.

- For an external link, use <ulink>, with or without link text.

- xreflabels added to tags prevent the chapter/section for id's from being
  referenced;  only the xreflabel is accessible.  Therefore, use xreflabels
  only when linking is common, and chapter/section information is unneeded.