Re: pgsql: Improve error handling of cryptohash computations

On Fri, 2022-01-14 at 10:49 +0900, Michael Paquier wrote: > On Thu, Jan 13, 2022 at 02:52:12PM -0500, Tom Lane wrote: > > Probably none of this should have been back-patched --- the issues > > are not so large that they require a risk of breaking things in > > the back branches. > > Agreed,

pgsql: Revert error handling improvements for cryptohashes

Revert error handling improvements for cryptohashes This reverts commits ab27df2, af8d530 and 3a0cced, that introduced pg_cryptohash_error(). In order to make the core code able to pass down the new error types that this introduced, some of the MD5-related routines had to be reworked, causing an

pgsql: Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD w

Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD while pruning. Since dc7420c2c92 the horizon used for pruning is determined "lazily". A more accurate horizon is built on-demand, rather than in GetSnapshotData(). If a horizon computation is triggered between two

pgsql: Assert redirect pointers are sensible after heap_page_prune().

Assert redirect pointers are sensible after heap_page_prune(). Corruption of redirect item pointers often only becomes visible well after being corrupted, as e.g. bug #17255 shows: In the original reproducer, gigabyte of WAL were between the source of the corruption and the corruption becoming

Re: pgsql: Improve error handling of cryptohash computations

On Thu, Jan 13, 2022 at 02:52:12PM -0500, Tom Lane wrote: > Probably none of this should have been back-patched --- the issues > are not so large that they require a risk of breaking things in > the back branches. Agreed, that's not worth breaking things in v14, so I'll go and revert this stuff

pgsql: Fix ruleutils.c's dumping of whole-row Vars in more contexts.

Fix ruleutils.c's dumping of whole-row Vars in more contexts. Commit 7745bc352 intended to ensure that whole-row Vars would be printed with "::type" decoration in all contexts where plain "var.*" notation would result in star-expansion, notably in ROW() and VALUES() constructs. However, it

pgsql: Fix ruleutils.c's dumping of whole-row Vars in more contexts.

Fix ruleutils.c's dumping of whole-row Vars in more contexts. Commit 7745bc352 intended to ensure that whole-row Vars would be printed with "::type" decoration in all contexts where plain "var.*" notation would result in star-expansion, notably in ROW() and VALUES() constructs. However, it

pgsql: Fix ruleutils.c's dumping of whole-row Vars in more contexts.

Fix ruleutils.c's dumping of whole-row Vars in more contexts. Commit 7745bc352 intended to ensure that whole-row Vars would be printed with "::type" decoration in all contexts where plain "var.*" notation would result in star-expansion, notably in ROW() and VALUES() constructs. However, it

pgsql: Fix ruleutils.c's dumping of whole-row Vars in more contexts.

Fix ruleutils.c's dumping of whole-row Vars in more contexts. Commit 7745bc352 intended to ensure that whole-row Vars would be printed with "::type" decoration in all contexts where plain "var.*" notation would result in star-expansion, notably in ROW() and VALUES() constructs. However, it

pgsql: Fix ruleutils.c's dumping of whole-row Vars in more contexts.

Fix ruleutils.c's dumping of whole-row Vars in more contexts. Commit 7745bc352 intended to ensure that whole-row Vars would be printed with "::type" decoration in all contexts where plain "var.*" notation would result in star-expansion, notably in ROW() and VALUES() constructs. However, it

pgsql: Fix ruleutils.c's dumping of whole-row Vars in more contexts.

Fix ruleutils.c's dumping of whole-row Vars in more contexts. Commit 7745bc352 intended to ensure that whole-row Vars would be printed with "::type" decoration in all contexts where plain "var.*" notation would result in star-expansion, notably in ROW() and VALUES() constructs. However, it

Re: pgsql: Improve error handling of cryptohash computations

Laurenz Albe writes: > On Tue, 2022-01-11 at 00:56 +, Michael Paquier wrote: >> Improve error handling of cryptohash computations > This commit changes the signature of the exported "pg_md5_hash" function, > which breaks my extension that uses this function. > Is there no way to avoid this

pgsql: ci: windows: run initdb with --no-sync.

ci: windows: run initdb with --no-sync. Author: Justin Pryzby Discussion: https://postgr.es/m/20220110220748.gs14...@telsasoft.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dfc0cb3940cd4d1f19fcf6c7545dc6cc01c6c92c Modified Files -- .cirrus.yml |

pgsql: ci: windows: enable build summary to make it easier to spot warn

ci: windows: enable build summary to make it easier to spot warnings / errors. The build summary was disabled unintentionally by setting the build verbosity lower. While at it, also add ForceNoAlign to prevent msbuild from introducing linebreaks in the middle of filenames etc - they make it

Re: pgsql: Improve error handling of cryptohash computations

On Tue, 2022-01-11 at 00:56 +, Michael Paquier wrote: > Improve error handling of cryptohash computations This commit changes the signature of the exported "pg_md5_hash" function, which breaks my extension that uses this function. Is there no way to avoid this API break in the back branches?

Re: pgsql: Check for STATUS_DELETE_PENDING on Windows.

Andrew Dunstan writes: > Done See > > crake will now run this as part of its normal runs on HEAD. Great, thanks! regards, tom lane

Re: pgsql: Check for STATUS_DELETE_PENDING on Windows.

On 1/11/22 16:54, Tom Lane wrote: > Andrew Dunstan writes: >> On 1/11/22 16:22, Thomas Munro wrote: >>> Those scripts aren't really on my radar... would it be a good idea to >>> run them as steps in the CompilerWarnings CI task? >> Or in a buildfarm module (c.f. the perl checks) > +1 for one or

Re: pgsql: Include permissive/enforcing state in sepgsql log messages.

Simon Riggs writes: > Is that a bug fix to be backpatched, or a new/changed feature to be > documented? It'd be the latter, if sepgsql had any documentation about the content of its log messages. But AFAICS it doesn't (and I'm not volunteering to add that). regards,

Re: pgsql: Include permissive/enforcing state in sepgsql log messages.

On Wed, 12 Jan 2022 at 19:23, Tom Lane wrote: > > Include permissive/enforcing state in sepgsql log messages. > > SELinux itself does this (at least in modern releases), and it > seems like a good idea to reduce confusion. > > Dave Page > > Discussion: >