Re: consider -Wmissing-variable-declarations

I have committed the first few of these. (The compiler warning flag itself is not activated yet.) This should allow you to proceed with your patches that add various const qualifiers. I'll come back to the rest later. On 18.06.24 17:02, Andres Freund wrote: diff --git a/src/bin/pg_archive

Re: New standby_slot_names GUC in PG 17

On Mon, Jul 1, 2024 at 6:01 PM Zhijie Hou (Fujitsu) wrote: > > Thanks! I am attaching another patch to modify the release note as discussed. > Pushed. -- With Regards, Amit Kapila.

Re: pgsql: Add more SQL/JSON constructor functions

On Mon, Jul 1, 2024 at 6:45 PM Amit Langote wrote: > > On Sun, Jun 30, 2024 at 3:56 AM Tom Lane wrote: > > Alvaro Herrera writes: > > >> +/* > > >> + * For domains, consider the base type's typmod to decide whether > > >> to setup > > >> + * an implicit or explicit cast. > > >> +

Re: Avoid orphaned objects dependencies, take 3

Hi, On Mon, Jul 01, 2024 at 09:39:17AM +, Bertrand Drouvot wrote: > Hi, > > On Wed, Jun 26, 2024 at 10:24:41AM +, Bertrand Drouvot wrote: > > Hi, > > > > On Fri, Jun 21, 2024 at 01:22:43PM +, Bertrand Drouvot wrote: > > > Another thought for the RelationRelationId class case: we coul

Re: Pgoutput not capturing the generated columns

Hi Shubham, As you can see, most of my recent review comments for patch 0001 are only cosmetic nitpicks. But, there is still one long-unanswered design question from a month ago [1, #G.2] A lot of the patch code of pgoutput.c and proto.c and logicalproto.h is related to the introduction and passi

Re: LogwrtResult contended spinlock

01.07.2024 20:04, Alvaro Herrera wrote: OK, so it's #if ALIGNOF_LONG_LONG_INT >= 8 Alexander, can you please confirm whether this works for you? Yes, the v4 patch makes `meson test --suite setup` pass in x86 environment. And complete `meson test` fails on pg_amcheck/004_verify_heapam only (I t

Re: Speed up JSON escape processing with SIMD plus other optimisations

I've attached a rebased set of patches. The previous set no longer applied. David v3-0001-Add-len-parameter-to-escape_json.patch Description: Binary data v3-0002-Use-SIMD-processing-for-escape_json.patch Description: Binary data v3-0003-Special-case-text-type-conversion-in-datum_to_jso.patc

Re: pg_createsubscriber: drop pre-existing subscriptions from the converted node

On Mon, 1 Jul 2024 at 11:44, Hayato Kuroda (Fujitsu) wrote: > > Dear Amit, > > Thanks for giving comments! PSA new version. > > > Thanks, this is a better approach. I have changed a few comments and > > made some other cosmetic changes. See attached. > > I checked your attached and LGTM. Based on

Re: Pgoutput not capturing the generated columns

On Mon, Jul 1, 2024 at 8:38 PM Shubham Khanna wrote: > >... > > 8. > > + else if (strcmp(elem->defname, "include-generated-columns") == 0) > > + { > > + if (elem->arg == NULL) > > + data->include_generated_columns = true; > > > > Is there any way to test that "elem->arg == NULL" in the > > generat

Re: Conflict Detection and Resolution

On Mon, Jul 1, 2024 at 11:47 AM Masahiko Sawada wrote: > > Hi, > > On Thu, May 23, 2024 at 3:37 PM shveta malik wrote: > > > > DELETE > > > > Conflict Type: > > > > delete_missing: An incoming delete is trying to delete a row on a > > target node which does not e

RE: Improve EXPLAIN output for multicolumn B-Tree Index

> > I think the better choice would be adding an IndexAmRoutine->amexplain > > support function, which would get called in e.g. explain.c's > > ExplainIndexScanDetails to populate a new "Index Scan Details" (name > > to be bikeshed) subsection of explain plans. This would certainly be > > possible,

Re: Use pgstat_kind_infos to read fixed shared stats structs

On Mon, Jul 01, 2024 at 02:48:19PM +0900, Michael Paquier wrote: > So, how about trying to remove the dependency to the fixed shared > stats structures in PgStat_ShmemControl and PgStat_Snapshot? I'd like > to think that these should be replaced with an area allocated in > shared memory and TopMem

Re: Should we document how column DEFAULT expressions work?

On Tue, 2 Jul 2024 at 02:43, Tom Lane wrote: > I'd be more excited about this discussion if I didn't think that > the chances of removing 'now'::timestamp are exactly zero. You > can't just delete useful decades-old features, whether there's > a better way or not. Do you have any thoughts on rej

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

Michael Paquier writes: > On Mon, Jul 01, 2024 at 08:40:17PM -0400, Tom Lane wrote: >> While this won't actually fail against a v10 or v11 server, it won't >> show anything useful either (because relam is zero for heaps in >> pre-v12 versions). Perhaps there should be a check to only add the >> e

CREATE OR REPLACE MATERIALIZED VIEW

I like to add CREATE OR REPLACE MATERIALIZED VIEW with the attached patches. Patch 0001 adds CREATE OR REPLACE MATERIALIZED VIEW similar to CREATE OR REPLACE VIEW. It also includes regression tests and changes to docs. Patch 0002 deprecates CREATE MATERIALIZED VIEW IF NOT EXISTS because it no lo

Re: Built-in CTYPE provider

On Mon, 2024-07-01 at 16:03 -0700, Noah Misch wrote: > I agree the v17 code is fine.  Today, a user can (with difficulty) > choose > dependency libraries so regexp_matches() is IMMUTABLE, as marked.  I > don't > want $SUBJECT to be the ctype that, at some post-v17 version, can't > achieve > that wi

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

On Mon, Jul 01, 2024 at 08:40:17PM -0400, Tom Lane wrote: > While this won't actually fail against a v10 or v11 server, it won't > show anything useful either (because relam is zero for heaps in > pre-v12 versions). Perhaps there should be a check to only add the > extra column if server >= v12?

Re: Cleaning up perl code

On Fri, May 24, 2024 at 02:09:49PM +0900, Michael Paquier wrote: > For now, I have staged for commit the attached, that handles most of > the changes from Alexander (msvc could go for more cleanup?). This one has been applied as of 0c1aca461481 now that v18 is open. > I'll look at the changes fro

Re: Make tuple deformation faster

David Rowley writes: > You can see the branch predictor has done a *much* better job in the > patched code vs master with about 10x fewer misses. This should have > helped contribute to the "insn per cycle" increase. 4.29 is quite > good for postgres. I often see that around 0.5. According to [

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

Michael Paquier writes: > On Thu, Jun 06, 2024 at 09:43:45AM +0900, Michael Paquier wrote: >> Not sure that this is a must-have. It is nice to have, but extra >> information is a new feature IMO. Any extra opinions? > Hearing nothing, I've applied that on HEAD now that v18 is open. While this

Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)

On Mon, Jul 01, 2024 at 09:19:59PM +0200, Daniel Gustafsson wrote: >> The bit I don't understand about this discussion is what will happen >> with users that currently have exactly 1024 chars in backup names today. >> With this change, we'll be truncating their names to 1023 chars instead. >> Why w

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

On Thu, Jun 06, 2024 at 09:43:45AM +0900, Michael Paquier wrote: > Not sure that this is a must-have. It is nice to have, but extra > information is a new feature IMO. Any extra opinions? Hearing nothing, I've applied that on HEAD now that v18 is open. -- Michael signature.asc Description: PGP

Re: Make tuple deformation faster

On Mon, 1 Jul 2024 at 23:42, Matthias van de Meent wrote: > > On Mon, 1 Jul 2024 at 12:49, David Rowley wrote: > > > > On Mon, 1 Jul 2024 at 22:07, Matthias van de Meent > > wrote: > > > One thing I'm slightly concerned about is that this allocates another > > > 8 bytes for each attribute in the

Re: Parallel CREATE INDEX for GIN indexes

Tomas Vondra writes: Hi Tomas, I am in a incompleted review process but I probably doesn't have much time on this because of my internal tasks. So I just shared what I did and the non-good-result patch. What I tried to do is: 1) remove all the "sort" effort for the state->bs_sort_state tuples s

Re: Relation bulk write facility

On Tue, Jul 02, 2024 at 12:53:05AM +0300, Heikki Linnakangas wrote: > On 01/07/2024 23:52, Noah Misch wrote: > > Commit 8af2565 wrote: > > > --- /dev/null > > > +++ b/src/backend/storage/smgr/bulk_write.c > > > > > +/* > > > + * Finish bulk write operation. > > > + * > > > + * This WAL-logs and fl

Re: Built-in CTYPE provider

On Mon, Jul 01, 2024 at 12:24:15PM -0700, Jeff Davis wrote: > On Sat, 2024-06-29 at 15:08 -0700, Noah Misch wrote: > > lower(), initcap(), upper(), and regexp_matches() are > > PROVOLATILE_IMMUTABLE. > > Until now, we've delegated that responsibility to the user.  The user > > is > > supposed to so

Re: Optimize numeric multiplication for one and two base-NBASE digit multiplicands.

On Mon, 1 Jul 2024 at 20:56, Joel Jacobson wrote: > > Below is a more realistic benchmark > > CREATE TABLE bench_mul_var (num1 numeric, num2 numeric); > > INSERT INTO bench_mul_var (num1, num2) > SELECT random(0::numeric,1e8::numeric), random(0::numeric,1e8::numeric) FROM > generate_series(1,1e8)

Re: Relation bulk write facility

Thanks for poking at this! On 01/07/2024 23:52, Noah Misch wrote: Commit 8af2565 wrote: --- /dev/null +++ b/src/backend/storage/smgr/bulk_write.c +/* + * Finish bulk write operation. + * + * This WAL-logs and flushes any remaining pending writes to disk, and fsyncs + * the relation if needed

Re: Relation bulk write facility

On Fri, Feb 23, 2024 at 04:27:34PM +0200, Heikki Linnakangas wrote: > Committed this. Thanks everyone! Commit 8af2565 wrote: > --- /dev/null > +++ b/src/backend/storage/smgr/bulk_write.c > +/* > + * Finish bulk write operation. > + * > + * This WAL-logs and flushes any remaining pending writes to

Re: WIP: parallel GiST index builds

Hi, I've done a number of experiments with the GiST parallel builds, both with the sorted and unsorted cases, so let me share some of the results and conclusions from that. In the first post I did some benchmarks using btree_gist, but that seemed not very realistic - there certainly are much more

Re: Commitfest manager for July 2024

> Postgres 17 18

Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)

> On 1 Jul 2024, at 21:58, Ranier Vilela wrote: > We only have to replace it with strlcpy. Thanks, I'll have a look at applying this in the tomorrow morning. -- Daniel Gustafsson

Re: optimizing pg_upgrade's once-in-each-database steps

On Mon, Jul 01, 2024 at 03:58:16PM -0400, Robert Haas wrote: > On Mon, Jul 1, 2024 at 3:47 PM Nathan Bossart > wrote: >> 0001 introduces a new API for registering callbacks and running them in >> parallel on all databases in the cluster. This new system manages a set of >> "slots" that follow a

Re: optimizing pg_upgrade's once-in-each-database steps

On Mon, Jul 1, 2024 at 3:47 PM Nathan Bossart wrote: > 0001 introduces a new API for registering callbacks and running them in > parallel on all databases in the cluster. This new system manages a set of > "slots" that follow a simple state machine to asynchronously establish a > connection and r

Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)

Em seg., 1 de jul. de 2024 às 16:20, Daniel Gustafsson escreveu: > > On 1 Jul 2024, at 21:15, Alvaro Herrera wrote: > > On 2024-Jul-01, Ranier Vilela wrote: > > >>> - charname[MAXPGPATH + 1]; > >>> + charname[MAXPGPATH];/* backup label name */ > >>> > >>> With

