Re: pgsql: Add template for adaptive radix tree

On Fri, Mar 8, 2024 at 10:43 AM David Rowley wrote: > > On Fri, 8 Mar 2024 at 16:37, John Naylor wrote: > > Thanks, I was getting close to committing a hackish workaround -- this > > seems better! > > ok cool. I also noticed a typo. Maybe worth fixing that at the same time? > > Attached. Done,

pgsql: Revert "Fix link error for test_radixtree module on Windows"

Revert "Fix link error for test_radixtree module on Windows" This reverts commit 9552e3ace317ac8bb0a80613c0e5cd6536c96dc8. I (john) forgot to revert this locally when a more principled fix was found, which has the same message title. Branch -- master Details ---

pgsql: Fix link error for test_radixtree module on Windows

Fix link error for test_radixtree module on Windows Add PGDLLIMPORT to pg_popcount32/64. In passing, fix a typo. Diagnosis by Masahiko Sawada, patch by David Rowley Per buildfarm members drongo and fairywren Discussion:

pgsql: Fix link error for test_radixtree module on Windows

Fix link error for test_radixtree module on Windows Add back "link_with" directive, similar to the one removed by 1f1d73a8b, but only for Windows, but use the "_shlib" variation. Diagnosis by Masahiko Sawada, proposed fix adjusted and tested by me Per buildfarm members drongo and fairywren

Re: pgsql: Add template for adaptive radix tree

On Fri, 8 Mar 2024 at 16:37, John Naylor wrote: > Thanks, I was getting close to committing a hackish workaround -- this > seems better! ok cool. I also noticed a typo. Maybe worth fixing that at the same time? Attached. David diff --git a/src/test/modules/test_radixtree/test_radixtree.c

Re: pgsql: Add template for adaptive radix tree

On Fri, Mar 8, 2024 at 10:29 AM David Rowley wrote: > > On Fri, 8 Mar 2024 at 13:48, John Naylor wrote: > > Now, after I get some coffee I'll look into the Windows failures. > > I had a look at this and the attached fixes the broken build on MSVC for me. > > I didn't take the time to fully

Re: pgsql: Add template for adaptive radix tree

On Fri, 8 Mar 2024 at 13:48, John Naylor wrote: > Now, after I get some coffee I'll look into the Windows failures. I had a look at this and the attached fixes the broken build on MSVC for me. I didn't take the time to fully understand it, but I did also try PGDLLEXPORT and that *didn't* fix

pgsql: Introduce a new GUC 'standby_slot_names'.

Introduce a new GUC 'standby_slot_names'. This patch provides a way to ensure that physical standbys that are potential failover candidates have received and flushed changes before the primary server making them visible to subscribers. Doing so guarantees that the promoted standby server is not

Re: pgsql: Add template for adaptive radix tree

On Thu, Mar 7, 2024 at 4:47 PM John Naylor wrote: > > On Thu, Mar 7, 2024 at 4:36 PM Alvaro Herrera wrote: > > > > Well, surely we can email them. Their profiles show they're still > > active. > > https://db.in.tum.de/people/sites/kemper/?lang=en > >

pgsql: Cope with a deficiency in OpenSSL 3.x's error reporting.

Cope with a deficiency in OpenSSL 3.x's error reporting. In OpenSSL 3.0.0 and later, ERR_reason_error_string randomly refuses to provide a string for error codes representing system errno values (e.g., "No such file or directory"). There is a poorly-documented way to extract the errno from the

pgsql: Cope with a deficiency in OpenSSL 3.x's error reporting.

Cope with a deficiency in OpenSSL 3.x's error reporting. In OpenSSL 3.0.0 and later, ERR_reason_error_string randomly refuses to provide a string for error codes representing system errno values (e.g., "No such file or directory"). There is a poorly-documented way to extract the errno from the

pgsql: Cope with a deficiency in OpenSSL 3.x's error reporting.

Cope with a deficiency in OpenSSL 3.x's error reporting. In OpenSSL 3.0.0 and later, ERR_reason_error_string randomly refuses to provide a string for error codes representing system errno values (e.g., "No such file or directory"). There is a poorly-documented way to extract the errno from the

pgsql: Cope with a deficiency in OpenSSL 3.x's error reporting.

