summaryrefslogtreecommitdiff
path: root/contrib/pg_freespacemap
Commit message (Collapse)AuthorAgeFilesLines
* Update copyright for 2023Bruce Momjian2023-01-021-1/+1
| | | | Backpatch-through: 11
* Add copyright notices to meson filesAndrew Dunstan2022-12-201-0/+2
| | | | Discussion: https://postgr.es/m/222b43a5-2fb3-2c1b-9cd0-375d376c8246@dunslane.net
* meson: Add 'running' test setup, as a replacement for installcheckAndres Freund2022-12-071-0/+3
| | | | | | | | | | | | | To run all tests that support running against existing server: $ meson test --setup running To run just the main pg_regress tests against existing server: $ meson test --setup running regress-running/regress To ensure the 'running' setup continues to work, test it as part of the freebsd CI task. Discussion: https://postgr.es/m/CAH2-Wz=XDQcmLoo7RR_i6FKQdDmcyb9q5gStnfuuQXrOGhB2sQ@mail.gmail.com
* meson: Add windows resource filesAndres Freund2022-10-051-3/+11
| | | | | | | | | | | | | The generated resource files aren't exactly the same ones as the old buildsystems generate. Previously "InternalName" and "OriginalFileName" were mostly wrong / not set (despite being required), but that was hard to fix in at least the make build. Additionally, the meson build falls back to a "auto-generated" description when not set, and doesn't set it in a few cases - unlikely that anybody looks at these descriptions in detail. Author: Andres Freund <andres@anarazel.de> Author: Nazir Bilal Yavuz <byavuz81@gmail.com> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
* meson: Add initial version of meson based build systemAndres Freund2022-09-211-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Autoconf is showing its age, fewer and fewer contributors know how to wrangle it. Recursive make has a lot of hard to resolve dependency issues and slow incremental rebuilds. Our home-grown MSVC build system is hard to maintain for developers not using Windows and runs tests serially. While these and other issues could individually be addressed with incremental improvements, together they seem best addressed by moving to a more modern build system. After evaluating different build system choices, we chose to use meson, to a good degree based on the adoption by other open source projects. We decided that it's more realistic to commit a relatively early version of the new build system and mature it in tree. This commit adds an initial version of a meson based build system. It supports building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD, Solaris and Windows (however only gcc is supported on aix, solaris). For Windows/MSVC postgres can now be built with ninja (faster, particularly for incremental builds) and msbuild (supporting the visual studio GUI, but building slower). Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM bitcode generation, documentation adjustments) are done in subsequent commits requiring further review. Other aspects (e.g. not installing test-only extensions) are not yet addressed. When building on Windows with msbuild, builds are slower when using a visual studio version older than 2019, because those versions do not support MultiToolTask, required by meson for intra-target parallelism. The plan is to remove the MSVC specific build system in src/tools/msvc soon after reaching feature parity. However, we're not planning to remove the autoconf/make build system in the near future. Likely we're going to keep at least the parts required for PGXS to keep working around until all supported versions build with meson. Some initial help for postgres developers is at https://wiki.postgresql.org/wiki/Meson With contributions from Thomas Munro, John Naylor, Stone Tickle and others. Author: Andres Freund <andres@anarazel.de> Author: Nazir Bilal Yavuz <byavuz81@gmail.com> Author: Peter Eisentraut <peter@eisentraut.org> Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
* Avoid instabilities with the regression tests of pg_freespacemapMichael Paquier2022-03-292-0/+6
| | | | | | | | | | | | | | | | | | | It was possible to run those tests with installcheck, but they are actually unstable as concurrent autovacuum jobs could prevent the truncation of the filespace map to happen (aka the scan of pg_database when building the list of relations to clean), an assumption we rely on when checking that the FSM of the relation gets truncated during a manual vacuum after deleting all the relation's data. This commit adds a NO_INSTALLCHECK to disallow installcheck, and introduces the use of a custom configuration file with autovacuum disabled. It happens that we already do that in the recovery test 008_fsm_truncation, for example. Reported-by: Tom Lane, via buildfarm member skink Discussion: https://postgr.es/m/381910.1648401526@sss.pgh.pa.us
* Add some basic regression tests for pg_freespacemapMichael Paquier2022-03-244-0/+123
| | | | | | | | | | | | The number of relation pages is tricky to get right in a portable way, particularly across 32b and 64b builds, but checking after the existence of the FSM and if there is any space available space should be stable enough with a minimal number of tuples involved. This commit introduces checks on a table with some btree, BRIN and hash indexes, as a first attempt. Author: Dong Wook Lee, Fabrízio de Royes Mello, Michael Paquier Discussion: https://postgr.es/m/CAAcByaJ5KW3bd7fJr=jPEyK8M_UzXJFHHBVuOcBe+JHD8txRyQ@mail.gmail.com
* Remove support for upgrading extensions from "unpackaged" state.Tom Lane2020-02-192-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Andres Freund pointed out that allowing non-superusers to run "CREATE EXTENSION ... FROM unpackaged" has security risks, since the unpackaged-to-1.0 scripts don't try to verify that the existing objects they're modifying are what they expect. Just attaching such objects to an extension doesn't seem too dangerous, but some of them do more than that. We could have resolved this, perhaps, by still requiring superuser privilege to use the FROM option. However, it's fair to ask just what we're accomplishing by continuing to lug the unpackaged-to-1.0 scripts forward. None of them have received any real testing since 9.1 days, so they may not even work anymore (even assuming that one could still load the previous "loose" object definitions into a v13 database). And an installation that's trying to go from pre-9.1 to v13 or later in one jump is going to have worse compatibility problems than whether there's a trivial way to convert their contrib modules into extension style. Hence, let's just drop both those scripts and the core-code support for "CREATE EXTENSION ... FROM". Discussion: https://postgr.es/m/20200213233015.r6rnubcvl4egdh5r@alap3.anarazel.de
* Split all OBJS style lines in makefiles into one-line-per-entry style.Andres Freund2019-11-051-1/+3
| | | | | | | | | | | | | | | When maintaining or merging patches, one of the most common sources for conflicts are the list of objects in makefiles. Especially when the split across lines has been changed on both sides, which is somewhat common due to attempting to stay below 80 columns, those conflicts are unnecessarily laborious to resolve. By splitting, and alphabetically sorting, OBJS style lines into one object per line, conflicts should be less frequent, and easier to resolve when they still occur. Author: Andres Freund Discussion: https://postgr.es/m/20191029200901.vww4idgcxv74cwes@alap3.anarazel.de
* Replace heapam.h includes with {table, relation}.h where applicable.Andres Freund2019-01-211-1/+1
| | | | | | | | | A lot of files only included heapam.h for relation_open, heap_open etc - replace the heapam.h include in those files with the narrower header. Author: Andres Freund Discussion: https://postgr.es/m/20190111000539.xbv7s6w7ilcvm7dp@alap3.anarazel.de
* Don't include heapam.h from others headers.Andres Freund2019-01-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | heapam.h previously was included in a number of widely used headers (e.g. execnodes.h, indirectly in executor.h, ...). That's problematic on its own, as heapam.h contains a lot of low-level details that don't need to be exposed that widely, but becomes more problematic with the upcoming introduction of pluggable table storage - it seems inappropriate for heapam.h to be included that widely afterwards. heapam.h was largely only included in other headers to get the HeapScanDesc typedef (which was defined in heapam.h, even though HeapScanDescData is defined in relscan.h). The better solution here seems to be to just use the underlying struct (forward declared where necessary). Similar for BulkInsertState. Another problem was that LockTupleMode was used in executor.h - parts of the file tried to cope without heapam.h, but due to the fact that it indirectly included it, several subsequent violations of that goal were not not noticed. We could just reuse the approach of declaring parameters as int, but it seems nicer to move LockTupleMode to lockoptions.h - that's not a perfect location, but also doesn't seem bad. As a number of files relied on implicitly included heapam.h, a significant number of files grew an explicit include. It's quite probably that a few external projects will need to do the same. Author: Andres Freund Reviewed-By: Alvaro Herrera Discussion: https://postgr.es/m/20190114000701.y4ttcb74jpskkcfb@alap3.anarazel.de
* Default monitoring rolesSimon Riggs2017-03-303-3/+10
| | | | | | | | | | | | Three nologin roles with non-overlapping privs are created by default * pg_read_all_settings - read all GUCs. * pg_read_all_stats - pg_stat_*, pg_database_size(), pg_tablespace_size() * pg_stat_scan_tables - may lock/scan tables Top level role - pg_monitor includes all of the above by default, plus others Author: Dave Page Reviewed-by: Stephen Frost, Robert Haas, Peter Eisentraut, Simon Riggs
* Update pg_freespacemap extension for parallel query.Robert Haas2016-06-094-5/+13
| | | | | | All functions provided by this extension are PARALLEL SAFE. Andreas Karlsson
* Fix typos in some error messages thrown by extension scripts when fed to psql.Andres Freund2014-08-251-1/+1
| | | | | | | | | | Some of the many error messages introduced in 458857cc missed 'FROM unpackaged'. Also e016b724 and 45ffeb7e forgot to quote extension version numbers. Backpatch to 9.1, just like 458857cc which introduced the messages. Do so because the error messages thrown when the wrong command is copy & pasted aren't easy to understand.
* Add file version information to most installed Windows binaries.Noah Misch2014-07-141-1/+2
| | | | | | | | Prominent binaries already had this metadata. A handful of minor binaries, such as pg_regress.exe, still lack it; efforts to eliminate such exceptions are welcome. Michael Paquier, reviewed by MauMau.
* Adjust blank lines around PG_MODULE_MAGIC defines, for consistencyBruce Momjian2014-07-101-1/+0
| | | | Report by Robert Haas
* Create function prototype as part of PG_FUNCTION_INFO_V1 macroPeter Eisentraut2014-04-181-2/+0
| | | | | | | | | | | | | | | | | Because of gcc -Wmissing-prototypes, all functions in dynamically loadable modules must have a separate prototype declaration. This is meant to detect global functions that are not declared in header files, but in cases where the function is called via dfmgr, this is redundant. Besides filling up space with boilerplate, this is a frequent source of compiler warnings in extension modules. We can fix that by creating the function prototype as part of the PG_FUNCTION_INFO_V1 macro, which such modules have to use anyway. That makes the code of modules cleaner, because there is one less place where the entry points have to be listed, and creates an additional check that functions have the right prototype. Remove now redundant prototypes from contrib and other modules.
* Throw a useful error message if an extension script file is fed to psql.Tom Lane2011-10-122-0/+6
| | | | | | | | | | | | | | | | We have seen one too many reports of people trying to use 9.1 extension files in the old-fashioned way of sourcing them in psql. Not only does that usually not work (due to failure to substitute for MODULE_PATHNAME and/or @extschema@), but if it did work they'd get a collection of loose objects not an extension. To prevent this, insert an \echo ... \quit line that prints a suitable error message into each extension script file, and teach commands/extension.c to ignore lines starting with \echo. That should not only prevent any adverse consequences of loading a script file the wrong way, but make it crystal clear to users that they need to do it differently now. Tom Lane, following an idea of Andrew Dunstan's. Back-patch into 9.1 ... there is not going to be much value in this if we wait till 9.2.
* Remove unnecessary #include references, per pgrminclude script.Bruce Momjian2011-09-011-2/+0
|
* Avoid use of CREATE OR REPLACE FUNCTION in extension installation files.Tom Lane2011-02-131-2/+2
| | | | | | | | | | | It was never terribly consistent to use OR REPLACE (because of the lack of comparable functionality for data types, operators, etc), and experimentation shows that it's now positively pernicious in the extension world. We really want a failure to occur if there are any conflicts, else it's unclear what the extension-ownership state of the conflicted object ought to be. Most of the time, CREATE EXTENSION will fail anyway because of conflicts on other object types, but an extension defining only functions can succeed, with bad results.
* Convert contrib modules to use the extension facility.Tom Lane2011-02-136-15/+12
| | | | | | | | | | | This isn't fully tested as yet, in particular I'm not sure that the "foo--unpackaged--1.0.sql" scripts are OK. But it's time to get some buildfarm cycles on it. sepgsql is not converted to an extension, mainly because it seems to require a very nonstandard installation process. Dimitri Fontaine and Tom Lane
* Remove useless whitespace at end of linesPeter Eisentraut2010-11-231-3/+3
|
* Convert cvsignore to gitignore, and add .gitignore for build targets.Magnus Hagander2010-09-221-0/+1
|
* Remove cvs keywords from all files.Magnus Hagander2010-09-204-4/+4
|
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-111-5/+5
| | | | provided by Andrew.
* Properly mark pg_freespace() function as strict. Also updateTom Lane2009-06-102-8/+5
| | | | uninstall script to match reality.
* Remove useless (leftover?) extern declaration.Tom Lane2009-04-071-2/+1
|
* Make the blkno arguments bigints instead of int4s. A signed int4 is notHeikki Linnakangas2008-10-022-11/+9
| | | | | | large enough for block numbers higher than 2^31. The old pre-FSM-rewrite pg_freespacemap implementation got this right. While we're at it, remove some unnecessary #includes.
* Rewrite pg_freespacemap to match the new FSM implementation. I missed theseHeikki Linnakangas2008-09-304-369/+25
| | | | changes from the main FSM commit for some reason.
* Rewrite the FSM. Instead of relying on a fixed-size shared memory segment, theHeikki Linnakangas2008-09-301-33/+15
| | | | | | | | | | | | | free space information is stored in a dedicated FSM relation fork, with each relation (except for hash indexes; they don't use FSM). This eliminates the max_fsm_relations and max_fsm_pages GUC options; remove any trace of them from the backend, initdb, and documentation. Rewrite contrib/pg_freespacemap to match the new FSM implementation. Also introduce a new variant of the get_raw_page(regclass, int4, int4) function in contrib/pageinspect that let's you to return pages from any relation fork, and a new fsm_page_contents() function to inspect the new FSM pages.
* Restructure some header files a bit, in particular heapam.h, by removing someAlvaro Herrera2008-05-121-3/+4
| | | | | | | | | | | | unnecessary #include lines in it. Also, move some tuple routine prototypes and macros to htup.h, which allows removal of heapam.h inclusion from some .c files. For this to work, a new header file access/sysattr.h needed to be created, initially containing attribute numbers of system columns, for pg_dump usage. While at it, make contrib ltree, intarray and hstore header files more consistent with our header style.
* Add CVS version labels to all install/uninstall scripts.Bruce Momjian2007-11-132-0/+4
|
* Make /contrib install/uninstall script consistent:Bruce Momjian2007-11-112-3/+1
| | | | | | | | | | | | remove transactions use create or replace function make formatting consistent set search patch on first line Add documentation on modifying *.sql to set the search patch, and mention that major upgrades should still run the installation scripts. Some of these issues were spotted by Tom today.
* Remove references to READMEs from /contrib Makefiles.Bruce Momjian2007-11-101-2/+1
|
* Move most /contrib README files into SGML. Some still need conversionBruce Momjian2007-11-101-173/+0
| | | | or will never be converted.
* Fix PGXS conventions so that extensions can be built against PostgresTom Lane2007-06-261-2/+3
| | | | | | installations whose pg_config program does not appear first in the PATH. Per gripe from Eddie Stanley and subsequent discussions with Fabien Coelho and others.
* Clean up local redeclarations of variables with DLLIMPORT, per reportTom Lane2006-10-191-8/+1
| | | | from Magnus that MSVC complains about this.
* pgindent run for 8.2.Bruce Momjian2006-10-041-64/+65
|
* uninstall script for pg_freespacemapTom Lane2006-09-302-1/+9
|
* Fix free space map to correctly track the total amount of FSM space neededTom Lane2006-09-213-47/+47
| | | | | | | even when a single relation requires more than max_fsm_pages pages. Also, make VACUUM emit a warning in this case, since it likely means that VACUUM FULL or other drastic corrective measure is needed. Per reports from Jeff Frost and others of unexpected changes in the claimed max_fsm_pages need.
* Magic blocks don't do us any good unless we use 'em ... so install oneTom Lane2006-05-301-1/+3
| | | | in every shared library.
* Code review for contrib/pg_freespacemap. Add a storedpages column toTom Lane2006-05-043-211/+181
| | | | | | | pg_freespacemap_relations --- while one could theoretically get that number by counting rows in pg_freespacemap_pages, it's surely the hard way to do it. Avoid expensive and inconvenient conversion to and from text format. Minor code and docs cleanup.
* Split out pg_freespace views to one for relations and another for pages,Bruce Momjian2006-04-263-64/+337
| | | | | | pg_freespacemap_relations and pg_freespacemap_pages. Mark Kirkwood
* Adjust /contrib/pg_freespace to show index free space as NULL (FSM onlyBruce Momjian2006-04-263-50/+71
| | | | | | | | | | | | tracks index pages, not free space on pages): 1/ Index free bytes set to NULL 2/ Comment added to the README briefly mentioning the index business 3/ Columns reordered more logically 4/ 'Blockid' column removed 5/ Free bytes column renamed to just 'bytes' instead of 'blockfreebytes' Mark Kirkwood
* Clean up CREATE FUNCTION syntax usage in contrib and elsewhere, inPeter Eisentraut2006-02-271-1/+1
| | | | | particular get rid of single quotes around language names and old WITH () construct.
* Need a DLLIMPORT for MaxFSMPages, per buildfarm failure on snake.Tom Lane2006-02-141-1/+3
|
* Add contrib/pg_freespacemap to display free space map information.Bruce Momjian2006-02-124-0/+365
Mark Kirkwood
View Lorry Controller Status