Re: Optimize numeric multiplication for one and two base-NBASE digit multiplicands.

On Mon, Jul 1, 2024, at 15:14, Joel Jacobson wrote: > * 0001-Optimize-mul_var-for-var2ndigits-4.patch Found a typo, fixed in new version. The int128 version is still slower though, I wonder if there is something that can be done to speed it up further. Below is a more realistic benchmark than ju

Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)

Em seg., 1 de jul. de 2024 às 16:15, Alvaro Herrera escreveu: > On 2024-Jul-01, Ranier Vilela wrote: > > > > - charname[MAXPGPATH + 1]; > > > + charname[MAXPGPATH];/* backup label name */ > > > > > > With the introduced use of strlcpy, why do we need to change

Re: optimizing pg_upgrade's once-in-each-database steps

I figured I'd post what I have so far since this thread hasn't been updated in a while. The attached patches are still "proof-of-concept grade," but they are at least moving in the right direction (IMHO). The variable naming is still not great, and they are woefully undercommented, among other th

Re: Built-in CTYPE provider

On Sat, 2024-06-29 at 15:08 -0700, Noah Misch wrote: > lower(), initcap(), upper(), and regexp_matches() are > PROVOLATILE_IMMUTABLE. > Until now, we've delegated that responsibility to the user.  The user > is > supposed to somehow never update libc or ICU in a way that changes > outcomes > from t

Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)

