2002-05-05 02:03:29 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* pg_shmem.h
|
|
|
|
|
* Platform-independent API for shared memory support.
|
|
|
|
|
*
|
|
|
|
|
* Every port is expected to support shared memory with approximately
|
|
|
|
|
* SysV-ish semantics; in particular, a memory block is not anonymous
|
|
|
|
|
* but has an ID, and we must be able to tell whether there are any
|
|
|
|
|
* remaining processes attached to a block of a specified ID.
|
|
|
|
|
*
|
|
|
|
|
* To simplify life for the SysV implementation, the ID is assumed to
|
|
|
|
|
* consist of two unsigned long values (these are key and ID in SysV
|
2014-05-06 18:12:18 +02:00
|
|
|
* terms). Other platforms may ignore the second value if they need
|
2002-05-05 02:03:29 +02:00
|
|
|
* only one ID number.
|
|
|
|
|
*
|
|
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
2002-05-05 02:03:29 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/storage/pg_shmem.h
|
2002-05-05 02:03:29 +02:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef PG_SHMEM_H
|
|
|
|
|
#define PG_SHMEM_H
|
|
|
|
|
|
2014-04-08 17:39:55 +02:00
|
|
|
#include "storage/dsm_impl.h"
|
|
|
|
|
|
2002-05-05 02:03:29 +02:00
|
|
|
typedef struct PGShmemHeader /* standard header for all Postgres shmem */
|
|
|
|
|
{
|
|
|
|
|
int32 magic; /* magic # to identify Postgres segments */
|
2006-01-04 22:06:32 +01:00
|
|
|
#define PGShmemMagic 679834894
|
2002-05-05 02:03:29 +02:00
|
|
|
pid_t creatorPID; /* PID of creating process */
|
2005-08-21 01:26:37 +02:00
|
|
|
Size totalsize; /* total size of segment */
|
|
|
|
|
Size freeoffset; /* offset to first free space */
|
2014-04-08 17:39:55 +02:00
|
|
|
dsm_handle dsm_control; /* ID of dynamic shared memory control seg */
|
2008-11-02 22:24:52 +01:00
|
|
|
void *index; /* pointer to ShmemIndex table */
|
2004-11-09 22:30:18 +01:00
|
|
|
#ifndef WIN32 /* Windows doesn't have useful inode#s */
|
|
|
|
|
dev_t device; /* device data directory is on */
|
|
|
|
|
ino_t inode; /* inode number of data directory */
|
|
|
|
|
#endif
|
2002-05-05 02:03:29 +02:00
|
|
|
} PGShmemHeader;
|
|
|
|
|
|
Allow using huge TLB pages on Linux (MAP_HUGETLB)
This patch adds an option, huge_tlb_pages, which allows requesting the
shared memory segment to be allocated using huge pages, by using the
MAP_HUGETLB flag in mmap(). This can improve performance.
The default is 'try', which means that we will attempt using huge pages,
and fall back to non-huge pages if it doesn't work. Currently, only Linux
has MAP_HUGETLB. On other platforms, the default 'try' behaves the same as
'off'.
In the passing, don't try to round the mmap() size to a multiple of
pagesize. mmap() doesn't require that, and there's no particular reason for
PostgreSQL to do that either. When using MAP_HUGETLB, however, round the
request size up to nearest 2MB boundary. This is to work around a bug in
some Linux kernel versions, but also to avoid wasting memory, because the
kernel will round the size up anyway.
Many people were involved in writing this patch, including Christian Kruse,
Richard Poole, Abhijit Menon-Sen, reviewed by Peter Geoghegan, Andres Freund
and me.
2014-01-29 12:44:45 +01:00
|
|
|
/* GUC variable */
|
2014-05-06 18:12:18 +02:00
|
|
|
extern int huge_pages;
|
Allow using huge TLB pages on Linux (MAP_HUGETLB)
This patch adds an option, huge_tlb_pages, which allows requesting the
shared memory segment to be allocated using huge pages, by using the
MAP_HUGETLB flag in mmap(). This can improve performance.
The default is 'try', which means that we will attempt using huge pages,
and fall back to non-huge pages if it doesn't work. Currently, only Linux
has MAP_HUGETLB. On other platforms, the default 'try' behaves the same as
'off'.
In the passing, don't try to round the mmap() size to a multiple of
pagesize. mmap() doesn't require that, and there's no particular reason for
PostgreSQL to do that either. When using MAP_HUGETLB, however, round the
request size up to nearest 2MB boundary. This is to work around a bug in
some Linux kernel versions, but also to avoid wasting memory, because the
kernel will round the size up anyway.
Many people were involved in writing this patch, including Christian Kruse,
Richard Poole, Abhijit Menon-Sen, reviewed by Peter Geoghegan, Andres Freund
and me.
2014-01-29 12:44:45 +01:00
|
|
|
|
2014-03-03 19:52:48 +01:00
|
|
|
/* Possible values for huge_pages */
|
Allow using huge TLB pages on Linux (MAP_HUGETLB)
This patch adds an option, huge_tlb_pages, which allows requesting the
shared memory segment to be allocated using huge pages, by using the
MAP_HUGETLB flag in mmap(). This can improve performance.
The default is 'try', which means that we will attempt using huge pages,
and fall back to non-huge pages if it doesn't work. Currently, only Linux
has MAP_HUGETLB. On other platforms, the default 'try' behaves the same as
'off'.
In the passing, don't try to round the mmap() size to a multiple of
pagesize. mmap() doesn't require that, and there's no particular reason for
PostgreSQL to do that either. When using MAP_HUGETLB, however, round the
request size up to nearest 2MB boundary. This is to work around a bug in
some Linux kernel versions, but also to avoid wasting memory, because the
kernel will round the size up anyway.
Many people were involved in writing this patch, including Christian Kruse,
Richard Poole, Abhijit Menon-Sen, reviewed by Peter Geoghegan, Andres Freund
and me.
2014-01-29 12:44:45 +01:00
|
|
|
typedef enum
|
|
|
|
|
{
|
2014-03-03 19:52:48 +01:00
|
|
|
HUGE_PAGES_OFF,
|
|
|
|
|
HUGE_PAGES_ON,
|
|
|
|
|
HUGE_PAGES_TRY
|
2017-06-21 20:39:04 +02:00
|
|
|
} HugePagesType;
|
2002-05-05 02:03:29 +02:00
|
|
|
|
2010-01-02 13:18:45 +01:00
|
|
|
#ifndef WIN32
|
2003-12-01 23:15:38 +01:00
|
|
|
extern unsigned long UsedShmemSegID;
|
2010-01-02 13:18:45 +01:00
|
|
|
#else
|
|
|
|
|
extern HANDLE UsedShmemSegID;
|
|
|
|
|
#endif
|
2003-05-08 16:49:04 +02:00
|
|
|
extern void *UsedShmemSegAddr;
|
2004-12-29 22:36:09 +01:00
|
|
|
|
2014-02-09 03:21:46 +01:00
|
|
|
#ifdef EXEC_BACKEND
|
2004-12-29 22:36:09 +01:00
|
|
|
extern void PGSharedMemoryReAttach(void);
|
On Windows, ensure shared memory handle gets closed if not being used.
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
2015-10-13 17:21:33 +02:00
|
|
|
extern void PGSharedMemoryNoReAttach(void);
|
2003-05-07 01:34:56 +02:00
|
|
|
#endif
|
|
|
|
|
|
2005-08-21 01:26:37 +02:00
|
|
|
extern PGShmemHeader *PGSharedMemoryCreate(Size size, bool makePrivate,
|
2014-04-08 17:39:55 +02:00
|
|
|
int port, PGShmemHeader **shim);
|
2002-05-05 02:03:29 +02:00
|
|
|
extern bool PGSharedMemoryIsInUse(unsigned long id1, unsigned long id2);
|
2003-11-07 22:55:50 +01:00
|
|
|
extern void PGSharedMemoryDetach(void);
|
2002-05-05 02:03:29 +02:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* PG_SHMEM_H */
|
