2003-04-07 00:45:23 +02:00
|
|
|
/*------------------------------------------------------------------------
|
|
|
|
* PostgreSQL manual configuration settings
|
|
|
|
*
|
|
|
|
* This file contains various configuration symbols and limits. In
|
|
|
|
* all cases, changing them is only useful in very rare situations or
|
2014-05-06 18:12:18 +02:00
|
|
|
* for developers. If you edit any of these, be sure to do a *full*
|
2003-04-07 00:45:23 +02:00
|
|
|
* rebuild (and an initdb if noted).
|
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
2012-01-02 04:39:59 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/pg_config_manual.h
|
2003-04-07 00:45:23 +02:00
|
|
|
*------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
Make WAL segment size configurable at initdb time.
For performance reasons a larger segment size than the default 16MB
can be useful. A larger segment size has two main benefits: Firstly,
in setups using archiving, it makes it easier to write scripts that
can keep up with higher amounts of WAL, secondly, the WAL has to be
written and synced to disk less frequently.
But at the same time large segment size are disadvantageous for
smaller databases. So far the segment size had to be configured at
compile time, often making it unrealistic to choose one fitting to a
particularly load. Therefore change it to a initdb time setting.
This includes a breaking changes to the xlogreader.h API, which now
requires the current segment size to be configured. For that and
similar reasons a number of binaries had to be taught how to recognize
the current segment size.
Author: Beena Emerson, editorialized by Andres Freund
Reviewed-By: Andres Freund, David Steele, Kuntal Ghosh, Michael
Paquier, Peter Eisentraut, Robert Hass, Tushar Ahuja
Discussion: https://postgr.es/m/CAOG9ApEAcQ--1ieKbhFzXSQPw_YLmepaa4hNdnY5+ZULpt81Mw@mail.gmail.com
2017-09-20 07:03:48 +02:00
|
|
|
/*
|
2018-12-29 00:24:11 +01:00
|
|
|
* This is the default value for wal_segment_size to be used when initdb is run
|
|
|
|
* without the --wal-segsize option. It must be a valid segment size.
|
Make WAL segment size configurable at initdb time.
For performance reasons a larger segment size than the default 16MB
can be useful. A larger segment size has two main benefits: Firstly,
in setups using archiving, it makes it easier to write scripts that
can keep up with higher amounts of WAL, secondly, the WAL has to be
written and synced to disk less frequently.
But at the same time large segment size are disadvantageous for
smaller databases. So far the segment size had to be configured at
compile time, often making it unrealistic to choose one fitting to a
particularly load. Therefore change it to a initdb time setting.
This includes a breaking changes to the xlogreader.h API, which now
requires the current segment size to be configured. For that and
similar reasons a number of binaries had to be taught how to recognize
the current segment size.
Author: Beena Emerson, editorialized by Andres Freund
Reviewed-By: Andres Freund, David Steele, Kuntal Ghosh, Michael
Paquier, Peter Eisentraut, Robert Hass, Tushar Ahuja
Discussion: https://postgr.es/m/CAOG9ApEAcQ--1ieKbhFzXSQPw_YLmepaa4hNdnY5+ZULpt81Mw@mail.gmail.com
2017-09-20 07:03:48 +02:00
|
|
|
*/
|
|
|
|
#define DEFAULT_XLOG_SEG_SIZE (16*1024*1024)
|
|
|
|
|
2007-02-06 10:16:08 +01:00
|
|
|
/*
|
|
|
|
* Maximum length for identifiers (e.g. table names, column names,
|
Reduce the alignment requirement of type "name" from int to char, and arrange
to suppress zero-padding of "name" entries in indexes.
The alignment change is unlikely to save any space, but it is really needed
anyway to make the world safe for our widespread practice of passing plain
old C strings to functions that are declared as taking Name. In the previous
coding, the C compiler was entitled to assume that a Name pointer was
word-aligned; but we were failing to guarantee that. I think the reason
we'd not seen failures is that usually the only thing that gets done with
such a pointer is strcmp(), which is hard to optimize in a way that exploits
word-alignment. Still, some enterprising compiler guy will probably think
of a way eventually, or we might change our code in a way that exposes
more-obvious optimization opportunities.
The padding change is accomplished in one-liner fashion by declaring the
"name" index opclasses to use storage type "cstring" in pg_opclass.h.
Normally btree and hash don't allow a nondefault storage type, because they
don't have any provisions for converting the input datum to another type.
However, because name and cstring are effectively the same thing except for
padding, no conversion is needed --- we only need index_form_tuple() to treat
the datum as being cstring not name, and this is sufficient. This seems to
make for about a one-third reduction in the typical sizes of system catalog
indexes that involve "name" columns, of which we have many.
These two changes are only weakly related, but the alignment change makes
me feel safer that the padding change won't introduce problems, so I'm
committing them together.
2008-06-24 19:58:27 +02:00
|
|
|
* function names). Names actually are limited to one less byte than this,
|
|
|
|
* because the length must include a trailing zero byte.
|
2007-02-06 10:16:08 +01:00
|
|
|
*
|
|
|
|
* Changing this requires an initdb.
|
|
|
|
*/
|
|
|
|
#define NAMEDATALEN 64
|
|
|
|
|
2003-04-07 00:45:23 +02:00
|
|
|
/*
|
2005-03-29 05:01:32 +02:00
|
|
|
* Maximum number of arguments to a function.
|
2003-04-07 00:45:23 +02:00
|
|
|
*
|
2011-12-25 01:03:21 +01:00
|
|
|
* The minimum value is 8 (GIN indexes use 8-argument support functions).
|
2005-03-29 05:01:32 +02:00
|
|
|
* The maximum possible value is around 600 (limited by index tuple size in
|
|
|
|
* pg_proc's index; BLCKSZ larger than 8K would allow more). Values larger
|
|
|
|
* than needed will waste memory and processing time, but do not directly
|
|
|
|
* cost disk space.
|
2003-04-07 00:45:23 +02:00
|
|
|
*
|
2005-03-29 05:01:32 +02:00
|
|
|
* Changing this does not require an initdb, but it does require a full
|
|
|
|
* backend recompile (including any user-defined C functions).
|
|
|
|
*/
|
|
|
|
#define FUNC_MAX_ARGS 100
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Maximum number of columns in an index. There is little point in making
|
|
|
|
* this anything but a multiple of 32, because the main cost is associated
|
|
|
|
* with index tuple header size (see access/itup.h).
|
|
|
|
*
|
|
|
|
* Changing this requires an initdb.
|
2003-04-07 00:45:23 +02:00
|
|
|
*/
|
|
|
|
#define INDEX_MAX_KEYS 32
|
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
/*
|
|
|
|
* Maximum number of columns in a partition key
|
|
|
|
*/
|
|
|
|
#define PARTITION_MAX_KEYS 32
|
|
|
|
|
2019-11-27 11:21:02 +01:00
|
|
|
/*
|
|
|
|
* Decide whether built-in 8-byte types, including float8, int8, and
|
|
|
|
* timestamp, are passed by value. This is on by default if sizeof(Datum) >=
|
|
|
|
* 8 (that is, on 64-bit platforms). If sizeof(Datum) < 8 (32-bit platforms),
|
|
|
|
* this must be off. We keep this here as an option so that it is easy to
|
|
|
|
* test the pass-by-reference code paths on 64-bit platforms.
|
|
|
|
*
|
|
|
|
* Changing this requires an initdb.
|
|
|
|
*/
|
|
|
|
#if SIZEOF_VOID_P >= 8
|
|
|
|
#define USE_FLOAT8_BYVAL 1
|
|
|
|
#endif
|
|
|
|
|
Reduce the number of semaphores used under --disable-spinlocks.
Instead of allocating a semaphore from the operating system for every
spinlock, allocate a fixed number of semaphores (by default, 1024)
from the operating system and multiplex all the spinlocks that get
created onto them. This could self-deadlock if a process attempted
to acquire more than one spinlock at a time, but since processes
aren't supposed to execute anything other than short stretches of
straight-line code while holding a spinlock, that shouldn't happen.
One motivation for this change is that, with the introduction of
dynamic shared memory, it may be desirable to create spinlocks that
last for less than the lifetime of the server. Without this change,
attempting to use such facilities under --disable-spinlocks would
quickly exhaust any supply of available semaphores. Quite apart
from that, it's desirable to contain the quantity of semaphores
needed to run the server simply on convenience grounds, since using
too many may make it harder to get PostgreSQL running on a new
platform, which is mostly the point of --disable-spinlocks in the
first place.
Patch by me; review by Tom Lane.
2014-01-09 00:49:14 +01:00
|
|
|
/*
|
|
|
|
* When we don't have native spinlocks, we use semaphores to simulate them.
|
|
|
|
* Decreasing this value reduces consumption of OS resources; increasing it
|
|
|
|
* may improve performance, but supplying a real spinlock implementation is
|
|
|
|
* probably far better.
|
|
|
|
*/
|
2016-04-18 19:33:06 +02:00
|
|
|
#define NUM_SPINLOCK_SEMAPHORES 128
|
Reduce the number of semaphores used under --disable-spinlocks.
Instead of allocating a semaphore from the operating system for every
spinlock, allocate a fixed number of semaphores (by default, 1024)
from the operating system and multiplex all the spinlocks that get
created onto them. This could self-deadlock if a process attempted
to acquire more than one spinlock at a time, but since processes
aren't supposed to execute anything other than short stretches of
straight-line code while holding a spinlock, that shouldn't happen.
One motivation for this change is that, with the introduction of
dynamic shared memory, it may be desirable to create spinlocks that
last for less than the lifetime of the server. Without this change,
attempting to use such facilities under --disable-spinlocks would
quickly exhaust any supply of available semaphores. Quite apart
from that, it's desirable to contain the quantity of semaphores
needed to run the server simply on convenience grounds, since using
too many may make it harder to get PostgreSQL running on a new
platform, which is mostly the point of --disable-spinlocks in the
first place.
Patch by me; review by Tom Lane.
2014-01-09 00:49:14 +01:00
|
|
|
|
Add a basic atomic ops API abstracting away platform/architecture details.
Several upcoming performance/scalability improvements require atomic
operations. This new API avoids the need to splatter compiler and
architecture dependent code over all the locations employing atomic
ops.
For several of the potential usages it'd be problematic to maintain
both, a atomics using implementation and one using spinlocks or
similar. In all likelihood one of the implementations would not get
tested regularly under concurrency. To avoid that scenario the new API
provides a automatic fallback of atomic operations to spinlocks. All
properties of atomic operations are maintained. This fallback -
obviously - isn't as fast as just using atomic ops, but it's not bad
either. For one of the future users the atomics ontop spinlocks
implementation was actually slightly faster than the old purely
spinlock using implementation. That's important because it reduces the
fear of regressing older platforms when improving the scalability for
new ones.
The API, loosely modeled after the C11 atomics support, currently
provides 'atomic flags' and 32 bit unsigned integers. If the platform
efficiently supports atomic 64 bit unsigned integers those are also
provided.
To implement atomics support for a platform/architecture/compiler for
a type of atomics 32bit compare and exchange needs to be
implemented. If available and more efficient native support for flags,
32 bit atomic addition, and corresponding 64 bit operations may also
be provided. Additional useful atomic operations are implemented
generically ontop of these.
The implementation for various versions of gcc, msvc and sun studio have
been tested. Additional existing stub implementations for
* Intel icc
* HUPX acc
* IBM xlc
are included but have never been tested. These will likely require
fixes based on buildfarm and user feedback.
As atomic operations also require barriers for some operations the
existing barrier support has been moved into the atomics code.
Author: Andres Freund with contributions from Oskari Saarenmaa
Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
20131015123303.GH5300@awork2.anarazel.de,
20131028205522.GI20248@awork2.anarazel.de
2014-09-25 23:49:05 +02:00
|
|
|
/*
|
|
|
|
* When we have neither spinlocks nor atomic operations support we're
|
|
|
|
* implementing atomic operations on top of spinlock on top of semaphores. To
|
|
|
|
* be safe against atomic operations while holding a spinlock separate
|
|
|
|
* semaphores have to be used.
|
|
|
|
*/
|
|
|
|
#define NUM_ATOMICS_SEMAPHORES 64
|
|
|
|
|
2003-04-07 00:45:23 +02:00
|
|
|
/*
|
|
|
|
* MAXPGPATH: standard size of a pathname buffer in PostgreSQL (hence,
|
|
|
|
* maximum usable pathname length is one less).
|
|
|
|
*
|
|
|
|
* We'd use a standard system header symbol for this, if there weren't
|
|
|
|
* so many to choose from: MAXPATHLEN, MAX_PATH, PATH_MAX are all
|
|
|
|
* defined by different "standards", and often have different values
|
|
|
|
* on the same platform! So we just punt and use a reasonably
|
|
|
|
* generous setting here.
|
|
|
|
*/
|
|
|
|
#define MAXPGPATH 1024
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PG_SOMAXCONN: maximum accept-queue length limit passed to
|
|
|
|
* listen(2). You'd think we should use SOMAXCONN from
|
|
|
|
* <sys/socket.h>, but on many systems that symbol is much smaller
|
|
|
|
* than the kernel's actual limit. In any case, this symbol need be
|
|
|
|
* twiddled only if you have a kernel that refuses large limit values,
|
|
|
|
* rather than silently reducing the value to what it can handle
|
|
|
|
* (which is what most if not all Unixen do).
|
|
|
|
*/
|
|
|
|
#define PG_SOMAXCONN 10000
|
|
|
|
|
|
|
|
/*
|
|
|
|
* You can try changing this if you have a machine with bytes of
|
|
|
|
* another size, but no guarantee...
|
|
|
|
*/
|
|
|
|
#define BITS_PER_BYTE 8
|
|
|
|
|
2003-09-21 19:57:21 +02:00
|
|
|
/*
|
|
|
|
* Preferred alignment for disk I/O buffers. On some CPUs, copies between
|
|
|
|
* user space and kernel space are significantly faster if the user buffer
|
|
|
|
* is aligned on a larger-than-MAXALIGN boundary. Ideally this should be
|
|
|
|
* a platform-dependent value, but for now we just hard-wire it.
|
|
|
|
*/
|
|
|
|
#define ALIGNOF_BUFFER 32
|
|
|
|
|
2003-04-07 00:45:23 +02:00
|
|
|
/*
|
2009-01-11 19:02:17 +01:00
|
|
|
* Disable UNIX sockets for certain operating systems.
|
2003-04-07 00:45:23 +02:00
|
|
|
*/
|
2006-01-05 04:01:38 +01:00
|
|
|
#if defined(WIN32)
|
2003-08-04 02:43:34 +02:00
|
|
|
#undef HAVE_UNIX_SOCKETS
|
2003-04-07 00:45:23 +02:00
|
|
|
#endif
|
|
|
|
|
2003-04-18 03:03:42 +02:00
|
|
|
/*
|
|
|
|
* Define this if your operating system supports link()
|
|
|
|
*/
|
2006-01-05 04:01:38 +01:00
|
|
|
#if !defined(WIN32) && !defined(__CYGWIN__)
|
2003-08-04 02:43:34 +02:00
|
|
|
#define HAVE_WORKING_LINK 1
|
2003-04-18 03:03:42 +02:00
|
|
|
#endif
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2009-01-11 19:02:17 +01:00
|
|
|
/*
|
|
|
|
* USE_POSIX_FADVISE controls whether Postgres will attempt to use the
|
|
|
|
* posix_fadvise() kernel call. Usually the automatic configure tests are
|
|
|
|
* sufficient, but some older Linux distributions had broken versions of
|
|
|
|
* posix_fadvise(). If necessary you can remove the #define here.
|
|
|
|
*/
|
|
|
|
#if HAVE_DECL_POSIX_FADVISE && defined(HAVE_POSIX_FADVISE)
|
|
|
|
#define USE_POSIX_FADVISE
|
|
|
|
#endif
|
|
|
|
|
2009-01-12 06:10:45 +01:00
|
|
|
/*
|
|
|
|
* USE_PREFETCH code should be compiled only if we have a way to implement
|
|
|
|
* prefetching. (This is decoupled from USE_POSIX_FADVISE because there
|
2018-09-28 22:12:13 +02:00
|
|
|
* might in future be support for alternative low-level prefetch APIs.
|
|
|
|
* If you change this, you probably need to adjust the error message in
|
|
|
|
* check_effective_io_concurrency.)
|
2009-01-12 06:10:45 +01:00
|
|
|
*/
|
|
|
|
#ifdef USE_POSIX_FADVISE
|
|
|
|
#define USE_PREFETCH
|
|
|
|
#endif
|
|
|
|
|
2016-11-26 00:36:10 +01:00
|
|
|
/*
|
|
|
|
* Default and maximum values for backend_flush_after, bgwriter_flush_after
|
|
|
|
* and checkpoint_flush_after; measured in blocks. Currently, these are
|
|
|
|
* enabled by default if sync_file_range() exists, ie, only on Linux. Perhaps
|
|
|
|
* we could also enable by default if we have mmap and msync(MS_ASYNC)?
|
|
|
|
*/
|
|
|
|
#ifdef HAVE_SYNC_FILE_RANGE
|
|
|
|
#define DEFAULT_BACKEND_FLUSH_AFTER 0 /* never enabled by default */
|
|
|
|
#define DEFAULT_BGWRITER_FLUSH_AFTER 64
|
|
|
|
#define DEFAULT_CHECKPOINT_FLUSH_AFTER 32
|
|
|
|
#else
|
|
|
|
#define DEFAULT_BACKEND_FLUSH_AFTER 0
|
|
|
|
#define DEFAULT_BGWRITER_FLUSH_AFTER 0
|
|
|
|
#define DEFAULT_CHECKPOINT_FLUSH_AFTER 0
|
|
|
|
#endif
|
|
|
|
/* upper limit for all three variables */
|
|
|
|
#define WRITEBACK_MAX_PENDING_FLUSHES 256
|
|
|
|
|
Break out OpenSSL-specific code to separate files.
This refactoring is in preparation for adding support for other SSL
implementations, with no user-visible effects. There are now two #defines,
USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which
is defined when building with any SSL implementation. Currently, OpenSSL is
the only implementation so the two #defines go together, but USE_SSL is
supposed to be used for implementation-independent code.
The libpq SSL code is changed to use a custom BIO, which does all the raw
I/O, like we've been doing in the backend for a long time. That makes it
possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids
a couple of syscall for each send(). Probably doesn't make much performance
difference in practice - the SSL encryption is expensive enough to mask the
effect - but it was a natural result of this refactoring.
Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by
Alvaro Herrera, Andreas Karlsson, Jeff Janes.
2014-08-11 10:54:19 +02:00
|
|
|
/*
|
|
|
|
* USE_SSL code should be compiled only when compiling with an SSL
|
|
|
|
* implementation. (Currently, only OpenSSL is supported, but we might add
|
|
|
|
* more implementations in the future.)
|
|
|
|
*/
|
|
|
|
#ifdef USE_OPENSSL
|
|
|
|
#define USE_SSL
|
|
|
|
#endif
|
|
|
|
|
2003-04-07 00:45:23 +02:00
|
|
|
/*
|
|
|
|
* This is the default directory in which AF_UNIX socket files are
|
2014-05-06 18:12:18 +02:00
|
|
|
* placed. Caution: changing this risks breaking your existing client
|
2003-04-07 00:45:23 +02:00
|
|
|
* applications, which are likely to continue to look in the old
|
|
|
|
* directory. But if you just hate the idea of sockets in /tmp,
|
|
|
|
* here's where to twiddle it. You can also override this at runtime
|
|
|
|
* with the postmaster's -k switch.
|
|
|
|
*/
|
|
|
|
#define DEFAULT_PGSOCKET_DIR "/tmp"
|
|
|
|
|
2014-07-17 12:42:08 +02:00
|
|
|
/*
|
|
|
|
* This is the default event source for Windows event log.
|
|
|
|
*/
|
|
|
|
#define DEFAULT_EVENT_SOURCE "PostgreSQL"
|
|
|
|
|
2003-04-07 00:45:23 +02:00
|
|
|
/*
|
|
|
|
* The random() function is expected to yield values between 0 and
|
|
|
|
* MAX_RANDOM_VALUE. Currently, all known implementations yield
|
|
|
|
* 0..2^31-1, so we just hardwire this constant. We could do a
|
|
|
|
* configure test if it proves to be necessary. CAUTION: Think not to
|
2014-05-06 18:12:18 +02:00
|
|
|
* replace this with RAND_MAX. RAND_MAX defines the maximum value of
|
2003-04-07 00:45:23 +02:00
|
|
|
* the older rand() function, which is often different from --- and
|
|
|
|
* considerably inferior to --- random().
|
|
|
|
*/
|
2015-04-02 17:43:35 +02:00
|
|
|
#define MAX_RANDOM_VALUE PG_INT32_MAX
|
2003-04-07 00:45:23 +02:00
|
|
|
|
2012-01-02 04:39:59 +01:00
|
|
|
/*
|
|
|
|
* On PPC machines, decide whether to use the mutex hint bit in LWARX
|
|
|
|
* instructions. Setting the hint bit will slightly improve spinlock
|
|
|
|
* performance on POWER6 and later machines, but does nothing before that,
|
|
|
|
* and will result in illegal-instruction failures on some pre-POWER4
|
|
|
|
* machines. By default we use the hint bit when building for 64-bit PPC,
|
|
|
|
* which should be safe in nearly all cases. You might want to override
|
|
|
|
* this if you are building 32-bit code for a known-recent PPC machine.
|
|
|
|
*/
|
2012-06-10 21:20:04 +02:00
|
|
|
#ifdef HAVE_PPC_LWARX_MUTEX_HINT /* must have assembler support in any case */
|
2012-01-02 04:39:59 +01:00
|
|
|
#if defined(__ppc64__) || defined(__powerpc64__)
|
|
|
|
#define USE_PPC_LWARX_MUTEX_HINT
|
|
|
|
#endif
|
|
|
|
#endif
|
|
|
|
|
2012-01-02 06:01:33 +01:00
|
|
|
/*
|
|
|
|
* On PPC machines, decide whether to use LWSYNC instructions in place of
|
2014-05-06 18:12:18 +02:00
|
|
|
* ISYNC and SYNC. This provides slightly better performance, but will
|
2012-01-02 06:01:33 +01:00
|
|
|
* result in illegal-instruction failures on some pre-POWER4 machines.
|
|
|
|
* By default we use LWSYNC when building for 64-bit PPC, which should be
|
|
|
|
* safe in nearly all cases.
|
|
|
|
*/
|
|
|
|
#if defined(__ppc64__) || defined(__powerpc64__)
|
|
|
|
#define USE_PPC_LWSYNC
|
|
|
|
#endif
|
|
|
|
|
2013-09-04 22:14:33 +02:00
|
|
|
/*
|
2015-01-19 21:20:31 +01:00
|
|
|
* Assumed cache line size. This doesn't affect correctness, but can be used
|
|
|
|
* for low-level optimizations. Currently, this is used to pad some data
|
|
|
|
* structures in xlog.c, to ensure that highly-contended fields are on
|
|
|
|
* different cache lines. Too small a value can hurt performance due to false
|
|
|
|
* sharing, while the only downside of too large a value is a few bytes of
|
|
|
|
* wasted memory. The default is 128, which should be large enough for all
|
|
|
|
* supported platforms.
|
2013-09-04 22:14:33 +02:00
|
|
|
*/
|
2014-10-01 11:54:05 +02:00
|
|
|
#define PG_CACHE_LINE_SIZE 128
|
2013-09-04 22:14:33 +02:00
|
|
|
|
2003-04-07 00:45:23 +02:00
|
|
|
/*
|
|
|
|
*------------------------------------------------------------------------
|
|
|
|
* The following symbols are for enabling debugging code, not for
|
|
|
|
* controlling user-visible features or resource limits.
|
|
|
|
*------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
2013-06-27 02:00:08 +02:00
|
|
|
/*
|
|
|
|
* Include Valgrind "client requests", mostly in the memory allocator, so
|
|
|
|
* Valgrind understands PostgreSQL memory contexts. This permits detecting
|
|
|
|
* memory errors that Valgrind would not detect on a vanilla build. See also
|
|
|
|
* src/tools/valgrind.supp. "make installcheck" runs 20-30x longer under
|
|
|
|
* Valgrind. Note that USE_VALGRIND slowed older versions of Valgrind by an
|
|
|
|
* additional order of magnitude; Valgrind 3.8.1 does not have this problem.
|
|
|
|
* The client requests fall in hot code paths, so USE_VALGRIND also slows
|
|
|
|
* native execution by a few percentage points.
|
|
|
|
*
|
|
|
|
* You should normally use MEMORY_CONTEXT_CHECKING with USE_VALGRIND;
|
|
|
|
* instrumentation of repalloc() is inferior without it.
|
|
|
|
*/
|
|
|
|
/* #define USE_VALGRIND */
|
|
|
|
|
2003-04-07 00:45:23 +02:00
|
|
|
/*
|
|
|
|
* Define this to cause pfree()'d memory to be cleared immediately, to
|
2008-04-12 00:54:23 +02:00
|
|
|
* facilitate catching bugs that refer to already-freed values.
|
|
|
|
* Right now, this gets defined automatically if --enable-cassert.
|
2003-04-07 00:45:23 +02:00
|
|
|
*/
|
|
|
|
#ifdef USE_ASSERT_CHECKING
|
|
|
|
#define CLOBBER_FREED_MEMORY
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Define this to check memory allocation errors (scribbling on more
|
2014-05-06 18:12:18 +02:00
|
|
|
* bytes than were allocated). Right now, this gets defined
|
2013-06-27 02:00:08 +02:00
|
|
|
* automatically if --enable-cassert or USE_VALGRIND.
|
2003-04-07 00:45:23 +02:00
|
|
|
*/
|
2013-06-27 02:00:08 +02:00
|
|
|
#if defined(USE_ASSERT_CHECKING) || defined(USE_VALGRIND)
|
2003-04-07 00:45:23 +02:00
|
|
|
#define MEMORY_CONTEXT_CHECKING
|
|
|
|
#endif
|
|
|
|
|
2008-07-12 04:28:43 +02:00
|
|
|
/*
|
|
|
|
* Define this to cause palloc()'d memory to be filled with random data, to
|
|
|
|
* facilitate catching code that depends on the contents of uninitialized
|
2014-05-06 18:12:18 +02:00
|
|
|
* memory. Caution: this is horrendously expensive.
|
2008-07-12 04:28:43 +02:00
|
|
|
*/
|
|
|
|
/* #define RANDOMIZE_ALLOCATED_MEMORY */
|
|
|
|
|
2003-04-07 00:45:23 +02:00
|
|
|
/*
|
|
|
|
* Define this to force all parse and plan trees to be passed through
|
|
|
|
* copyObject(), to facilitate catching errors and omissions in
|
|
|
|
* copyObject().
|
|
|
|
*/
|
|
|
|
/* #define COPY_PARSE_PLAN_TREES */
|
|
|
|
|
Add a debugging option to stress-test outfuncs.c and readfuncs.c.
In the normal course of operation, query trees will be serialized only if
they are stored as views or rules; and plan trees will be serialized only
if they get passed to parallel-query workers. This leaves an awful lot of
opportunity for bugs/oversights to not get detected, as indeed we've just
been reminded of the hard way.
To improve matters, this patch adds a new compile option
WRITE_READ_PARSE_PLAN_TREES, which is modeled on the longstanding option
COPY_PARSE_PLAN_TREES; but instead of passing all parse and plan trees
through copyObject, it passes them through nodeToString + stringToNode.
Enabling this option in a buildfarm animal or two will catch problems
at least for cases that are exercised by the regression tests.
A small problem with this idea is that readfuncs.c historically has
discarded location fields, on the reasonable grounds that parse
locations in a retrieved view are not relevant to the current query.
But doing that in WRITE_READ_PARSE_PLAN_TREES breaks pg_stat_statements,
and it could cause problems for future improvements that might try to
report error locations at runtime. To fix that, provide a variant
behavior in readfuncs.c that makes it restore location fields when
told to.
In passing, const-ify the string arguments of stringToNode and its
subsidiary functions, just because it annoyed me that they weren't
const already.
Discussion: https://postgr.es/m/17114.1537138992@sss.pgh.pa.us
2018-09-18 23:11:54 +02:00
|
|
|
/*
|
|
|
|
* Define this to force all parse and plan trees to be passed through
|
|
|
|
* outfuncs.c/readfuncs.c, to facilitate catching errors and omissions in
|
|
|
|
* those modules.
|
|
|
|
*/
|
|
|
|
/* #define WRITE_READ_PARSE_PLAN_TREES */
|
|
|
|
|
2016-05-24 01:08:26 +02:00
|
|
|
/*
|
|
|
|
* Define this to force all raw parse trees for DML statements to be scanned
|
|
|
|
* by raw_expression_tree_walker(), to facilitate catching errors and
|
|
|
|
* omissions in that function.
|
|
|
|
*/
|
|
|
|
/* #define RAW_EXPRESSION_COVERAGE_TEST */
|
|
|
|
|
2003-04-07 00:45:23 +02:00
|
|
|
/*
|
|
|
|
* Enable debugging print statements for lock-related operations.
|
|
|
|
*/
|
|
|
|
/* #define LOCK_DEBUG */
|
|
|
|
|
2004-01-06 18:26:23 +01:00
|
|
|
/*
|
|
|
|
* Enable debugging print statements for WAL-related operations; see
|
|
|
|
* also the wal_debug GUC var.
|
|
|
|
*/
|
2014-06-17 07:49:20 +02:00
|
|
|
/* #define WAL_DEBUG */
|
2004-01-06 18:26:23 +01:00
|
|
|
|
2005-10-04 00:55:56 +02:00
|
|
|
/*
|
|
|
|
* Enable tracing of resource consumption during sort operations;
|
|
|
|
* see also the trace_sort GUC var. For 8.1 this is enabled by default.
|
|
|
|
*/
|
|
|
|
#define TRACE_SORT 1
|
|
|
|
|
2007-06-08 20:23:53 +02:00
|
|
|
/*
|
|
|
|
* Enable tracing of syncscan operations (see also the trace_syncscan GUC var).
|
|
|
|
*/
|
|
|
|
/* #define TRACE_SYNCSCAN */
|
|
|
|
|
2003-04-07 00:45:23 +02:00
|
|
|
/*
|
|
|
|
* Other debug #defines (documentation, anyone?)
|
|
|
|
*/
|
2005-10-04 00:55:56 +02:00
|
|
|
/* #define HEAPDEBUGALL */
|
2003-04-07 00:45:23 +02:00
|
|
|
/* #define ACLDEBUG */
|