Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

> On 19 Apr 2024, at 07:37, Michael Paquier wrote: > > On Thu, Apr 18, 2024 at 12:53:43PM +0200, Peter Eisentraut wrote: >> If everything is addressed, I agree that 0001, 0003, and 0004 can go into >> PG17, the rest later. > > About the PG17 bits, would you agree about a backpatch? Or perhaps >

Re: Can't find not null constraint, but \d+ shows that

Alvaro Herrera 于2024年4月19日周五 02:49写道： > On 2024-Apr-13, jian he wrote: > > > I wonder is there any incompatibility issue, or do we need to say > something > > about the new behavior when dropping a key column? > > Umm, yeah, maybe we should document it in ALTER TABLE DROP PRIMARY KEY > and in the

Re: promotion related handling in pg_sync_replication_slots()

On Fri, Apr 19, 2024 at 10:53 AM Bertrand Drouvot wrote: > > Hi, > > On Thu, Apr 18, 2024 at 05:36:05PM +0530, shveta malik wrote: > > Please find v8 attached. Changes are: > > Thanks! > > A few comments: Thanks for reviewing. > 1 === > > @@ -1440,7 +1461,7 @@ ReplSlotSyncWorkerMain(char *startu

Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

On Thu, Apr 18, 2024 at 12:53:43PM +0200, Peter Eisentraut wrote: > If everything is addressed, I agree that 0001, 0003, and 0004 can go into > PG17, the rest later. About the PG17 bits, would you agree about a backpatch? Or perhaps you disagree? -- Michael signature.asc Description: PGP signat

Re: WIP Incremental JSON Parser

On Thu, Apr 18, 2024 at 06:03:45AM -0400, Andrew Dunstan wrote: > On 2024-04-18 Th 02:04, Michael Paquier wrote: >> Why usingFile::Temp::tempfile here? Couldn't you just use a >> file in a PostgreSQL::Test::Utils::tempdir() that would be cleaned up >> once the test finishes? > > That's another

Re: Cannot find a working 64-bit integer type on Illumos

On Fri, 19 Apr 2024 at 05:22, Thomas Munro wrote: > On Thu, Apr 18, 2024 at 6:09 PM Japin Li wrote: >> /home/japin/postgres/build/../src/include/lib/simplehash.h:1138:9: error: >> format '%llu' expects argument of type 'long long unsigned int', but >> argument 4 has type 'uint64' {aka 'long u

Re: promotion related handling in pg_sync_replication_slots()

Hi, On Thu, Apr 18, 2024 at 05:36:05PM +0530, shveta malik wrote: > Please find v8 attached. Changes are: Thanks! A few comments: 1 === @@ -1440,7 +1461,7 @@ ReplSlotSyncWorkerMain(char *startup_data, size_t startup_data_len) * slotsync_worker_onexit() but that will need the connecti

Direct SSL connection with ALPN and HBA rules

Hi all, (Heikki in CC.) Since 91044ae4baea (require ALPN for direct SSL connections) and d39a49c1e459 (direct hanshake), direct SSL connections are supported (yeah!), still the thread where this has been discussed does not cover the potential impact on HBA rules: https://www.postgresql.org/message

Re: cfbot is failing all tests on FreeBSD/Meson builds

On Fri, Apr 19, 2024 at 10:36 AM Thomas Munro wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276535 > > So perhaps it's time for me to undo what I did before... looking now. It turned out that I still needed the previous work-around, but I was too clever for my own boots last time.

Re: Allow tests to pass in OpenSSL FIPS mode

On Fri, Apr 19, 2024 at 4:00 PM Tom Lane wrote: > Thomas Munro writes: > > Probably not this thread's fault, but following the breadcrumbs to the > > last thread to touch the relevant test lines in > > authentication/001_password, is it expected that we have these > > warnings? > > > psql::1: WAR

Re: Allow tests to pass in OpenSSL FIPS mode

Thomas Munro writes: > Probably not this thread's fault, but following the breadcrumbs to the > last thread to touch the relevant test lines in > authentication/001_password, is it expected that we have these > warnings? > psql::1: WARNING: roles created by regression test cases > should have na

Re: ECPG cleanup and fix for clang compile-time problem

Andres Freund writes: > On 2024-04-18 23:11:52 -0400, Tom Lane wrote: >> I was just looking locally at what I got by removing that, and sadly >> I don't think I believe it: there are a lot of places where it claims >> we hit lines we don't, and vice versa. That might be partially >> blamable on o

Re: Allow tests to pass in OpenSSL FIPS mode

On Sat, Nov 18, 2023 at 7:46 AM Peter Eisentraut wrote: > All done, thanks. Probably not this thread's fault, but following the breadcrumbs to the last thread to touch the relevant test lines in authentication/001_password, is it expected that we have these warnings? psql::1: WARNING: roles cre

Use XLOG_CONTROL_FILE macro everywhere?

Hello! There is a macro XLOG_CONTROL_FILE for control file name defined in access/xlog_internal.h And there are some places in code where this macro is used like here https://github.com/postgres/postgres/blob/84db9a0eb10dd1dbee6db509c0e427fa237177dc/src/bin/pg_resetwal/pg_resetwal.c#L588 or here

Re: ECPG cleanup and fix for clang compile-time problem

On 2024-04-18 23:11:52 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2024-04-18 22:18:34 -0400, Tom Lane wrote: > >> (If our code coverage tools worked on bison/flex stuff, > >> maybe this'd be less scary ... but they don't.) > > > For bison coverage seems to work, see e.g.: > > Yeah, I'd

Re: ECPG cleanup and fix for clang compile-time problem

Andres Freund writes: > On 2024-04-18 22:18:34 -0400, Tom Lane wrote: >> (If our code coverage tools worked on bison/flex stuff, >> maybe this'd be less scary ... but they don't.) > For bison coverage seems to work, see e.g.: Yeah, I'd just noticed that --- I had it in my head that we'd put LCOV

Re: ECPG cleanup and fix for clang compile-time problem

Hi, On 2024-04-18 22:18:34 -0400, Tom Lane wrote: > Here is a patch series that aims to clean up ecpg's preprocessor > code a little and fix the compile time problems we're seeing with > late-model clang [1]. I guess whether it's a cleanup is in the eye of > the beholder, but it definitely succee

RE: Disallow changing slot's failover option in transaction block

Dear Hou, Thanks for updating the patch! Let me confirm the content. In your patch, the pg_dump.c was updated. IIUC the main reason was that pg_restore executes some queries as single transactions so that ALTER SUBSCRIPTION cannot be done, right? Also, failover was synchronized only when we were

Re: Speed up clean meson builds by ~25%

Andres Freund writes: > On 2024-04-17 23:10:53 -0400, Tom Lane wrote: >> I think we should hold off on this. I found a simpler way to address >> ecpg's problem than what I sketched upthread. I have a not-ready-to- >> show-yet patch that allows the vast majority of ecpg's grammar >> productions t

RE: Disallow changing slot's failover option in transaction block

Dear Shveta, > When I said that option 2 aligns with ALTER-SUB documented behaviour, > I meant the doc described in [1] stating "When altering the slot_name, > the failover and two_phase property values of the named slot may > differ from the counterpart failover and two_phase parameters > specifi

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

On Thu, Apr 18, 2024 at 06:17:56PM +0200, Alvaro Herrera wrote: > On 2024-Apr-18, Michael Paquier wrote: >> I was also worrying about a need to dump the protocol version to be >> able to track the relkind in the toc entries, but a45c78e3284b has >> already done one. The difference in AM handling b

Re: documentation structure

> > Yeah, we can't expect everyone wanting to call a built-in function to > know how they would define an equivalent one themselves. In that case I > propos marking it up like this: > > format ( > formatstr text > , formatarg "any" > , ... ) > text > Looks good, but I guess I

Re: AIX support

On Fri, Apr 19, 2024 at 6:01 AM Andres Freund wrote: > On 2024-04-18 11:15:43 +, Sriram RK wrote: > > We (IBM-AIX team) looked into this issue > > > > https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com > > > > This is related to the compiler issue. The compilers xlc(13.1)

RE: Disallow changing slot's failover option in transaction block

On Thursday, April 18, 2024 1:52 PM Amit Kapila wrote: > > On Tue, Apr 16, 2024 at 5:06 PM shveta malik > wrote: > > > > On Tue, Apr 16, 2024 at 1:45 PM Hayato Kuroda (Fujitsu) > > wrote: > > > > > > Dear Hou, > > > > > > > Kuroda-San reported an issue off-list that: > > > > > > > > If user exe

Re: pg_combinebackup does not detect missing files

On 4/19/24 00:50, Robert Haas wrote: On Wed, Apr 17, 2024 at 7:09 PM David Steele wrote: Fair enough. I accept that your reasoning is not random, but I'm still not very satisfied that the user needs to run a separate and rather expensive process to do the verification when pg_combinebackup alr

Re: Disallow changing slot's failover option in transaction block

On Thu, Apr 18, 2024 at 11:22:24AM +0530, Amit Kapila wrote: > +1 for option 2 as it sounds logical to me and consistent with ALTER > SUBSCRIPTION. BTW, IIUC, you are referring to: "When altering the > slot_name, the failover and two_phase property values of the named > slot may differ from the cou

Re: Support a wildcard in backtrace_functions

On Thu, Apr 18, 2024 at 12:21:56PM +0200, Jelte Fennema-Nio wrote: > On Thu, 18 Apr 2024 at 09:02, Michael Paquier wrote: >> On Fri, Apr 12, 2024 at 09:36:36AM +0900, Michael Paquier wrote: >> log_backtrace speaks a bit more to me as a name for this stuff because >> it logs a backtrace. Now, ther

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi! 18.04.2024 19:00, Alexander Lakhin wrote: leaves a strange constraint: \d+ t*   Table "public.tp_0" ... Not-null constraints:     "merge-16385-26BCB0-tmp_i_not_null" NOT NULL "i" Thanks! Attached fix (with test) for this case. The patch should be a

Re: pg_combinebackup fails on file named INCREMENTAL.*

On 4/19/24 01:10, Robert Haas wrote: On Wed, Apr 17, 2024 at 7:56 PM David Steele wrote: Thanks! I've tested this and it works as advertised. Ideally I'd want an error on backup if there is a similar file in any data directories that would cause an error on combine, but I admit that it is vani

Re: plenty code is confused about function level static

On Thu, Apr 18, 2024 at 07:56:35PM +0200, Peter Eisentraut wrote: > On 18.04.24 19:11, Andres Freund wrote: >> Thoughts about when to apply these? Arguably they're fixing mildly broken >> code, making it appropriate to fix in 17, but it's also something that we >> could end up fixing for a while...

Re: cfbot is failing all tests on FreeBSD/Meson builds

On Thu, Feb 8, 2024 at 3:53 PM Tom Lane wrote: > Thomas Munro writes: > > On Tue, Jan 30, 2024 at 5:06 PM Tom Lane wrote: > >> Thomas Munro writes: > >>> Ahh, there is one: https://github.com/cpan-authors/IO-Tty/issues/38 > > >> Just for the archives' sake: I hit this today on a fresh install >

Re: Solaris tar issues, or other reason why margay fails 010_pg_basebackup?

On Fri, Apr 19, 2024 at 12:57 AM Marcel Hofstetter wrote: > SKIP_READLINE_TESTS works. margay is now green again. Great! FTR there was a third thing revealed by margay since you enabled the TAP tests: commit e2a23576. I would guess that the best chance of getting the readline stuff to actually

Re: Popcount optimization using AVX512

On Thu, Apr 18, 2024 at 10:11:08PM +, Devulapalli, Raghuveer wrote: >> On that note, is it necessary to also check for avx512f? At the moment, >> we are assuming that's supported if the other AVX-512 instructions are >> available. > > No, it's not needed. There are no CPU's with avx512bw/avx5

Re: brininsert optimization opportunity

Hi, Here's two patched to deal with this open item. 0001 is a trivial fix of typos and wording, I moved it into a separate commit for clarity. 0002 does the actual fix - adding the index_insert_cleanup(). It's 99% the patch Alvaro shared some time ago, with only some minor formatting tweaks by me.

RE: Popcount optimization using AVX512

> On that note, is it necessary to also check for avx512f? At the moment, we > are assuming that's supported if the other AVX-512 instructions are available. No, it's not needed. There are no CPU's with avx512bw/avx512popcnt without avx512f. Unfortunately though, avx512popcnt does not mean avx

Re: Popcount optimization using AVX512

On Thu, Apr 18, 2024 at 09:29:55PM +, Devulapalli, Raghuveer wrote: > (1) Shouldn't it be: return (_xgetbv(0) & 0xe6) == 0xe6; ? Otherwise > zmm_regs_available() will return false.. Yes, that's a mistake. I fixed that in v3. > (2) Nitpick: avx512_popcnt_available and avx512_bw_available() ru

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 18 Apr 2024 at 23:36, Jelte Fennema-Nio wrote: > To clarify: My proposed approach is to use a protocol extension > parameter for to enable the new messages that the server can send > (like Peter is doing now). And **in addition to that** gate the new > Bind format type behind a feature swi

Re: Idea Feedback: psql \h misses -> Offers Links?

Kirk Wolak writes: > On Thu, Apr 18, 2024 at 2:37 PM Peter Eisentraut > wrote: > >> On 17.04.24 19:47, Kirk Wolak wrote: >> > *Example:* >> > \h current_setting >> > No help available for "current_setting". >> > Try \h with no arguments to see available help. >> > >> > https://www.postgresql.org

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 18 Apr 2024 at 22:17, Robert Haas wrote: > If we go with Peter's approach, every driver that supports his feature > will work perfectly, and every driver that doesn't will work exactly > as it does today. The risk of breaking anything is as near to zero as > human developers can reasonably

Re: documentation structure

Corey Huinker writes: >> >> I havent dealt with variadic yet, since the two styles are visually >> different, not just markup (... renders as [...]). >> >> The two styles for variadic are the what I call caller-style: >> >>concat ( val1 "any" [, val2 "any" [, ...] ] ) >>format(formatstr t

RE: Popcount optimization using AVX512

> Thanks for the feedback. I've attached an updated patch. (1) Shouldn't it be: return (_xgetbv(0) & 0xe6) == 0xe6; ? Otherwise zmm_regs_available() will return false. (2) Nitpick: avx512_popcnt_available and avx512_bw_available() run the same cpuid leaf. You could combine them into one to avo

Re: Idea Feedback: psql \h misses -> Offers Links?

On Thu, Apr 18, 2024 at 2:37 PM Peter Eisentraut wrote: > On 17.04.24 19:47, Kirk Wolak wrote: > > *Example:* > > \h current_setting > > No help available for "current_setting". > > Try \h with no arguments to see available help. > > > > https://www.postgresql.org/search/?u=%2Fdocs%2F16%2F&q=curr

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, Apr 18, 2024 at 6:09 PM Japin Li wrote: > /home/japin/postgres/build/../src/common/config_info.c:198:11: error: > comparison of integer expressions of different signedness: 'int' and 'size_t' > {aka 'long unsigned int'} [-Werror=sign-compare] > 198 | Assert(i == *configdata_len); Rig

Re: improve performance of pg_dump --binary-upgrade

On Thu, Apr 18, 2024 at 10:33:08PM +0200, Daniel Gustafsson wrote: > From a read-through they look good, a very nice performance improvement in an > important path. I think it would be nice with some comments on the > BinaryUpgradeClassOids struct (since the code using it is thousands of lines > a

Re: Popcount optimization using AVX512

On Thu, Apr 18, 2024 at 08:24:03PM +, Devulapalli, Raghuveer wrote: >> This seems to contradict the note about doing step 3 at any point, and >> given step 1 is the OSXSAVE check, I'm not following what this means, >> anyway. > > It is recommended that you run the xgetbv code before you check

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, Apr 18, 2024 at 8:47 PM Peter Eisentraut wrote: > Maybe this means something like our int64 is long long int but the > system's int64_t is long int underneath, but I don't see how that would > matter for the limit macros. Agreed, so I don't think it's long vs long long (when they have the

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Here are some additional fixes to docs. >From 6da8beaa5a2b78e785e5b6519894f8357002d916 Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Thu, 18 Apr 2024 15:40:44 -0500 Subject: [PATCH] doc review for ALTER TABLE ... SPLIT/MERGE PARTITION --- doc/src/sgml/ddl.sgml | 4 ++-- doc/src

Re: improve performance of pg_dump --binary-upgrade

> On 18 Apr 2024, at 22:28, Nathan Bossart wrote: > > On Thu, Apr 18, 2024 at 10:23:01AM -0500, Nathan Bossart wrote: >> On Thu, Apr 18, 2024 at 09:24:53AM +0200, Daniel Gustafsson wrote: >>> That does indeed seem like a saner approach. Since we look up the relkind >>> we >>> can also remove th

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, Apr 18, 2024 at 8:47 PM Peter Eisentraut wrote: > I'm not sure I understand the problem here. Do you mean that in theory > a platform's PRId64 could be something other than "l" or "ll"? Yes. I don't know why anyone would do that, and the systems I checked all have the obvious definition

Re: improve performance of pg_dump --binary-upgrade

On Thu, Apr 18, 2024 at 10:23:01AM -0500, Nathan Bossart wrote: > On Thu, Apr 18, 2024 at 09:24:53AM +0200, Daniel Gustafsson wrote: >> That does indeed seem like a saner approach. Since we look up the relkind we >> can also remove the is_index parameter to binary_upgrade_set_pg_class_oids >> sinc

Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

> On 18 Apr 2024, at 12:53, Peter Eisentraut wrote: > Review of the latest batch: Thanks for reviewing! > 8 v9-0002-Remove-support-for-OpenSSL-1.0.2.patch > > Ok, but maybe make the punctuation consistent here: Fixed. > * v9-0004-Support-SSL_R_VERSION_TOO_LOW-on-LibreSSL.patch > > Seems ok,

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, Apr 18, 2024 at 3:34 PM Jelte Fennema-Nio wrote: > I really don't understand what exactly you're worried about. What do > you expect will break when bumping the protocol version? As Dave said, > clients should never bail out due to protocol version differences. Sure, and I should never fo

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

On Thu, Dec 14, 2017 at 08:51:06AM +0700, Ali Akbar wrote: > Patch for adding check in pg_upgrade. [...] On Fri, Sep 29, 2023 at 11:36:42AM -0500, Justin Pryzby wrote: > On Fri, Sep 29, 2023 at 09:16:35AM +0900, Michael Paquier wrote: > > You mean when upgrading from an instance of 9.6 or older a

Re: cataloguing NOT NULL constraints

Hello Alvaro, 18.04.2024 16:39, Alvaro Herrera wrote: I have pushed a fix which should hopefully fix this problem (d9f686a72e). Please give this a look. Thanks for reporting the issue. Please look at an assertion failure, introduced with d9f686a72: CREATE TABLE t(a int, NOT NULL a NO INHERIT

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Thu, Apr 18, 2024 at 6:35 AM Alexander Korotkov wrote: > The revised patchset is attached. > 1) I've split the fix for the CommandCounterIncrement() issue and the > fix for relation persistence issue into a separate patch. > 2) I've validated that the lock on the new partition is held in > crea

Re: Popcount optimization using AVX512

On Thu, Apr 18, 2024 at 06:12:22PM +, Shankaran, Akash wrote: > Good find. I confirmed after speaking with an intel expert, and from the > intel AVX-512 manual [0] section 14.3, which recommends to check bit27. From > the manual: > > "Prior to using Intel AVX, the application must identify t

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, 15 Apr 2024 at 21:47, Dave Cramer wrote: >> On Mon, 15 Apr 2024 at 19:52, Robert Haas wrote: >> > surely it can't be right to use protocol >> > version 3.0 to refer to a bunch of different things. But at the same >> > time, surely we don't want clients to start panicking and bailing out >

Re: Add notes to pg_combinebackup docs

On Thu, Apr 18, 2024 at 3:25 PM Daniel Gustafsson wrote: > I don't think this is the way to go, such an option will be plastered on to > helpful tutorials which users will copy/paste from even when they don't need > the option at all, only to disable checksums when there was no reason for > doing

Re: Add notes to pg_combinebackup docs

> On 18 Apr 2024, at 20:11, Robert Haas wrote: > 2. As (1), but make check_control_files() emit a warning message when > the problem case is detected. Being in the post-freeze part of the cycle, this seems like the best option. > 3. As (2), but also add a command-line option to pg_combinebackup

Re: [18] clarify the difference between pg_wchar, wchar_t, and Unicode code points

On 16.04.24 01:40, Jeff Davis wrote: I'm not sure I understand all of the history behind pg_wchar, but it seems to be some blend of: (a) Postgres's own internal representation of a decoded character (b) libc's wchar_t (c) Unicode code point For example, Postgres has its own encoding/de

Re: pgsql: Fix restore of not-null constraints with inheritance

On 2024-04-18 Th 11:39, Alvaro Herrera wrote: On 2024-Apr-18, Alvaro Herrera wrote: On 2024-Apr-18, Alvaro Herrera wrote: Lastly, make two changes to pg_dump: 1) do not try to drop a not-null constraint that's marked as inherited; this allows a dump to restore with no errors if a table with

Re: Transparent column encryption

On Thu, Apr 18, 2024 at 1:49 PM Jelte Fennema-Nio wrote: > I think this is an interesting idea. I can indeed see use cases for > e.g. inserting a new row based on another row (where the secret is the > same). > > IMHO that means that we should also bump the protocol version for this > change, beca

Re: Can't find not null constraint, but \d+ shows that

On 2024-Apr-13, jian he wrote: > I wonder is there any incompatibility issue, or do we need to say something > about the new behavior when dropping a key column? Umm, yeah, maybe we should document it in ALTER TABLE DROP PRIMARY KEY and in the release notes to note the different behavior. > only

Re: fix tablespace handling in pg_combinebackup

On Thu, Apr 18, 2024 at 1:45 PM Andres Freund wrote: > I was really just remarking on this from the angle of a test writer. I know > that our interfaces around this suck... > > For tests, do we really need to set anything on a per-tablespace basis? Can't > we instead just reparent all of them to a

Re: Idea Feedback: psql \h misses -> Offers Links?

On 17.04.24 19:47, Kirk Wolak wrote: *Example:* \h current_setting No help available for "current_setting". Try \h with no arguments to see available help. https://www.postgresql.org/search/?u=%2Fdocs%2F16%2F&q=current_setting

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [ NOT Fixed ]

On Thu, Feb 22, 2024 at 4:49 PM Michael Banck wrote: > Hi, > > On Wed, Jan 24, 2024 at 02:50:52PM -0500, Kirk Wolak wrote: > > On Mon, Jan 22, 2024 at 1:30 AM Kirk Wolak wrote: > > > On Fri, Jan 19, 2024 at 7:03 PM Daniel Gustafsson > wrote: > > >> > On 19 Jan 2024, at 23:09, Kirk Wolak wrote:

RE: Popcount optimization using AVX512

> It was brought to my attention [0] that we probably should be checking for > the OSXSAVE bit instead of the XSAVE bit when determining whether there's > support for the XGETBV instruction. IIUC that should indicate that both the > OS and the processor have XGETBV support (not just the process

Re: Add notes to pg_combinebackup docs

On Tue, Apr 9, 2024 at 5:46 AM Tomas Vondra wrote: > What we could do is detect this in pg_combinebackup, and either just > disable checksums with a warning and hint to maybe enable them again. Or > maybe just print that the user needs to disable them. > > I was thinking maybe we could detect this

Re: AIX support

Hi, On 2024-04-18 11:15:43 +, Sriram RK wrote: > We (IBM-AIX team) looked into this issue > > https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com > > This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0) > have issues. But we verified that this issue

Re: plenty code is confused about function level static

On 18.04.24 19:11, Andres Freund wrote: Thoughts about when to apply these? Arguably they're fixing mildly broken code, making it appropriate to fix in 17, but it's also something that we could end up fixing for a while... Yeah, let's keep these for later. They are not regressions, and there

Re: documentation structure

> > I havent dealt with variadic yet, since the two styles are visually > different, not just markup (... renders as [...]). > > The two styles for variadic are the what I call caller-style: > >concat ( val1 "any" [, val2 "any" [, ...] ] ) >format(formatstr text [, formatarg "any" [, ...] ]

Re: Transparent column encryption

On Thu, 18 Apr 2024 at 18:46, Robert Haas wrote: > With regard to the Bind message, I suggest that we regard the protocol > change as reserving a currently-unused bit in the message to indicate > whether the value is pre-encrypted, without reference to the protocol > extension. It could be legal f

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On 2024-Apr-18, Alexander Lakhin wrote: > I think the feature implementation should also provide tab completion > for SPLIT/MERGE. I don't think that we should be imposing on feature authors or committers the task of filling in tab-completion for whatever features they contribute. I mean, if the

Re: fix tablespace handling in pg_combinebackup

Hi, On 2024-04-18 09:03:21 -0400, Robert Haas wrote: > On Wed, Apr 17, 2024 at 5:50 PM Andres Freund wrote: > > > +If there are tablespace present in the backup, include tablespace_map as > > > +a keyword parameter whose values is a hash. When tar_program is used, the > > > +hash keys are tablesp

Re: plenty code is confused about function level static

Em qui., 18 de abr. de 2024 às 14:16, Andres Freund escreveu: > Hi, > > On 2024-04-18 09:07:43 -0300, Ranier Vilela wrote: > > On 18/04/2024 00:39, Andres Freund wrote: > > >There are lots of places that could benefit from adding 'static > > >const'. > > > > I found a few more places. > > Good c

Re: plenty code is confused about function level static

Hi, On 2024-04-18 09:07:43 -0300, Ranier Vilela wrote: > On 18/04/2024 00:39, Andres Freund wrote: > >There are lots of places that could benefit from adding 'static > >const'. > > I found a few more places. Good catches. > Patch 004 > > The opposite would also help, adding static. > In thes

Re: plenty code is confused about function level static

Hi, On 2024-04-18 10:33:30 +0200, Peter Eisentraut wrote: > > Attached are fixes for struct option and a few more occurrences I've found > > with a bit of grepping. > > These look good to me. Thoughts about when to apply these? Arguably they're fixing mildly broken code, making it appropriate to

Re: Add notes to pg_combinebackup docs

On Tue, Apr 9, 2024 at 4:00 AM Martín Marqués wrote: > I've attached two patches, the first one is just neat-picking things I > found when I first read the docs. I pushed a commit to remove the spurious "the" that you found, but I don't really agree with the other changes. They all seem grammatic

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Alexander Lakhin writes: > Hi Alexander, > > 18.04.2024 13:35, Alexander Korotkov wrote: >> >> The revised patchset is attached. >> 1) I've split the fix for the CommandCounterIncrement() issue and the >> fix for relation persistence issue into a separate patch. >> 2) I've validated that the lock

Re: pg17 issues with not-null contraints

On Thu, Apr 18, 2024 at 06:23:30PM +0200, Alvaro Herrera wrote: > On 2024-Apr-18, Justin Pryzby wrote: > > > BTW, this works up to v16 (although maybe it should not): > > > > | CREATE TABLE ip(id int PRIMARY KEY); CREATE TABLE ic(id int) INHERITS > > (ip); ALTER TABLE ic ALTER id DROP NOT NULL;

Re: Transparent column encryption

On Wed, Apr 10, 2024 at 6:13 AM Peter Eisentraut wrote: > Obviously, it's early days, so there will be plenty of time to have > discussions on various other aspects of this patch. I'm keeping a keen > eye on the discussion of protocol extensions, for example. I think the way that you handled tha

Re: Speed up clean meson builds by ~25%

On 2024-04-17 23:10:53 -0400, Tom Lane wrote: > Jelte Fennema-Nio writes: > > As I expected this problem was indeed fairly easy to address by still > > building "backend/parser" before "interfaces". See attached patch. > > I think we should hold off on this. I found a simpler way to address > ec

Re: pg17 issues with not-null contraints

On 2024-Apr-18, Justin Pryzby wrote: > That seems like it could be important. I considered but never actually > test your patch by pg_upgrading across major versions. It would be a welcome contribution for sure. I've been doing it rather haphazardly, which is not great. > BTW, this works up to

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

On 2024-Apr-18, Michael Paquier wrote: > On Wed, Apr 17, 2024 at 10:31:52AM +0200, Alvaro Herrera wrote: > > Hmm, maybe we should do a RESET of default_table_access_method before > > printing the CREATE TABLE to avoid the confusion. > > A hard reset would make the business around currTableAM tha

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi Alexander, 18.04.2024 13:35, Alexander Korotkov wrote: The revised patchset is attached. 1) I've split the fix for the CommandCounterIncrement() issue and the fix for relation persistence issue into a separate patch. 2) I've validated that the lock on the new partition is held in createParti

PostgreSQL 17 Beta 1 release date

Hi, PostgreSQL 17 Beta 1 is planned to be release on May 23, 2024. Please continue your hard work on closing out open items[1] ahead of the release and have the fixes targeted for the release committed by May 18, 2024. Thanks - it's very exciting that we're at this point in the release cycle

Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan

On Thu, Apr 18, 2024 at 2:13 AM Donghang Lin wrote: > It's triggered when a scankey's strategy is set to invalid. While for a > descending ordered column, > the strategy needs to get fixed to its commute strategy. That doesn't work if > the strategy is invalid. The problem is that _bt_fix_scank

Re: pgsql: Fix restore of not-null constraints with inheritance

On 2024-Apr-18, Alvaro Herrera wrote: > On 2024-Apr-18, Alvaro Herrera wrote: > > > Lastly, make two changes to pg_dump: 1) do not try to drop a not-null > > constraint that's marked as inherited; this allows a dump to restore > > with no errors if a table with a PK inherits from another which al

Re: Trigger violates foreign key constraint

Aleksander Alekseev writes: >> I agree with documenting this hazard, but I think it'd be better >> to do so in the "Triggers" chapter. There is no hazard unless >> you are writing user-defined triggers, which is surely far fewer >> people than use foreign keys. So I suggest something like the >>

Re: improve performance of pg_dump --binary-upgrade

On Thu, Apr 18, 2024 at 09:24:53AM +0200, Daniel Gustafsson wrote: >> On 18 Apr 2024, at 06:17, Nathan Bossart wrote: > >> The attached work-in-progress patch speeds up 'pg_dump --binary-upgrade' >> for this case. Instead of executing the query in every call to the >> function, we can execute it

Re: Transparent column encryption

On Thu, 18 Apr 2024 at 13:25, Peter Eisentraut wrote: > Hopefully, the reason for key rotation is mainly that policies require > key rotation, not that keys get compromised all the time. These key rotation policies are generally in place to reduce the impact of a key compromise by limiting the ti

Re: pg_combinebackup fails on file named INCREMENTAL.*

On Wed, Apr 17, 2024 at 7:56 PM David Steele wrote: > Thanks! I've tested this and it works as advertised. > > Ideally I'd want an error on backup if there is a similar file in any > data directories that would cause an error on combine, but I admit that > it is vanishingly rare for users to put f

Re: pg17 issues with not-null contraints

On Tue, Apr 16, 2024 at 08:11:49PM +0200, Alvaro Herrera wrote: > This is still missing some cleanup and additional tests, of course. > Speaking of which, I wonder if I should modify pg16's tests so that they > leave behind tables set up in this way, to immortalize pg_upgrade > testing. That seems

clang's sanitizer makes stringToNode() extremely slow

Hello hackers, When using a server built with clang (15, 18) with sanitizers enabled, the last query in the following script: SET parallel_setup_cost = 0; SET min_parallel_table_scan_size = 0; SELECT a::text INTO t FROM generate_series(1, 1000) a; \timing on SELECT string_agg(a, ',') FROM t WHER

Re: improve performance of pg_dump --binary-upgrade

On Thu, Apr 18, 2024 at 02:08:28AM -0400, Corey Huinker wrote: > Bar-napkin math tells me in a worst-case architecture and braindead byte > alignment, we'd burn 64 bytes per struct, so the 100K tables cited would be > about 6.25MB of memory. That doesn't seem too terrible. > The obvious low-memor

Re: pg_combinebackup does not detect missing files

On Wed, Apr 17, 2024 at 7:09 PM David Steele wrote: > I think here: > > + pg_basebackup only attempts to verify > > you mean: > > + pg_combinebackup only attempts to verify > > Otherwise this looks good to me. Good catch, thanks. Committed with that change. > Fair enough. I accept that your

Re: pg17 issues with not-null contraints

On 2024-Apr-15, Justin Pryzby wrote: > Here's a couple more issues affecting upgrades from v16 to v17. > > postgres=# CREATE TABLE a(i int NOT NULL); CREATE TABLE b(i int PRIMARY KEY) > INHERITS (a); > pg_restore: error: could not execute query: ERROR: constraint > "pgdump_throwaway_notnull_0"

Re: cataloguing NOT NULL constraints

On 2024-Jan-25, Andrew Bille wrote: > Starting from b0e96f31, pg_upgrade fails with inherited NOT NULL constraint: > For example upgrade from 9c13b6814a (or REL_12_STABLE .. REL_16_STABLE) to > b0e96f31 (or master) with following two tables (excerpt from > src/test/regress/sql/rules.sql) > > crea

Re: documentation structure

On Thu, Apr 18, 2024 at 2:37 AM Dagfinn Ilmari Mannsåker wrote: > > Andres Freund writes: > > > Hi, > > > > On 2024-04-17 12:07:24 +0100, Dagfinn Ilmari Mannsåker wrote: > >> Andres Freund writes: > >> > I think the manual work for writing signatures in sgml is not > >> > insignificant, > >> >

Re: fix tablespace handling in pg_combinebackup

On Wed, Apr 17, 2024 at 5:50 PM Andres Freund wrote: > > +If there are tablespace present in the backup, include tablespace_map as > > +a keyword parameter whose values is a hash. When tar_program is used, the > > +hash keys are tablespace OIDs; otherwise, they are the tablespace pathnames > > +us

  1   2   >