postgres

Commit Graph

Author	SHA1	Message	Date
Alvaro Herrera	da6f3e45dd	Reorganize partitioning code There's been a massive addition of partitioning code in PostgreSQL 11, with little oversight on its placement, resulting in a catalog/partition.c with poorly defined boundaries and responsibilities. This commit tries to set a couple of distinct modules to separate things a little bit. There are no code changes here, only code movement. There are three new files: src/backend/utils/cache/partcache.c src/include/partitioning/partdefs.h src/include/utils/partcache.h The previous arrangement of #including catalog/partition.h almost everywhere is no more. Authors: Amit Langote and Álvaro Herrera Discussion: https://postgr.es/m/98e8d509-790a-128c-be7f-e48a5b2d8d97@lab.ntt.co.jp https://postgr.es/m/11aa0c50-316b-18bb-722d-c23814f39059@lab.ntt.co.jp https://postgr.es/m/143ed9a4-6038-76d4-9a55-502035815e68@lab.ntt.co.jp https://postgr.es/m/20180413193503.nynq7bnmgh6vs5vm@alvherre.pgsql	7 years ago
Robert Haas	b0313f9cc8	pageinspect: Fix use of wrong memory context by hash_page_items. This can cause it to produce incorrect output. Report and patch by Masahiko Sawada. Discussion: http://postgr.es/m/CAD21AoBc5Asx7pXdUWu6NqU_g=Ysn95EGL9SMeYhLLduYoO_OA@mail.gmail.com	8 years ago
Bruce Momjian	9d4649ca49	Update copyright for 2018 Backpatch-through: certain files through 9.3	8 years ago
Tom Lane	382ceffdf7	Phase 3 of pgindent updates. Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. 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	8 years ago
Bruce Momjian	a6fd7b7a5f	Post-PG 10 beta1 pgindent run perltidy run not included.	8 years ago
Tom Lane	2040bb4a0b	Clean up manipulations of hash indexes' hasho_flag field. Standardize on testing a hash index page's type by doing (opaque->hasho_flag & LH_PAGE_TYPE) == LH_xxx_PAGE Various places were taking shortcuts like opaque->hasho_flag & LH_BUCKET_PAGE which while not actually wrong, is still bad practice because it encourages use of opaque->hasho_flag & LH_UNUSED_PAGE which is wrong (LH_UNUSED_PAGE == 0, so the above is constant false). hash_xlog.c's hash_mask() contained such an incorrect test. This also ensures that we mask out the additional flag bits that hasho_flag has accreted since 9.6. pgstattuple's pgstat_hash_page(), for one, was failing to do that and was thus actively broken. Also fix assorted comments that hadn't been updated to reflect the extended usage of hasho_flag, and fix some macros that were testing just "(hasho_flag & bit)" to use the less dangerous, project-approved form "((hasho_flag & bit) != 0)". Coverity found the bug in hash_mask(); I noted the one in pgstat_hash_page() through code reading.	8 years ago
Robert Haas	633e15ea0f	Fix pageinspect failures on hash indexes. Make every page in a hash index which isn't all-zeroes have a valid special space, so that tools like pageinspect don't error out. Also, make pageinspect cope with all-zeroes pages, because _hash_alloc_buckets can leave behind large numbers of those until they're consumed by splits. Ashutosh Sharma and Robert Haas, reviewed by Amit Kapila. Original trouble report from Jeff Janes. Discussion: http://postgr.es/m/CAMkU=1y6NjKmqbJ8wLMhr=F74WzcMALYWcVFhEpm7i=mV=XsOg@mail.gmail.com	8 years ago
Robert Haas	b4316928d5	Fix incorrect typecast. Ashutosh Sharma, per a report from Mithun Cy. Discussion: http://postgr.es/m/CAD__OujgqNNnCujeFTmKpjNu+W4smS8Hbi=RcWAhf1ZUs3H4WA@mail.gmail.com	8 years ago
Robert Haas	fc8219dc54	pageinspect: Fix hash_bitmap_info not to read the underlying page. It did that to verify that the page was an overflow page rather than anything else, but that means that checking the status of all the overflow bits requires reading the entire index. So don't do that. The new code validates that the page is not a primary bucket page or bitmap page by looking at the metapage, so that using this on large numbers of pages can be reasonably efficient. Ashutosh Sharma, per a complaint from me, and with further modifications by me.	9 years ago
Robert Haas	871ec0e336	pageinspect: More type-sanity surgery on the new hash index code. Uniformly expose unsigned quantities using the next-wider signed integer type (since we have no unsigned types at the SQL level). At the SQL level, this results a change to report itemoffset as int4 rather than int2. Also at the SQL level, report one value that is an OID as type oid. Under the hood, uniformly use macros that match the SQL output type as to both width and signedness.	9 years ago
Tom Lane	14e9b18fed	In pageinspect/hashfuncs.c, avoid crashes on alignment-picky machines. On machines with MAXALIGN = 8, the payload of a bytea is not maxaligned, since it will start 4 bytes into a palloc'd value. On alignment-picky hardware, this will cause failures in accesses to 8-byte-wide values within the page. We already encountered this problem when we introduced GIN index inspection functions, and fixed it in commit `84ad68d64`. Make use of the same function for hash indexes. A small difficulty is that up to now contrib/pageinspect has not shared any functions at all across files. To support that, introduce a common header file "pageinspect.h" for the module. Also, move get_page_from_raw() out of ginfuncs.c, where it didn't especially belong, and put it in rawpage.c which seems a more natural home. Per buildfarm. Discussion: https://postgr.es/m/17311.1486134714@sss.pgh.pa.us	9 years ago
Tom Lane	c6eeb67dcc	Fix a bunch more portability bugs in commit `08bf6e529`. It seems like somebody used a dartboard while choosing integer widths for the various values taken and returned by these functions ... and then threw a fresh set of darts while writing the SQL declarations. This patch brings the C code into line with what the SQL declarations say, which is enough to make it not dump core on the particular 32-bit machine I'm testing on. But I think we could do with another round of looking at what the datum widths should be. For instance, it's not all that sensible that hash_bitmap_info decided to use int64 to represent a BlockNumber input when get_raw_page doesn't do it that way. There's also a remaining problem that the expected outputs from the test script are platform-dependent, but I'll leave that issue for somebody else. Per buildfarm.	9 years ago
Robert Haas	ed807fda6d	pageinspect: Try to fix some bugs in previous commit. Commit `08bf6e5295` seems not to have used the correct GetDatum and PG_GETARG_ macros for the SQL types in some cases, and some of the SQL types seem to have been poorly chosen, too. Try to fix it. I'm not sure if this is the reason why the buildfarm is currently unhappy with this code, but it seems like a good place to start. Buildfarm unhappiness reported by Tom Lane.	9 years ago
Robert Haas	08bf6e5295	pageinspect: Support hash indexes. Patch by Jesper Pedersen and Ashutosh Sharma, with some error handling improvements by me. Tests from Peter Eisentraut. Reviewed by Álvaro Herrera, Michael Paquier, Jesper Pedersen, Jeff Janes, Peter Eisentraut, Amit Kapila, Mithun Cy, and me. Discussion: http://postgr.es/m/e2ac6c58-b93f-9dd9-f4e6-d6d30add7fdf@redhat.com	9 years ago

14 Commits (1667148a4dd98cea28b8b53d57dbc1eece1b0b5c)