Cope with a deficiency in OpenSSL 3.x's error reporting. In OpenSSL 3.0.0 and later, ERR_reason_error_string randomly refuses to provide a string for error codes representing system errno values (e.g., "No such file or directory"). There is a poorly-documented way to extract the errno from the

pgsql: Cope with a deficiency in OpenSSL 3.x's error reporting.

Cope with a deficiency in OpenSSL 3.x's error reporting. In OpenSSL 3.0.0 and later, ERR_reason_error_string randomly refuses to provide a string for error codes representing system errno values (e.g., "No such file or directory"). There is a poorly-documented way to extract the errno from the

pgsql: Cope with a deficiency in OpenSSL 3.x's error reporting.

Cope with a deficiency in OpenSSL 3.x's error reporting. In OpenSSL 3.0.0 and later, ERR_reason_error_string randomly refuses to provide a string for error codes representing system errno values (e.g., "No such file or directory"). There is a poorly-documented way to extract the errno from the

pgsql: Add support for DEFAULT in ALTER TABLE .. SET ACCESS METHOD

Add support for DEFAULT in ALTER TABLE .. SET ACCESS METHOD This option can be used to switch a relation to use the access method set by default_table_access_method when running the command. This has come up when discussing the possibility to support setting pg_class.relam for partitioned tables

pgsql: Update comment of AlterTableCmd->name in parsenodes.h

Update comment of AlterTableCmd->name in parsenodes.h Since b0483263dda0, this field can be used to store an access method name for ALTER TABLE, but access methods were not mentioned in the field's description. Issue noticed while working on the area. Discussion:

pgsql: Unicode case mapping tables and functions.

Unicode case mapping tables and functions. Implements Unicode simple case mapping, in which all code points map to exactly one other code point unconditionally. These tables are generated from UnicodeData.txt, which is already being used by other infrastructure in src/common/unicode. The tables

Re: pgsql: Add template for adaptive radix tree

On 2024-03-07 Th 00:49, John Naylor wrote: Add template for adaptive radix tree drongo and fairywren don't like this, See e.g. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

pgsql: Fix description and grouping of RangeTblEntry.inh

Fix description and grouping of RangeTblEntry.inh The inh field of RangeTblEntry was doubly confusingly documented. Some parts of the code insisted that it was only valid for RTE_RELATION entries, other parts said the field was valid for all entries. Neither was quite correct. More correctly,

pgsql: Blind attempt to fix ODR violations

Blind attempt to fix ODR violations Remove apparently useless "link_with" directive. Even if this isn't the root cause, it makes the .build file more like the other test modules. Reviewed by Masahiko Sawada Follow-up to ee1b30f12, per buildfarm members olingo and grassquit. Discussion:

pgsql: Fix handling of self-modified tuples in MERGE.

Fix handling of self-modified tuples in MERGE. When an UPDATE or DELETE action in MERGE returns TM_SelfModified, there are 2 possible causes: 1). The target tuple was already updated or deleted by the current command. This can happen if the target row joins to more than one source row,

pgsql: Fix handling of self-modified tuples in MERGE.

Fix handling of self-modified tuples in MERGE. When an UPDATE or DELETE action in MERGE returns TM_SelfModified, there are 2 possible causes: 1). The target tuple was already updated or deleted by the current command. This can happen if the target row joins to more than one source row,

pgsql: Fix handling of self-modified tuples in MERGE.

Fix handling of self-modified tuples in MERGE. When an UPDATE or DELETE action in MERGE returns TM_SelfModified, there are 2 possible causes: 1). The target tuple was already updated or deleted by the current command. This can happen if the target row joins to more than one source row,

Re: pgsql: Add template for adaptive radix tree

On Thu, Mar 7, 2024 at 4:36 PM Alvaro Herrera wrote: > > Well, surely we can email them. Their profiles show they're still > active. > https://db.in.tum.de/people/sites/kemper/?lang=en > https://db.in.tum.de/people/sites/neumann/?lang=en > https://db.in.tum.de/people/sites/leis/?lang=en I

Re: pgsql: Add template for adaptive radix tree

On 2024-Mar-07, John Naylor wrote: > Understandably so. FWIW, the use case proposed by the authors was for > secondary indexes within in-memory databases, not as a type of > associative array. I'm unable to find patents for the thing itself, > but IANAL. I believe I've been in contact with some