> On 1 Jul 2024, at 21:15, Alvaro Herrera wrote: > On 2024-Jul-01, Ranier Vilela wrote: >>> - charname[MAXPGPATH + 1]; >>> + charname[MAXPGPATH];/* backup label name */ >>> >>> With the introduced use of strlcpy, why do we need to change this field? >>> >> Th

Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)

On 2024-Jul-01, Ranier Vilela wrote: > > - charname[MAXPGPATH + 1]; > > + charname[MAXPGPATH];/* backup label name */ > > > > With the introduced use of strlcpy, why do we need to change this field? > > > The part about being the only reference in the entire cod

Re: LogwrtResult contended spinlock

Hello, Thanks for your attention here. On 2024-Jul-01, Andres Freund wrote: > On 2024-07-01 11:10:24 +0200, Alvaro Herrera wrote: > > In the meantime I noticed that pg_attribute_aligned() is not supported > > in every platform/compiler, so for safety sake I think it's better to go > > with what

Re: Remove last traces of HPPA support

Noah Misch writes: > On Sat, Oct 21, 2023 at 02:18:19AM -0400, Tom Lane wrote: >> Andres Freund writes: >>> IMO a single person looking at HPPA code for a few minutes is a cost that >>> more >>> than outweighs the potential benefits of continuing "supporting" this dead >>> arch. Even code that d

