pgsql: Make ExecGetInsertedCols() and friends more robust and improve c

2021-02-14 Thread Heikki Linnakangas
Make ExecGetInsertedCols() and friends more robust and improve comments. If ExecGetInsertedCols(), ExecGetUpdatedCols() or ExecGetExtraUpdatedCols() were called with a ResultRelInfo that's not in the range table and isn't a partition routing target, the functions would dereference a NULL pointer,

pgsql: Make ExecGetInsertedCols() and friends more robust and improve c

2021-02-14 Thread Heikki Linnakangas
Make ExecGetInsertedCols() and friends more robust and improve comments. If ExecGetInsertedCols(), ExecGetUpdatedCols() or ExecGetExtraUpdatedCols() were called with a ResultRelInfo that's not in the range table and isn't a partition routing target, the functions would dereference a NULL pointer,

pgsql: Make ExecGetInsertedCols() and friends more robust and improve c

2021-02-14 Thread Heikki Linnakangas
Make ExecGetInsertedCols() and friends more robust and improve comments. If ExecGetInsertedCols(), ExecGetUpdatedCols() or ExecGetExtraUpdatedCols() were called with a ResultRelInfo that's not in the range table and isn't a partition routing target, the functions would dereference a NULL pointer,

pgsql: Make ExecGetInsertedCols() and friends more robust and improve c

2021-02-14 Thread Heikki Linnakangas
Make ExecGetInsertedCols() and friends more robust and improve comments. If ExecGetInsertedCols(), ExecGetUpdatedCols() or ExecGetExtraUpdatedCols() were called with a ResultRelInfo that's not in the range table and isn't a partition routing target, the functions would dereference a NULL pointer,

pgsql: Display the time when the process started waiting for the lock,

2021-02-14 Thread Fujii Masao
Display the time when the process started waiting for the lock, in pg_locks, take 2 This commit adds new column "waitstart" into pg_locks view. This column reports the time when the server process started waiting for the lock if the lock is not held. This information is useful, for example, when

Re: pgsql: Add functions to 'pageinspect' to inspect GiST indexes.

2021-02-14 Thread Peter Geoghegan
On Thu, Feb 11, 2021 at 9:22 PM Andrey Borodin wrote: > Thanks, Peter! I agree that taking PageGetMaxOffsetNumber() seems > incorrect for deleted page, because we set pd_lower for the deleted page. > Also, there was an idea to add a column for LP_DEAD. > As long as we are dealing with deleted data

pgsql: Add "LP_DEAD item?" column to GiST pageinspect functions

2021-02-14 Thread Peter Geoghegan
Add "LP_DEAD item?" column to GiST pageinspect functions This brings gist_page_items() and gist_page_items_bytea() in line with nbtree's bt_page_items() function. Minor follow-up to commit 756ab291, which added the GiST functions. Author: Andrey Borodin Discussion: https://postgr.es/m/e0794687

pgsql: Avoid misinterpreting GiST pages in pageinspect.

2021-02-14 Thread Peter Geoghegan
Avoid misinterpreting GiST pages in pageinspect. GistPageSetDeleted() sets pd_lower when deleting a page, and sets the page contents to a GISTDeletedPageContents. Avoid treating deleted GiST pages as regular slotted pages within pageinspect. Oversight in commit 756ab291. Author: Andrey Borodin

pgsql: Adjust lazy_scan_heap() accounting comments.

2021-02-14 Thread Peter Geoghegan
Adjust lazy_scan_heap() accounting comments. Explain which particular LP_DEAD line pointers get accounted for by the tups_vacuumed variable. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7cde6b13a9b630e2f04d91e2f17dedc2afee21c6 Modified Files -- src/b

pgsql: Default to wal_sync_method=fdatasync on FreeBSD.

2021-02-14 Thread Thomas Munro
Default to wal_sync_method=fdatasync on FreeBSD. FreeBSD 13 gained O_DSYNC, which would normally cause wal_sync_method to choose open_datasync as its default value. That may not be a good choice for all systems, and performs worse than fdatasync in some scenarios. Let's preserve the existing def

pgsql: Default to wal_sync_method=fdatasync on FreeBSD.

2021-02-14 Thread Thomas Munro
Default to wal_sync_method=fdatasync on FreeBSD. FreeBSD 13 gained O_DSYNC, which would normally cause wal_sync_method to choose open_datasync as its default value. That may not be a good choice for all systems, and performs worse than fdatasync in some scenarios. Let's preserve the existing def

pgsql: Default to wal_sync_method=fdatasync on FreeBSD.

2021-02-14 Thread Thomas Munro
Default to wal_sync_method=fdatasync on FreeBSD. FreeBSD 13 gained O_DSYNC, which would normally cause wal_sync_method to choose open_datasync as its default value. That may not be a good choice for all systems, and performs worse than fdatasync in some scenarios. Let's preserve the existing def

pgsql: Default to wal_sync_method=fdatasync on FreeBSD.

