aboutsummaryrefslogtreecommitdiff
path: root/src/include/pg_config_manual.h
Commit message (Collapse)AuthorAge
* Define integer limits independently from the system definitions.Andres Freund2015-04-02
| | | | | | | | | | | | | | | | | | | | | In 83ff1618 we defined integer limits iff they're not provided by the system. That turns out not to be the greatest idea because there's different ways some datatypes can be represented. E.g. on OSX PG's 64bit datatype will be a 'long int', but OSX unconditionally uses 'long long'. That disparity then can lead to warnings, e.g. around printf formats. One way to fix that would be to back int64 using stdint.h's int64_t. While a good idea it's not that easy to implement. We would e.g. need to include stdint.h in our external headers, which we don't today. Also computing the correct int64 printf formats in that case is nontrivial. Instead simply prefix the integer limits with PG_ and define them unconditionally. I've adjusted all the references to them in code, but not the ones in comments; the latter seems unnecessary to me. Discussion: 20150331141423.GK4878@alap3.anarazel.de
* Centralize definition of integer limits.Andres Freund2015-03-25
| | | | | | | | | | | | | | | | | Several submitted and even committed patches have run into the problem that C89, our baseline, does not provide minimum/maximum values for various integer datatypes. C99's stdint.h does, but we can't rely on it. Several parts of the code defined limits locally, so instead centralize the definitions to c.h. This patch also changes the more obvious usages of literal limit values; there's more places that could be changed, but it's less clear whether it's beneficial to change those. Author: Andrew Gierth Discussion: 87619tc5wc.fsf@news-spur.riddles.org.uk
* Use abbreviated keys for faster sorting of text datums.Robert Haas2015-01-19
| | | | | | | | | | | | | | | | | | | | | This commit extends the SortSupport infrastructure to allow operator classes the option to provide abbreviated representations of Datums; in the case of text, we abbreviate by taking the first few characters of the strxfrm() blob. If the abbreviated comparison is insufficent to resolve the comparison, we fall back on the normal comparator. This can be much faster than the old way of doing sorting if the first few bytes of the string are usually sufficient to resolve the comparison. There is the potential for a performance regression if all of the strings to be sorted are identical for the first 8+ characters and differ only in later positions; therefore, the SortSupport machinery now provides an infrastructure to abort the use of abbreviation if it appears that abbreviation is producing comparatively few distinct keys. HyperLogLog, a streaming cardinality estimator, is included in this commit and used to make that determination for text. Peter Geoghegan, reviewed by me.
* Update copyright for 2015Bruce Momjian2015-01-06
| | | | Backpatch certain files through 9.0
* Move PG_AUTOCONF_FILENAME definitionPeter Eisentraut2014-12-03
| | | | | | | | | Since this is not something that a user should change, pg_config_manual.h was an inappropriate place for it. In initdb.c, remove the use of the macro, because utils/guc.h can't be included by non-backend code. But we hardcode all the other configuration file names there, so this isn't a disaster.
* Detect PG_PRINTF_ATTRIBUTE automatically.Noah Misch2014-11-23
| | | | | This eliminates gobs of "unrecognized format function type" warnings under MinGW compilers predating GCC 4.4.
* Remove obsolete debugging option, RTDEBUG.Heikki Linnakangas2014-11-18
| | | | | | The r-tree AM that used it was removed back in 2005. Peter Geoghegan
* Rename CACHE_LINE_SIZE to PG_CACHE_LINE_SIZE.Andres Freund2014-10-01
| | | | | | | | | | | | | | | As noted in http://bugs.debian.org/763098 there is a conflict between postgres' definition of CACHE_LINE_SIZE and the definition by various *bsd platforms. It's debatable who has the right to define such a name, but postgres' use was only introduced in 375d8526f290 (9.4), so it seems like a good idea to rename it. Discussion: 20140930195756.GC27407@msg.df7cb.de Per complaint of Christoph Berg in the above email, although he's not the original bug reporter. Backpatch to 9.4 where the define was introduced.
* Add a basic atomic ops API abstracting away platform/architecture details.Andres Freund2014-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Break out OpenSSL-specific code to separate files.Heikki Linnakangas2014-08-11
| | | | | | | | | | | | | | | | | | | 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.
* Add option to pg_ctl to choose event source for loggingMagnus Hagander2014-07-17
| | | | | | | | | | | pg_ctl will log to the Windows event log when it is running as a service, which is the primary way of running PostgreSQL on Windows. This option makes it possible to specify which event source to use for this, in order to separate different instances. The server logging itself is still controlled by the regular logging parameters, including a separate setting for the event source. The parameter to pg_ctl only controlls the logging from pg_ctl itself. MauMau, review in many iterations by Amit Kapila and me.
* Revert accidental change of WAL_DEBUG default.Heikki Linnakangas2014-06-17
| | | | Oops.
* Change the signature of rm_desc so that it's passed a XLogRecord.Heikki Linnakangas2014-06-14
| | | | Just feels more natural, and is more consistent with rm_redo.
* pgindent run for 9.4Bruce Momjian2014-05-06
| | | | | This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
* Fix typos in comments for ALTER SYSTEM.Fujii Masao2014-01-27
| | | | Michael Paquier
* Reduce the number of semaphores used under --disable-spinlocks.Robert Haas2014-01-08
| | | | | | | | | | | | | | | | | | | | | | | 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.
* Update copyright for 2014Bruce Momjian2014-01-07
| | | | | Update all files in head, and files COPYRIGHT and legal.sgml in all back branches.
* Add ALTER SYSTEM command to edit the server configuration file.Tatsuo Ishii2013-12-18
| | | | | Patch contributed by Amit Kapila. Reviewed by Hari Babu, Masao Fujii, Boszormenyi Zoltan, Andres Freund, Greg Smith and others.
* Keep heavily-contended fields in XLogCtlInsert on different cache lines.Heikki Linnakangas2013-09-04
| | | | | | | Performance testing shows that if the insertpos_lck spinlock and the fields that it protects are on the same cache line with other variables that are frequently accessed, the false sharing can hurt performance a lot. Keep them apart by adding some padding.
* Cooperate with the Valgrind instrumentation framework.Noah Misch2013-06-26
| | | | | | | | | | | | | | | | Valgrind "client requests" in aset.c and mcxt.c teach Valgrind and its Memcheck tool about the PostgreSQL allocator. This makes Valgrind roughly as sensitive to memory errors involving palloc chunks as it is to memory errors involving malloc chunks. Further client requests in PageAddItem() and printtup() verify that all bits being added to a buffer page or furnished to an output function are predictably-defined. Those tests catch failures of C-language functions to fully initialize the bits of a Datum, which in turn stymie optimizations that rely on _equalConst(). Define the USE_VALGRIND symbol in pg_config_manual.h to enable these additions. An included "suppression file" silences nominal errors we don't plan to fix. Reviewed in earlier versions by Peter Geoghegan and Korry Douglas.
* Update copyrights for 2013Bruce Momjian2013-01-01
| | | | | Fully update git head, and update back branches in ./COPYRIGHT and legal.sgml files.
* Run pgindent on 9.2 source tree in preparation for first 9.3Bruce Momjian2012-06-10
| | | | commit-fest.
* Use LWSYNC in place of SYNC/ISYNC in PPC spinlocks, where possible.Tom Lane2012-01-02
| | | | | | | | | | | | | This is allegedly a win, at least on some PPC implementations, according to the PPC ISA documents. However, as with LWARX hints, some PPC platforms give an illegal-instruction failure. Use the same trick as before of assuming that PPC64 platforms will accept it; we might need to refine that based on experience, but there are other projects doing likewise according to google. I did not add an assembler compatibility test because LWSYNC has been around much longer than hint bits, and it seems unlikely that any toolchains currently in use don't recognize it.
* Use mutex hint bit in PPC LWARX instructions, where possible.Tom Lane2012-01-02
| | | | | | | | | | | | | | | The hint bit makes for a small but measurable performance improvement in access to contended spinlocks. On the other hand, some PPC chips give an illegal-instruction failure. There doesn't seem to be a completely bulletproof way to tell whether the hint bit will cause an illegal-instruction failure other than by trying it; but most if not all 64-bit PPC machines should accept it, so follow the Linux kernel's lead and assume it's okay to use it in 64-bit builds. Of course we must also check whether the assembler accepts the command, since even with a recent CPU the toolchain could be old. Patch by Manabu Ori, significantly modified by me.
* Rethink representation of index clauses' mapping to index columns.Tom Lane2011-12-24
| | | | | | | | | | | | | | | | | | | | | In commit e2c2c2e8b1df7dfdb01e7e6f6191a569ce3c3195 I made use of nested list structures to show which clauses went with which index columns, but on reflection that's a data structure that only an old-line Lisp hacker could love. Worse, it adds unnecessary complication to the many places that don't much care which clauses go with which index columns. Revert to the previous arrangement of flat lists of clauses, and instead add a parallel integer list of column numbers. The places that care about the pairing can chase both lists with forboth(), while the places that don't care just examine one list the same as before. The only real downside to this is that there are now two more lists that need to be passed to amcostestimate functions in case they care about column matching (which btcostestimate does, so not passing the info is not an option). Rather than deal with 11-argument amcostestimate functions, pass just the IndexPath and expect the functions to extract fields from it. That gets us down to 7 arguments which is better than 11, and it seems more future-proof against likely additions to the information we keep about an index path.
* Revert accidental change to pg_config_manual.h.Robert Haas2011-10-09
| | | | | | | | | This was broken in commit 53dbc27c62d8e1b6c5253feba04a5094cb8fe046, which introduced unlogged tables. Fortunately, as debugging tools go, this one is pretty cheap, which is probably why it took nine months for someone to notice, but it's not intended to be enabled by default, so revert. Noted by Fujii Masao.
* Use a macro variable PG_PRINTF_ATTRIBUTE for the style used for checking ↵Andrew Dunstan2011-04-28
| | | | | | | | | printf type functions. The style is set to "printf" for backwards compatibility everywhere except on Windows, where it is set to "gnu_printf", which eliminates hundreds of false error messages from modern versions of gcc arising from %m and %ll{d,u} formats.
* Support unlogged tables.Robert Haas2010-12-29
| | | | | | | The contents of an unlogged table are WAL-logged; thus, they are not available on standby servers and are truncated whenever the database system enters recovery. Indexes on unlogged tables are also unlogged. Unlogged GiST indexes are not currently supported.
* Create core infrastructure for KNNGIST.Tom Lane2010-12-02
| | | | | | | | | | | | | | | | | | | This is a heavily revised version of builtin_knngist_core-0.9. The ordering operators are no longer mixed in with actual quals, which would have confused not only humans but significant parts of the planner. Instead, ordering operators are carried separately throughout planning and execution. Since the API for ambeginscan and amrescan functions had to be changed anyway, this commit takes the opportunity to rationalize that a bit. RelationGetIndexScan no longer forces a premature index_rescan call; instead, callers of index_beginscan must call index_rescan too. Aside from making the AM-side initialization logic a bit less peculiar, this has the advantage that we do not make a useless extra am_rescan call when there are runtime key values. AMs formerly could not assume that the key values passed to amrescan were actually valid; now they can. Teodor Sigaev and Tom Lane
* Remove cvs keywords from all files.Magnus Hagander2010-09-20
|
* Remove all the special-case code for INT64_IS_BUSTED, per decision thatTom Lane2010-01-07
| | | | | | | | we're not going to support that anymore. I did keep the 64-bit-CRC-with-32-bit-arithmetic code, since it has a performance excuse to live. It's a bit moot since that's all ifdef'd out, of course.
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-11
| | | | provided by Andrew.
* Add a -w/--no-password option that prevents all password prompts to allPeter Eisentraut2009-02-26
| | | | | | programs that have a -W/--password option. In passing, remove the ancient PSQL_ALWAYS_GET_PASSWORDS compile option.
* Implement prefetching via posix_fadvise() for bitmap index scans. A newTom Lane2009-01-12
| | | | | | | | | | GUC variable effective_io_concurrency controls how many concurrent block prefetch requests will be issued. (The best way to handle this for plain index scans is still under debate, so that part is not applied yet --- tgl) Greg Stark
* Re-enable the old code in xlog.c that tried to use posix_fadvise(), so thatTom Lane2009-01-11
| | | | | | | we can get some buildfarm feedback about whether that function is still problematic. (Note that the planned async-preread patch will not really prove anything one way or the other in buildfarm testing, since it will be inactive with default GUC settings.)
* Don't make --enable-cassert turn on RANDOMIZE_ALLOCATED_MEMORY automatically;Tom Lane2008-07-12
| | | | | it's just too dang expensive. Per recent discussion, but I just got my nose rubbed in it again while doing some performance checking.
* Reduce the alignment requirement of type "name" from int to char, and arrangeTom Lane2008-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Extend yesterday's patch making BLCKSZ and RELSEG_SIZE configurable to alsoTom Lane2008-05-02
| | | | | | let XLOG_BLCKSZ and XLOG_SEG_SIZE be set via configure. Per a proposal by Mark Wong, though I thought it better to call the switches after "wal" rather than "xlog".
* Remove the recently added USE_SEGMENTED_FILES option, and indeed remove allTom Lane2008-05-02
| | | | | | | | | | support for a nonsegmented mode from md.c. Per recent discussions, there doesn't seem to be much value in a "never segment" option as opposed to segmenting with a suitably large segment size. So instead provide a configure-time switch to set the desired segment size in units of gigabytes. While at it, expose a configure switch for BLCKSZ as well. Zdenek Kotala
* Add some debug support code to try to catch future mistakes in the area ofTom Lane2008-04-11
| | | | | | | | | | input functions that include garbage bytes in their results. Provide a compile-time option RANDOMIZE_ALLOCATED_MEMORY to make palloc fill returned blocks with variable contents. This option also makes the parser perform conversions of literal constants twice and compare the results, emitting a WARNING if they don't match. (This is the code I used to catch the input function bugs fixed in the previous commit.) For the moment, I've set it to be activated automatically by --enable-cassert.
* Reduce the need for frontend programs to include "postgres.h" by refactoringTom Lane2008-03-27
| | | | | | | | | | | | inclusions in src/include/catalog/*.h files. The main idea here is to push function declarations for src/backend/catalog/*.c files into separate headers, rather than sticking them into the corresponding catalog definition file as has been done in the past. This commit only carries out that idea fully for pg_proc, pg_type and pg_conversion, but that's enough for the moment --- if pg_list.h ever becomes unsafe for frontend code to include, we'll need to work a bit more. Zdenek Kotala
* Provide a build-time option to store large relations as single files, ratherTom Lane2008-03-10
| | | | | | | | than dividing them into 1GB segments as has been our longtime practice. This requires working support for large files in the operating system; at least for the time being, it won't be the default. Zdenek Kotala
* Remove long-unused and broken TCL_ARRAYS.Alvaro Herrera2008-02-29
|
* Arrange for large sequential scans to synchronize with each other, so thatTom Lane2007-06-08
| | | | | | | when multiple backends are scanning the same relation concurrently, each page is (ideally) read only once. Jeff Davis, with review by Heikki and Tom.
* Move BLCKSZ < 1024 check to guc.c.Bruce Momjian2007-02-23
|
* Prevent BLCKSZ < 1024, and have initdb test shared buffers based on theBruce Momjian2007-02-20
| | | | BLCKSZ value.
* Move NAMEDATALEN definition from postgres_ext.h to pg_config_manual.h. ItPeter Eisentraut2007-02-06
| | | | | used to be part of libpq's exported interface many releases ago, but now it's no longer necessary to make it accessible to clients.
* Add built-in userlock manipulation functions to replace the formerTom Lane2006-09-18
| | | | | | | contrib functionality. Along the way, remove the USER_LOCKS configuration symbol, since it no longer makes any sense to try to compile that out. No user documentation yet ... mmoncure has promised to write some. Thanks to Abhijit Menon-Sen for creating a first draft to work from.
* Make the planner estimate costs for nestloop inner indexscans on the basisTom Lane2006-06-06
| | | | | | | | | | | | | | | | | | | | | that the Mackert-Lohmann formula applies across all the repetitions of the nestloop, not just each scan independently. We use the M-L formula to estimate the number of pages fetched from the index as well as from the table; that isn't what it was designed for, but it seems reasonably applicable anyway. This makes large numbers of repetitions look much cheaper than before, which accords with many reports we've received of overestimation of the cost of a nestloop. Also, change the index access cost model to charge random_page_cost per index leaf page touched, while explicitly not counting anything for access to metapage or upper tree pages. This may all need tweaking after we get some field experience, but in simple tests it seems to be giving saner results than before. The main thing is to get the infrastructure in place to let cost_index() and amcostestimate functions take repeated scans into account at all. Per my recent proposal. Note: this patch changes pg_proc.h, but I did not force initdb because the changes are basically cosmetic --- the system does not look into pg_proc to decide how to call an index amcostestimate function, and there's no way to call such a function from SQL at all.
* Define a separately configurable XLOG_BLCKSZ symbol for the page sizeTom Lane2006-04-03
| | | | | | | | | | | used within WAL files. Historically this was the same as the data file BLCKSZ, but there's no necessary connection, and it's possible that performance gains might ensue from reducing XLOG_BLCKSZ. In any case distinguishing two symbols should improve code clarity. This commit does not actually change the page size, only provide the infrastructure to make it possible to do so. initdb forced because of addition of a field to pg_control. Mark Wong, with some help from Simon Riggs and Tom Lane.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-31 16:52:53 +0000