Commitfest manager for July 2024

Hello everyone! As Michael noted in e26810d01d4 [0] hacking for Postgres 17 has begun. I’ve skimmed through hackers@ list. And it seems that so far role of the commitfest manager is vacant. Is anyone up for doing this community work? Make things moving :) Best regards, Andrey Borodin. [0] htt

Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)

Em seg., 1 de jul. de 2024 às 14:35, Ranier Vilela escreveu: > Em seg., 1 de jul. de 2024 às 06:20, Daniel Gustafsson > escreveu: > >> > On 27 Jun 2024, at 13:50, Ranier Vilela wrote: >> >> > Now with file patch really attached. >> >> - if (strlen(backupidstr) > MAXPGPATH) >> + if (

Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)

Em seg., 1 de jul. de 2024 às 06:20, Daniel Gustafsson escreveu: > > On 27 Jun 2024, at 13:50, Ranier Vilela wrote: > > > Now with file patch really attached. > > - if (strlen(backupidstr) > MAXPGPATH) > + if (strlcpy(state->name, backupidstr, sizeof(state->name)) >= > sizeof(state->

Re: LogwrtResult contended spinlock

Hi, On 2024-07-01 11:10:24 +0200, Alvaro Herrera wrote: > In the meantime I noticed that pg_attribute_aligned() is not supported > in every platform/compiler, so for safety sake I think it's better to go > with what we do for PGAlignedBlock: use a union with a double member. > That should be 8-byt

Re: call for applications: mentoring program for code contributors

On Thu, Jun 20, 2024 at 1:12 PM Robert Haas wrote: > I'm working to start a mentoring program where code contributors can > be mentored by current committers. Applications are now open: > https://forms.gle/dgjmdxtHYXCSg6aB7 Applications are now closed. Initially, I had imagined just keeping this

Re: LogwrtResult contended spinlock

On 2024-Jul-01, Tom Lane wrote: > Alvaro Herrera writes: > > Maybe we can do something like this, > > > +#if MAXIMUM_ALIGNOF >= 8 > > uint64 currval; > > This should probably be testing the alignment of int64 specifically, > rather than assuming that MAXIMUM_ALIGNOF applies to it.

Re: pg_sequence_last_value() for unlogged sequences on standbys

On Thu, May 16, 2024 at 08:33:35PM -0500, Nathan Bossart wrote: > Here is a rebased version of 0002, which I intend to commit once v18 > development begins. Committed. -- nathan

Re: Backporting BackgroundPsql

On 01/07/2024 17:11, Pavan Deolasee wrote: H i Daniel, On Mon, Jul 1, 2024 at 1:09 PM Daniel Gustafsson > wrote: > On 29 Jun 2024, at 06:38, Pavan Deolasee mailto:pavan.deola...@gmail.com>> wrote: > Don't we need to add install and uninstall rules for the

Re: Restart pg_usleep when interrupted

> >> Therefore, rather than "improving" pg_usleep (and uglifying its API), >> the right answer is to fix parallel vacuum leaders to not depend on >> pg_usleep in the first place. A better idea might be to use >> pg_sleep() or equivalent code. > > Yes, that is a good idea to explore and it will

Re: Wrong security context for deferred triggers?

On Sat, 2024-06-22 at 17:50 -0400, Joseph Koshakow wrote: > On Mon, Jun 10, 2024 at 1:00 PM Laurenz Albe wrote: > > Like you, I was surprised by the current behavior.  There is a design > > principle that PostgreSQL tries to follow, called the "Principle of > > least astonishment".  Things should

Windows perl/tcl requirement documentation

Our docs currently state this regarding the perl requirement for building on Windows: ActiveState Perl ActiveState Perl is required to run the build generation scripts. MinGW or Cygwin Perl will not work. It must also be present in the PATH. Binaries can be downloaded from https://w

Re: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall

Committed. -- nathan

Re: small pg_dump code cleanup

> On 11 Jun 2024, at 22:30, Nathan Bossart wrote: > At the moment, I'm inclined to commit v1 once v18 development opens up. We > can consider any additional adjustments separately. Patch LGTM and the tests pass, +1 on pushing this version. -- Daniel Gustafsson

Re: gamma() and lgamma() functions

On 2024-Jul-01, Stepan Neretin wrote: > I have one notice: > ERROR: value out of range: overflow. I think we need to add information > about the available ranges in the error message I think this is a project of its own. The error comes from calling float_overflow_error(), which is a generic ro

jsonpath: Inconsistency of timestamp_tz() Output

Hackers, There’s an odd difference in the behavior of timestamp_tz() outputs. Running with America/New_York as my TZ, it looks fine for a full timestamptz, identical to how casting the types directly works: david=# set time zone 'America/New_York'; SET david=# select '2024-08-15 12:34:56-04'::

Re: LogwrtResult contended spinlock

Alvaro Herrera writes: > Maybe we can do something like this, > +#if MAXIMUM_ALIGNOF >= 8 > uint64 currval; This should probably be testing the alignment of int64 specifically, rather than assuming that MAXIMUM_ALIGNOF applies to it. At least historically, there have been platfor

Re: LogwrtResult contended spinlock

Maybe we can do something like this, diff --git a/src/include/port/atomics.h b/src/include/port/atomics.h index 78987f3154..f6fa90bad8 100644 --- a/src/include/port/atomics.h +++ b/src/include/port/atomics.h @@ -580,7 +580,20 @@ pg_atomic_sub_fetch_u64(volatile pg_atomic_uint64 *ptr, int64 sub_)

RE: speed up a logical replica setup

Dear Tom, > I have a different but possibly-related complaint: why is > 040_pg_createsubscriber.pl so miserably slow? On my machine it > runs for a bit over 19 seconds, which seems completely out of line > (for comparison, 010_pg_basebackup.pl takes 6 seconds, and the > other test scripts in this

Re: Should we document how column DEFAULT expressions work?

Peter Eisentraut writes: > On 01.07.24 01:54, David Rowley wrote: >> I think there are valid reasons to use the special timestamp input >> values. One that I can think of is for use with partition pruning. If >> you have a time-range partitioned table and want the planner to prune >> the partitio

Re: Surround CheckRelation[Oid]LockedByMe() with USE_ASSERT_CHECKING

Hi, On Mon, Jul 01, 2024 at 10:21:35AM -0400, Tom Lane wrote: > Michael Paquier writes: > > On Mon, Jul 01, 2024 at 06:42:46AM +, Bertrand Drouvot wrote: > >> I think it would make sense to declare / define those functions only for > >> assert enabled build: please find attached a tiny patch

Re: LogwrtResult contended spinlock

On 2024-Jul-01, Tom Lane wrote: > Alvaro Herrera writes: > >> because the failed assertion is: > >> #ifndef PG_HAVE_ATOMIC_U64_SIMULATION > >>     AssertPointerAlignment(&currval, 8); > >> #endif > > Perhaps this assertion is what is wrong? If the platform has no > native 8-byte alignment requi

Re: gamma() and lgamma() functions

On Mon, Jul 1, 2024 at 5:33 PM Dean Rasheed wrote: > Attached is a patch adding support for the gamma and log-gamma > functions. See, for example: > > https://en.wikipedia.org/wiki/Gamma_function > > I think these are very useful general-purpose mathematical functions. > They're part of C99, and

Re: Should we document how column DEFAULT expressions work?

On 01.07.24 01:54, David Rowley wrote: On Thu, 27 Jun 2024 at 23:57, Peter Eisentraut wrote: Maybe we should really be thinking about deprecating these special values and steering users more urgently toward more robust alternatives. Imagine if 'random' were a valid input value for numeric type

Re: gamma() and lgamma() functions

> On 1 Jul 2024, at 16:20, Stepan Neretin wrote: > The patch file seems broken. > git apply gamma-and-lgamma.patch error: git apply: bad git-diff — exptec > /dev/null in line 2 It's a plain patch file, if you apply it with patch and not git it will work fine: $ patch -p1 < gamma-and-lgamma.p

Re: Surround CheckRelation[Oid]LockedByMe() with USE_ASSERT_CHECKING

Michael Paquier writes: > On Mon, Jul 01, 2024 at 06:42:46AM +, Bertrand Drouvot wrote: >> I think it would make sense to declare / define those functions only for >> assert enabled build: please find attached a tiny patch doing so. > Not convinced that's a good idea. What about out-of-core

Re: gamma() and lgamma() functions

On Mon, Jul 1, 2024 at 5:33 PM Dean Rasheed wrote: > Attached is a patch adding support for the gamma and log-gamma > functions. See, for example: > > https://en.wikipedia.org/wiki/Gamma_function > > I think these are very useful general-purpose mathematical functions. > They're part of C99, and

Re: Should we move the resowner field from JitContext to LLVMJitContext?

> On 5 Jun 2024, at 10:19, Andreas Karlsson wrote: > When Heikki made the resource owners extensible in commit > b8bff07daa85c837a2747b4d35cd5a27e73fb7b2 the API for JIT plugins changed when > ResourceOwnerForgetJIT() was moved from the generic JIT code to the LLVM > specific JIT code so now t

Re: Backporting BackgroundPsql

H i Daniel, On Mon, Jul 1, 2024 at 1:09 PM Daniel Gustafsson wrote: > > On 29 Jun 2024, at 06:38, Pavan Deolasee > wrote: > > > Don't we need to add install and uninstall rules for the new module, > like we did in > https://git.postgresql.org/pg/commitdiff/a4c17c86176cfa712f541b81b2a026ae054b27

Re: LogwrtResult contended spinlock

Alvaro Herrera writes: >> because the failed assertion is: >> #ifndef PG_HAVE_ATOMIC_U64_SIMULATION >>     AssertPointerAlignment(&currval, 8); >> #endif Perhaps this assertion is what is wrong? If the platform has no native 8-byte alignment requirement, why do we think that atomics need it?

Re: [PATCH] Handle SK_SEARCHNULL and SK_SEARCHNOTNULL in HeapKeyTest

Hi, > This patches changes the HeapKeyTest macro to add handling for SK_SEARCHNULL > and SK_SEARCHNOTNULL. While currently no core codes uses these ScanKey flags > it would be useful for extensions if it was supported so extensions > dont have to implement > handling for those by themself. As I r

Re: Wrong security context for deferred triggers?

Hi, Allow me to provide some background on how we came across this. (This is my first time posting to a pgsql list so hopefully I've got everything set up correctly.) We have a db with a big legacy section that we're in the process of modernizing. To compensate for some of the shortcomings w

Re: Should we document how column DEFAULT expressions work?

On Sun, Jun 30, 2024 at 8:16 PM David G. Johnston wrote: > > On Sun, Jun 30, 2024 at 4:55 PM David Rowley wrote: >> >> >> I'd like to know what led someone down the path of doing something >> like DEFAULT 'now()'::timestamp in a CREATE TABLE. Could it be a >> faulty migration tool that created th

Re: Reg: Alternate way of hashing database role passwords

> On 26 Jun 2024, at 18:59, Robert Haas wrote: > However, it seems like SCRAM is designed so > that different hash functions can be substituted into it, so what I'm > hoping is that we can keep SCRAM and just replace SCRAM-SHA-256 with > SCRAM-WHATEVER when SHA-256 starts to look too weak. Corre

Re: Optimize numeric multiplication for one and two base-NBASE digit multiplicands.

On Mon, Jul 1, 2024, at 15:11, Joel Jacobson wrote: > Not really sure why. Maybe the code I tried can be optimized further: If anyone want experiment with the int128 version, here is a patch that adds a separate numeric_mul_patched() function, so it's easier to benchmark against the unmodified num

Re: PATCH: Add query for operators unusable with RLS to documentation

On Sun, 23 Jun 2024 19:14:09 +0900 Yugo NAGATA wrote: > and Operator Families"? Additionally, is it useful to add LEAKPROOF > information > to the result of psql \dAo(+) meta-comand, or a function that can check given > index > or operator is leakproof or not? I worte a pach to implement the p

Re: Optimize numeric multiplication for one and two base-NBASE digit multiplicands.

On Mon, Jul 1, 2024, at 14:25, Dagfinn Ilmari Mannsåker wrote: > div_var() also has an optimisation for 3- and 4-digit operands under > HAVE_INT128 (added in commit 0aa38db56bf), would that make sense in > mul_var() too? I considered it, but it only gives a marginal speed-up on Intel Core i9-14900

psql: Add leakproof field to \dAo+ meta-command results

Hi, I would like to propose to add a new field to psql's \dAo+ meta-command to show whether the underlying function of an operator is leak-proof. This idea is inspired from [1] that claims some indexes uses non-LEAKPROOF functions under the associated operators, as a result, it can not be selecte

Re: [PATCH] Fix docs to use canonical links

> On 1 Jul 2024, at 13:09, Joel Jacobson wrote: > > On Mon, Jul 1, 2024, at 09:35, Daniel Gustafsson wrote: >> Avoding redirects is generally a good thing, not everyone is on lightning >> fast >> internet. Wikipedia is however not doing any 30X redirects so it's not >> really >> an issue for t

RE: New standby_slot_names GUC in PG 17

On Monday, July 1, 2024 6:45 PM Amit Kapila wrote: > > On Thu, Jun 27, 2024 at 7:14 AM Masahiko Sawada > wrote: > > > > On Wed, Jun 26, 2024 at 6:15 PM Zhijie Hou (Fujitsu) > > wrote: > > > > Thank you for updating the patch. The v2 patch looks good to me. > > > > Pushed. Thanks! I am attachi

Re: Optimize numeric multiplication for one and two base-NBASE digit multiplicands.

"Joel Jacobson" writes: > Hello hackers, > > Attached patch introduces an optimization of mul_var() in numeric.c, > targeting cases where the multiplicands consist of only one or two > base-NBASE digits. Such small multiplicands can fit into an int64 and > thus be computed directly, resulting in

Re: pg_createsubscriber: drop pre-existing subscriptions from the converted node

On Mon, Jul 1, 2024 at 11:44 AM Hayato Kuroda (Fujitsu) wrote: > > > You can create a dummy subscription on node_p > > and do a test similar to what we are doing in "# Create failover slot > > to test its removal". > > Your approach looks better than mine. I followed the approach. > LGTM. -- Wi

Re: Make tuple deformation faster

On Mon, 1 Jul 2024 at 12:49, David Rowley wrote: > > On Mon, 1 Jul 2024 at 22:07, Matthias van de Meent > wrote: > > One thing I'm slightly concerned about is that this allocates another > > 8 bytes for each attribute in the tuple descriptor. While that's not a > > lot when compared with the ->at

Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids)

On Jul 1, 2024, at 12:56 AM, Ashutosh Bapat wrote:On Wed, Jun 12, 2024 at 4:22 AM David Christensen wrote:On Mon, Jun 10, 2024 at 8:15 AM Robert Haas wrote: > > On Mon, Jun 10, 2024 at 3:09 AM Ashutosh Bapat > wrote: > >

Re: [PATCH] Fix docs to use canonical links

On Mon, Jul 1, 2024, at 09:35, Daniel Gustafsson wrote: > Avoding redirects is generally a good thing, not everyone is on lightning fast > internet. Wikipedia is however not doing any 30X redirects so it's not really > an issue for those links, it's all 200 requests. Yes, I noticed that too when

Re: Virtual generated columns

On 28.06.24 02:00, jian he wrote: the test structure you made ( generated_stored.sql, generated_virtual.sq) looks ok to me. but do we need to reset the search_path at the end of generated_stored.sql, generated_virtual.sql? No, the session ends at the end of the test file, so we don't need to r

Re: Virtual generated columns

On 17.06.24 21:31, Tomasz Rybak wrote: v1-0001-Rename-regress-test-generated-to-generated_stored.patch: no objections here, makes sense as preparation for future changes v1-0002-Put-generated_stored-test-objects-in-a-schema.patch: also no objections. OTOH other tests (like publication.out, rowse

Re: Make tuple deformation faster

On Mon, 1 Jul 2024 at 22:07, Matthias van de Meent wrote: > Cool, that's similar to, but even better than, my patch from 2021 over at [0]. I'll have a read of that. Thanks for pointing it out. > One thing I'm slightly concerned about is that this allocates another > 8 bytes for each attribute in

Re: pgsql: Add more SQL/JSON constructor functions

On Sun, Jun 30, 2024 at 3:56 AM Tom Lane wrote: > Alvaro Herrera writes: > >> +/* > >> + * For domains, consider the base type's typmod to decide whether to > >> setup > >> + * an implicit or explicit cast. > >> + */ > >> +if (get_typtype(returning->typid) == TYPTYPE_DOMAIN)

Re: New standby_slot_names GUC in PG 17

On Thu, Jun 27, 2024 at 7:14 AM Masahiko Sawada wrote: > > On Wed, Jun 26, 2024 at 6:15 PM Zhijie Hou (Fujitsu) > wrote: > > Thank you for updating the patch. The v2 patch looks good to me. > Pushed. -- With Regards, Amit Kapila.

gamma() and lgamma() functions

Attached is a patch adding support for the gamma and log-gamma functions. See, for example: https://en.wikipedia.org/wiki/Gamma_function I think these are very useful general-purpose mathematical functions. They're part of C99, and they're commonly included in other mathematical libraries, such a

Alias of VALUES RTE in explain plan

Hi All, While reviewing Richard's patch for grouping sets, I stumbled upon following explain output explain (costs off) select distinct on (a, b) a, b from (values (1, 1), (2, 2)) as t (a, b) where a = b group by grouping sets((a, b), (a)) order by a, b; QUERY PLAN -

Re: Make tuple deformation faster

On Mon, 1 Jul 2024 at 21:17, Andy Fan wrote: > Yet another a wonderful optimization! I just want to know how did you > find this optimization (CPU cache hit) case and think it worths some > time. because before we invest our time to optimize something, it is > better know that we can get some meas

Re: Make tuple deformation faster

On Mon, 1 Jul 2024 at 10:56, David Rowley wrote: > > Currently, TupleDescData contains the descriptor's attributes in a > variable length array of FormData_pg_attribute allocated within the > same allocation as the TupleDescData. According to my IDE, > sizeof(FormData_pg_attribute) == 104 bytes. I

Re: cfbot update: Using GitHub for patch review

On Sat, Jun 29, 2024 at 2:12 PM Jelte Fennema-Nio wrote: > On Sat, 29 Jun 2024 at 01:13, Thomas Munro wrote: > > > > On Sat, Jun 29, 2024 at 1:10 AM Ashutosh Bapat > > wrote: > > > I need to sign in to github to add my review comments. So those who do > not have a github account can not use it

Re: Conflict Detection and Resolution

On Mon, Jul 1, 2024 at 1:35 PM Masahiko Sawada wrote: > > Setting resolvers at table-level and subscription-level sounds good to > me. DDLs for setting resolvers at subscription-level would need the > subscription name to be specified? > Yes, it should be part of the ALTER/CREATE SUBSCRIPTION com

Re: Conflict Detection and Resolution

On Mon, Jul 1, 2024 at 11:47 AM Masahiko Sawada wrote: > > On Thu, May 23, 2024 at 3:37 PM shveta malik wrote: > > > > DELETE > > > > Conflict Type: > > > > delete_missing: An incoming delete is trying to delete a row on a > > target node which does not exist. >

Re: Converting README documentation to Markdown

> On 28 Jun 2024, at 20:40, Peter Eisentraut wrote: > If we're going to do it, then I expect that the files are marked up correctly > at all times. I agree with that. I don't think it will be a terribly high bar though since we were pretty much already writing markdown. We already have pandoc

  1   2   >