2021-02-14 Thread Thomas Munro
Default to wal_sync_method=fdatasync on FreeBSD. FreeBSD 13 gained O_DSYNC, which would normally cause wal_sync_method to choose open_datasync as its default value. That may not be a good choice for all systems, and performs worse than fdatasync in some scenarios. Let's preserve the existing def

pgsql: Default to wal_sync_method=fdatasync on FreeBSD.

2021-02-14 Thread Thomas Munro
Default to wal_sync_method=fdatasync on FreeBSD. FreeBSD 13 gained O_DSYNC, which would normally cause wal_sync_method to choose open_datasync as its default value. That may not be a good choice for all systems, and performs worse than fdatasync in some scenarios. Let's preserve the existing def

pgsql: Default to wal_sync_method=fdatasync on FreeBSD.

2021-02-14 Thread Thomas Munro
Default to wal_sync_method=fdatasync on FreeBSD. FreeBSD 13 gained O_DSYNC, which would normally cause wal_sync_method to choose open_datasync as its default value. That may not be a good choice for all systems, and performs worse than fdatasync in some scenarios. Let's preserve the existing def

pgsql: Use pg_pwrite() in pg_test_fsync.

2021-02-14 Thread Thomas Munro
Use pg_pwrite() in pg_test_fsync. For consistency with the PostgreSQL behavior this test program is intended to simulate, use pwrite() instead of lseek() + write(). Also fix the final "non-sync" test, which was opening and closing the file for every write. Discussion: https://postgr.es/m/CA%2Bh

pgsql: Fix the warnings introduced in commit ce0fdbfe97.

2021-02-14 Thread Amit Kapila
Fix the warnings introduced in commit ce0fdbfe97. Author: Amit Kapila Reviewed-by: Tom Lane Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d9b0767becf5f41e4f001d8381e6a89941efa5b2 Modified Files

pgsql: Hold interrupts while running dsm_detach() callbacks.

2021-02-14 Thread Thomas Munro
Hold interrupts while running dsm_detach() callbacks. While cleaning up after a parallel query or parallel index creation that created temporary files, we could be interrupted by a statement timeout. The error handling path would then fail to clean up the files when it ran dsm_detach() again, beca

pgsql: Hold interrupts while running dsm_detach() callbacks.

2021-02-14 Thread Thomas Munro
Hold interrupts while running dsm_detach() callbacks. While cleaning up after a parallel query or parallel index creation that created temporary files, we could be interrupted by a statement timeout. The error handling path would then fail to clean up the files when it ran dsm_detach() again, beca

pgsql: Hold interrupts while running dsm_detach() callbacks.

2021-02-14 Thread Thomas Munro
Hold interrupts while running dsm_detach() callbacks. While cleaning up after a parallel query or parallel index creation that created temporary files, we could be interrupted by a statement timeout. The error handling path would then fail to clean up the files when it ran dsm_detach() again, beca

pgsql: Hold interrupts while running dsm_detach() callbacks.

2021-02-14 Thread Thomas Munro
Hold interrupts while running dsm_detach() callbacks. While cleaning up after a parallel query or parallel index creation that created temporary files, we could be interrupted by a statement timeout. The error handling path would then fail to clean up the files when it ran dsm_detach() again, beca

pgsql: Hold interrupts while running dsm_detach() callbacks.

2021-02-14 Thread Thomas Munro
Hold interrupts while running dsm_detach() callbacks. While cleaning up after a parallel query or parallel index creation that created temporary files, we could be interrupted by a statement timeout. The error handling path would then fail to clean up the files when it ran dsm_detach() again, beca

pgsql: Hold interrupts while running dsm_detach() callbacks.

2021-02-14 Thread Thomas Munro
Hold interrupts while running dsm_detach() callbacks. While cleaning up after a parallel query or parallel index creation that created temporary files, we could be interrupted by a statement timeout. The error handling path would then fail to clean up the files when it ran dsm_detach() again, beca

pgsql: Add result size as argument of pg_cryptohash_final() for overflo

2021-02-14 Thread Michael Paquier
Add result size as argument of pg_cryptohash_final() for overflow checks With its current design, a careless use of pg_cryptohash_final() could would result in an out-of-bound write in memory as the size of the destination buffer to store the result digest is not known to the cryptohash internals,

pgsql: Minor fixes to improve regex debugging code.

2021-02-14 Thread Tom Lane
Minor fixes to improve regex debugging code. When REG_DEBUG is defined, ensure that an un-filled "struct cnfa" is all-zeroes, not just that it has nstates == 0. This is mainly so that looking at "struct subre" structs in gdb doesn't distract one with a lot of garbage fields during regex compilati

pgsql: ReadNewTransactionId() -> ReadNextTransactionId().

2021-02-14 Thread Thomas Munro
ReadNewTransactionId() -> ReadNextTransactionId(). The new name conveys the effect better, is more consistent with similar functions ReadNextMultiXactId(), ReadNextFullTransactionId(), and matches the name of the variable that it reads. Reported-by: Peter Geoghegan Discussion: https://postgr.es