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

Hi, On Mon, Jul 1, 2024 at 12:12 PM Bertrand Drouvot wrote: > > Hi hackers, > > While working on a rebase for [1] due to 0cecc908e97, I noticed that > CheckRelationLockedByMe() and CheckRelationOidLockedByMe() are used only in > assertions. > > I think it would make sense to declare / define thos

Re: Virtual generated columns

On 28.06.24 02:00, jian he wrote: inhttps://www.postgresql.org/docs/current/catalog-pg-attrdef.html The catalog pg_attrdef stores column default values. The main information about columns is stored in pg_attribute. Only columns for which a default value has been explicitly set will have an entry

Re: pgsql: Add more SQL/JSON constructor functions

On Sun, Jun 30, 2024 at 2:24 AM Alvaro Herrera wrote: > > TBH I'm not super clear on why we decide on explicit or implicit cast > based on presence of a typmod. Why isn't it better to always use an > implicit one? > I am using an example to explain it. SELECT JSON_SERIALIZE(JSON('{ "a" : 1 } '))

Re: Logical Replication of sequences

Here are some review comments for the patch v20240625-0002 == Commit Message 1. This commit enhances logical replication by enabling the inclusion of all sequences in publications. This improvement facilitates seamless synchronization of sequence data during operations such as CREATE SUBSCRIP

Re: [PATCH] Fix docs to use canonical links

> On 1 Jul 2024, at 08:06, Michael Paquier wrote: > > On Thu, Jun 27, 2024 at 11:27:45AM +0200, Joel Jacobson wrote: >> During work in the separate thread [1], I discovered more cases >> where the link in docs wasn't the canonical link [2]. >> >> [1] >> https://postgr.es/m/cakfquwyex9pj9g0zhjew

Re: Backporting BackgroundPsql

> 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/a4c17c86176cfa712f541b81b2a026ae054b275e > and > https://git.postgresql.org/pg/commitdiff/7039c7cff6736780c3bbb

Re: Conflict Detection and Resolution

On Thu, Jun 27, 2024 at 1:14 PM Nisha Moond wrote: > Please find the attached 'patch0003', which implements conflict > resolutions according to the global resolver settings. > > Summary of Conflict Resolutions Implemented in 'patch0003': > > INSERT Conflicts: > > 1) Conf

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

Hi, On Mon, Jul 01, 2024 at 12:35:34PM +0530, Bharath Rupireddy wrote: > Hi, > > On Mon, Jul 1, 2024 at 12:12 PM Bertrand Drouvot > wrote: > > > > Hi hackers, > > > > While working on a rebase for [1] due to 0cecc908e97, I noticed that > > CheckRelationLockedByMe() and CheckRelationOidLockedByMe

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

On Mon, Jul 01, 2024 at 06:42:46AM +, Bertrand Drouvot wrote: > While working on a rebase for [1] due to 0cecc908e97, I noticed that > CheckRelationLockedByMe() and CheckRelationOidLockedByMe() are used only in > assertions. > > I think it would make sense to declare / define those functions o

Re: Conflict Detection and Resolution

On Thu, Jun 27, 2024 at 1:50 PM shveta malik wrote: > > On Wed, Jun 26, 2024 at 2:33 PM Amit Kapila wrote: > > > > On Tue, Jun 25, 2024 at 3:39 PM shveta malik wrote: > > > > > > On Tue, Jun 25, 2024 at 3:12 PM Amit Kapila > > > wrote: > > > > > > > > On Mon, Jun 24, 2024 at 1:47 PM shveta mal

Re: Adminpack removal

> On 28 Jun 2024, at 09:06, Philippe BEAUDOIN wrote: > So just looking in public repo covers probably less than 1% of the code. > However, this may give a first idea, especialy if a feature use is already > detected. Searching for anything on Github is essentially a dead end since it reports s

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

On Mon, Jul 1, 2024, at 08:04, Joel Jacobson wrote: > * 0001-optimize-numeric-mul_var-small-factors.patch New version to silence maybe-uninitialized error reported by cfbot. /Joel v2-0001-optimize-numeric-mul_var-small-factors.patch Description: Binary data

Re: Wrong results with grouping sets

On Mon, Jun 10, 2024 at 5:05 PM Richard Guo wrote: > This patchset does not apply any more. Here is a new rebase. Here is an updated version of this patchset. I've run pgindent for it, and also tweaked the commit messages a bit. In principle, 0001 can be backpatched to all supported versions t

Re: Is missing LOGIN Event on Trigger Firing Matrix ?

> On 27 Jun 2024, at 22:00, David G. Johnston > wrote: > I suggest adding a sentence and link from the main description [1] to that > page. How about the attached. -- Daniel Gustafsson login_evt_link.diff Description: Binary data

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

> On 27 Jun 2024, at 06:01, Yugo NAGATA wrote: >> Em dom., 23 de jun. de 2024 às 23:56, Richard Guo >> escreveu: >>> On Mon, Jun 24, 2024 at 7:51 AM Ranier Vilela wrote: memcpy with strlen does not copy the whole string. strlen returns the exact length of the string, without the

Re: LogwrtResult contended spinlock

Hello, On 2024-Jun-29, Alexander Lakhin wrote: > It doesn't, but the following works for me: >  static inline uint64 >  pg_atomic_monotonic_advance_u64(volatile pg_atomic_uint64 *ptr, uint64 > target_) >  { > -   uint64  currval; > +   pg_attribute_aligned(8) uint64  curr

Re: doc: modify the comment in function libpqrcv_check_conninfo()

On Thu, 27 Jun 2024 at 12:27, ikedarintarof wrote: > Thanks for your suggestion. I used ChatGPT to choose the wording, but > it's still difficult for me. Looks good to me now (but obviously biased since you took my wording). Adding Robert, since he authored the commit that introduced this comment

Re: Make tuple deformation faster

David Rowley writes: > 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. It's that large mainly due > t

Re: A new strategy for pull-up correlated ANY_SUBLINK

On 10/12/23 14:52, Andy Fan wrote: Here the sublink can't be pulled up because of its reference to the  LHS of left join, the original logic is that no matter the 'b.t in ..' returns the true or false,  the rows in LHS will be returned.  If we pull it up to LHS, some rows in LHS will be filtered

Re: Add memory context type to pg_backend_memory_contexts view

On Sat, 1 Jun 2024 at 12:55, Michael Paquier wrote: > This patch looks like a good idea, so +1 from here. Thank you to both of you for reviewing this. I've now pushed the patch. David

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

> 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->name)) ereport(ERROR, Stylistic nit perhaps, I would keep the

Re: Avoid orphaned objects dependencies, take 3

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 could check if > > there > > is a lock first and if there is no lock then acquire one. T

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

Hi, On Mon, Jul 01, 2024 at 05:01:46PM +0900, Michael Paquier wrote: > On Mon, Jul 01, 2024 at 06:42:46AM +, Bertrand Drouvot wrote: > > While working on a rebase for [1] due to 0cecc908e97, I noticed that > > CheckRelationLockedByMe() and CheckRelationOidLockedByMe() are used only in > > asse

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

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: 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: 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: 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: 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

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 -

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

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.

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: 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: 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: 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: [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: 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: 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: 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: 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: 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: [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

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: 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

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 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: 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: 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: 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: [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: 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: 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: 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: 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: 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 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: 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 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: 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: 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: 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: 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: 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: 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

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: 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

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: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall

Committed. -- nathan

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: 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

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: 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: 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: 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: 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

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: 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: 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 (

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: 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

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: 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: 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: 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: 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: 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: 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: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: 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: 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: 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: Commitfest manager for July 2024

> Postgres 17 18

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: 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: 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: 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: 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: 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: 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

  1   2   >