Re: GUC names in messages

On Tue, 2023-11-28 at 07:53 +0900, Michael Paquier wrote: > On Mon, Nov 27, 2023 at 01:35:44AM -0500, Tom Lane wrote: > > Laurenz Albe writes: > > > On Mon, 2023-11-27 at 13:41 +1100, Peter Smith wrote: > > > > In the documentation and in the guc_tables.c they are all described in > > > >

Re: BackgroundPsql's set_query_timer_restart() may not work

Bharath Rupireddy writes: > A nitpick on the patch - how about honoring the passed-in parameter > with something like $self->{query_timer_restart} = 1 if !defined > $self->{query_timer_restart}; instead of just setting it to 1 (a value > other than undef) $self->{query_timer_restart} = 1;? I

Re: Synchronizing slots from primary to standby

Hi, On 11/28/23 4:13 AM, shveta malik wrote: On Mon, Nov 27, 2023 at 4:08 PM Amit Kapila wrote: On Mon, Nov 27, 2023 at 2:27 PM Zhijie Hou (Fujitsu) wrote: Here is the updated version(v39_2) which include all the changes made in 0002. Please use for review, and sorry for the confusion.

Re: [PATCH] pg_convert improvement

Hi, On 11/28/23 2:16 AM, Yurii Rashkovskii wrote:  Hi Bertrand, Did some minor changes in the attached: - Started the multi-line comment with an upper case and finished it with a "." and re-worded a bit. - Ran pgindent What do you think about the attached? It looks

Re: BackgroundPsql's set_query_timer_restart() may not work

On Tue, Nov 28, 2023 at 6:48 AM Masahiko Sawada wrote: > > Hi, > > While adding some TAP tests, I realized that set_query_timer_restart() > in BackgroundPsql may not work. Specifically, it seems not to work > unless we pass an argument to the function. Here is the test script I > used: > > If

Re: PostgreSql: Canceled on conflict out to old pivot

Hi, > On 28. Nov 2023, at 06:41, Wirch, Eduard wrote: > >  > > : > > ERROR: could not serialize access due to read/write dependencies among > transactions > Detail: Reason code: Canceled on identification as a pivot, with conflict > out to old committed transaction 61866959. > > There

PostgreSql: Canceled on conflict out to old pivot

Hi I posted this question already on pgsql-general, but it got no answers. Maybe the topic is too technical? So I'm trying it here. Maybe a SSI specialist is here on the list. We have a PostgreSql 15 server serving around 30 databases, one schema each with the same layout. Each database is used

Re: [PoC] pg_upgrade: allow to upgrade publisher node

On Thu, Nov 9, 2023 at 7:07 PM Amit Kapila wrote: > > On Wed, Nov 8, 2023 at 11:05 PM vignesh C wrote: > > > > On Wed, 8 Nov 2023 at 08:43, vignesh C wrote: > > > > Here is a small improvisation where num_slots need not be initialized > > as it will be used only after assigning the result now.

Re: Improve tab completion for ALTER DEFAULT PRIVILEGE and ALTER TABLE

On Mon, Nov 27, 2023 at 9:58 PM vignesh C wrote: > > On Fri, 24 Nov 2023 at 18:37, Shubham Khanna > wrote: > > > > n Fri, Nov 24, 2023 at 6:33 PM vignesh C wrote: > > > > > > Hi, > > > > > > Improved tab completion for "ALTER DEFAULT PRIVILEGE" and "ALTER TABLE": > > > 1) GRANT, REVOKE and FOR

Re: remaining sql/json patches

On Mon, Nov 27, 2023 at 8:57 PM Andrew Dunstan wrote: > Interesting. But inferring a speed effect from such changes is > difficult. I don't have a good idea about measuring parser speed, but a > tool to do that would be useful. Amit has made a start on such > measurements, but it's only a start.

Re: New instability in stats regression test

On Sun, Nov 26, 2023 at 10:34:59PM -0500, Tom Lane wrote: > I'm good with that answer --- I doubt that this test sequence is > proving anything that's worth the cycles it takes. If it'd catch > oversights like failing to add new stats types to the "reset all" > code path, then I'd be for keeping

Re: SSL tests fail on OpenSSL v3.2.0

Michael Paquier writes: > Or even simpler: plant a (ssl\/tls|sslv3) in these strings. Yeah, weakening the pattern match was what I had in mind. I was thinking of something like "ssl[a-z0-9/]*" but your proposal works too. regards, tom lane

Re: SSL tests fail on OpenSSL v3.2.0

On Tue, Nov 28, 2023 at 12:55:37PM +0900, Michael Paquier wrote: > Sigh. We could use an extra check_pg_config() with a routine new in > 3.2.0. Looking at CHANGES.md, SSL_get0_group_name() seems to be one > generic choice here. Or even simpler: plant a (ssl\/tls|sslv3) in these strings. --

Re: POC, WIP: OR-clause support for indexes

On Mon, Nov 27, 2023 at 5:07 PM Peter Geoghegan wrote: > One of the reasons why we shouldn't do this during parse analysis is > because query rewriting might matter. But that doesn't mean that the > transformation/normalization process must fundamentally be the > responsibility of the optimizer,

Re: SSL tests fail on OpenSSL v3.2.0

On Mon, Nov 27, 2023 at 09:04:23PM -0500, Tom Lane wrote: > I can confirm that we also fail when using up-to-date MacPorts, which > seems to have started shipping 3.2.0 last week or so. I tried the v3 > patch, and while that stops the crash, it looks like 3.2.0 has also > made some random changes

Re: POC, WIP: OR-clause support for indexes

On 25.11.2023 19:13, Alexander Korotkov wrote: On Sat, Nov 25, 2023 at 1:10 PM Alena Rybakina wrote: On 25.11.2023 04:13, Alexander Korotkov wrote: It seems to me there is a confusion. I didn't mean we need to move conversion of OR-expressions to ANY into choose_bitmap_and() function or

Re: SSL tests fail on OpenSSL v3.2.0

On Mon, Nov 27, 2023 at 08:32:28PM -0500, Tom Lane wrote: > Since this is something we'd need to back-patch, OpenSSL 0.9.8 > and later are relevant: the v12 branch still supports those. > It's moot given Bo's claim about the origin of the function, > though. Yep, unfortunately this needs to be

Re: [PATCH] psql: Add tab-complete for optional view parameters

On Thu, Nov 23, 2023 at 4:37 PM Dean Rasheed wrote: > > On Mon, 14 Aug 2023 at 18:34, David Zhang wrote: > > > > it would be great to switch the order of the 3rd and the 4th line to make a > > better match for "CREATE" and "CREATE OR REPLACE" . > > > > I took a look at this, and I think it's

Re: Synchronizing slots from primary to standby

On Mon, Nov 27, 2023 at 4:08 PM Amit Kapila wrote: > > On Mon, Nov 27, 2023 at 2:27 PM Zhijie Hou (Fujitsu) > wrote: > > > > Here is the updated version(v39_2) which include all the changes made in > > 0002. > > Please use for review, and sorry for the confusion. > > > > ---

Re: proposal: change behavior on collation version mismatch

On Mon, 2023-11-27 at 15:35 -0800, Jeremy Schneider wrote: > For many enterprise customers, if they ask why their database > wouldn't accept connections after an OS upgrade and we explained that > durability & correctness is prioritized over availability, I think > they would agree we're doing

Re: SSL tests fail on OpenSSL v3.2.0

I can confirm that we also fail when using up-to-date MacPorts, which seems to have started shipping 3.2.0 last week or so. I tried the v3 patch, and while that stops the crash, it looks like 3.2.0 has also made some random changes in error messages: # +++ tap check in src/test/ssl +++

Re: Testing autovacuum wraparound (including failsafe)

On Mon, Nov 27, 2023 at 10:40 PM Daniel Gustafsson wrote: > > > On 27 Nov 2023, at 14:06, Masahiko Sawada wrote: > > > Is it true that we can modify the timeout after creating > > BackgroundPsql object? If so, it seems we don't need to introduce the > > new timeout argument. But how? > > I can't

Re: remaining sql/json patches

On Thu, Nov 23, 2023 at 6:46 PM jian he wrote: > > -however these four will not fail. > SELECT JSON_QUERY(jsonb '{"a":[3,4]}', '$.z' RETURNING int4range empty > object on error); > SELECT JSON_QUERY(jsonb '{"a":[3,4]}', '$.z' RETURNING int4range empty > array on error); > SELECT

Re: SSL tests fail on OpenSSL v3.2.0

"Tristan Partin" writes: > On Mon Nov 27, 2023 at 7:14 PM CST, Tom Lane wrote: >> ... If the function >> does exist in 0.9.8 then I concur that we don't need to test. > I have gone back all the way to 1.0.0 and confirmed that the function > exists. Didn't choose to go further than that since

Re: SSL tests fail on OpenSSL v3.2.0

On Mon Nov 27, 2023 at 7:14 PM CST, Tom Lane wrote: "Tristan Partin" writes: > On Mon Nov 27, 2023 at 6:21 PM CST, Tom Lane wrote: >> What about LibreSSL? In general, I'm not too pleased with just assuming >> that BIO_get_app_data exists. > Falling back to what existed before is invalid.

BackgroundPsql's set_query_timer_restart() may not work

Hi, While adding some TAP tests, I realized that set_query_timer_restart() in BackgroundPsql may not work. Specifically, it seems not to work unless we pass an argument to the function. Here is the test script I used: use strict; use warnings; use PostgreSQL::Test::Cluster; use

Re: [PATCH] pg_convert improvement

Hi Bertrand, > Did some minor changes in the attached: > > - Started the multi-line comment with an upper case and finished > it with a "." and re-worded a bit. > - Ran pgindent > > What do you think about the attached? > It looks great! > > Also, might be good to create a CF entry [1] so

Re: SSL tests fail on OpenSSL v3.2.0

"Tristan Partin" writes: > On Mon Nov 27, 2023 at 6:21 PM CST, Tom Lane wrote: >> What about LibreSSL? In general, I'm not too pleased with just assuming >> that BIO_get_app_data exists. > Falling back to what existed before is invalid. Well, sure it only worked by accident, but it did work

Re: POC, WIP: OR-clause support for indexes

On Mon, Nov 27, 2023 at 4:07 PM Robert Haas wrote: > > I am sure that there is a great deal of truth to this. The general > > conclusion about parse analysis being the wrong place for this seems > > very hard to argue with. But I'm much less sure that there needs to be > > a conventional cost

Re: GUC names in messages

Here is patch set v3. Patches 0001 and 0002 are unchanged from v2. Patch 0003 now uses a "%s%s%s" format specifier with GUC_FORMAT macro in guc.c, as recently suggested by Michael [1]. ~ (Meanwhile, the MixedCase stuff is still an open question, to be addressed in a later patch version)

Re: autovectorize page checksum code included elsewhere

Hi, On 2023-11-25 14:09:14 +0700, John Naylor wrote: > * Note: I have seen the threads with the idea of compiling multiple > entire binaries, and switching at postmaster start. I think it's a > good idea, but I also suspect detecting flags from the packager is an > easier intermediate step. It's

Re: SSL tests fail on OpenSSL v3.2.0

On Mon Nov 27, 2023 at 6:21 PM CST, Tom Lane wrote: Michael Paquier writes: > Interesting. I have yet to look at that in details, but > BIO_get_app_data() exists down to 0.9.8, which is the oldest version > we need to support for stable branches. So that looks like a safe > bet. What about

Re: SSL tests fail on OpenSSL v3.2.0

Michael Paquier writes: > Interesting. I have yet to look at that in details, but > BIO_get_app_data() exists down to 0.9.8, which is the oldest version > we need to support for stable branches. So that looks like a safe > bet. What about LibreSSL? In general, I'm not too pleased with just

Re: POC, WIP: OR-clause support for indexes

On Mon, Nov 27, 2023 at 5:16 PM Peter Geoghegan wrote: > [ various observations ] This all seems to make sense but I don't have anything particular to say about it. > I am sure that there is a great deal of truth to this. The general > conclusion about parse analysis being the wrong place for

Re: POC, WIP: OR-clause support for indexes

On Mon, 27 Nov 2023, 23:16 Peter Geoghegan, wrote: > On Mon, Nov 27, 2023 at 1:04 PM Robert Haas wrote: > > The use of op_mergejoinable() seems pretty random to me. Why should we > > care about that? If somebody writes a<1 or a<2 or a<3 or a<4, you can > > transform that to a > good idea, but I

Re: SSL tests fail on OpenSSL v3.2.0

On Mon Nov 27, 2023 at 5:53 PM CST, Michael Paquier wrote: On Mon, Nov 27, 2023 at 12:33:49PM -0600, Tristan Partin wrote: > -#ifndef HAVE_BIO_GET_DATA > -#define BIO_get_data(bio) (bio->ptr) > -#define BIO_set_data(bio, data) (bio->ptr = data) > -#endif Shouldn't this patch do a refresh of

Re: SSL tests fail on OpenSSL v3.2.0

On Mon, Nov 27, 2023 at 12:33:49PM -0600, Tristan Partin wrote: > - res = secure_raw_read(((Port *) BIO_get_data(h)), buf, size); > + res = secure_raw_read(((Port *) BIO_get_app_data(h)), buf, > size); > BIO_clear_retry_flags(h); > if (res <= 0)

Re: Partial aggregates pushdown

First of all, that last email of mine was snippy, and I apologize for it. Sorry. That said: On Mon, Nov 27, 2023 at 4:23 PM Tom Lane wrote: > Well, one of the founding principles of postgres_fdw was to be able > to talk to PG servers that are not of the same version as yours. > If we break that

Re: Incorrect comment in tableam.h regarding GetHeapamTableAmRoutine()

On Mon, Nov 27, 2023 at 02:14:32PM +0800, Richard Guo wrote: > +1. Nice catch. Thanks, applied it. -- Michael signature.asc Description: PGP signature

Re: [PATCH] Add CHECK_FOR_INTERRUPTS in scram_SaltedPassword loop.

On Mon, Nov 27, 2023 at 10:05:49AM +0100, Daniel Gustafsson wrote: > I don't see any reason to backpatch further down than 16 given how low the > hardcoded value is set there, scanning the archives I see no complaints about > it either. As a reference, CREATE ROLE using 4096 iterations takes 14ms

Re: proposal: change behavior on collation version mismatch

On 11/27/23 12:29 PM, Jeff Davis wrote: >> 2) "most users would rather have ease-of-use than 100% safety, since >> it's uncommon" >> >> And I think this led to the current behavior of issuing a warning >> rather >> than an error > The elevel trade-off is *availability* vs safety, not ease-of-use

Re: Don't use bms_membership in places where it's not needed

On Tue, 28 Nov 2023 at 11:21, Andres Freund wrote: > Hm, does this ever matter from a performance POV? The current code does look > simpler to read to me. If the overhead is relevant, I'd instead just move the > code into a static inline? I didn't particularly find the code in examine_variable()

Re: GUC names in messages

On Mon, Nov 27, 2023 at 01:35:44AM -0500, Tom Lane wrote: > Laurenz Albe writes: > > On Mon, 2023-11-27 at 13:41 +1100, Peter Smith wrote: >>> In the documentation and in the guc_tables.c they are all described in >>> MixedCase (e.g. "DateStyle" instead of "datestyle"), so I felt the >>> messages

Re: New instability in stats regression test

On Mon, Nov 27, 2023 at 02:01:51PM -0500, Tom Lane wrote: > The problem as I see it is that this test: > > SELECT :io_stats_post_reset < :io_stats_pre_reset; > > requires an assumption that less I/O has happened since the commanded > reset action than happened before it (extending back to the

Re: Adding facility for injection points (or probe points?) for more advanced tests

On Mon, Nov 27, 2023 at 12:14:05PM +0530, Ashutosh Bapat wrote: > Since you wroten "(still need to improve ...) I thought you are > working on v6. No problem. Sorry for the confusion. I see why my previous message could be confusing. Sorry about that. -- Michael signature.asc Description: PGP

Re: Dynamically generate a nested JSON file

On Mon, Nov 27, 2023 at 2:10 PM Rushabh Shah wrote: > > I want to dynamically generate a nested json file. I have written a > function for it in PL/PGSQL that accepts 3 arrays. First one is an array of > all json fields, second one is an array of all json fields with columns > from tables

Re: autovectorize page checksum code included elsewhere

On Mon, Nov 27, 2023 at 03:21:53PM -0600, Nathan Bossart wrote: > On Sat, Nov 25, 2023 at 02:09:14PM +0700, John Naylor wrote: >> Sorry, I wasn't clear, I mean: detect that a packager passed >> "-march=x86_64-v2" in the CFLAGS, so that a symbol in header files >> would cause inlining of functions

Re: proposal: change behavior on collation version mismatch

On Mon, 2023-11-27 at 22:37 +0100, Magnus Hagander wrote: > That is, set it to "warnings only", insert a single row into the > table > with an "unlucky" key, set it back to "errors always" and you now > have > a corrupt database, but your setting reflects that it shouldn't be > corrupt. You would

Re: Don't use bms_membership in places where it's not needed

Hi, On 2023-11-24 17:06:25 +1300, David Rowley wrote: > While working on the patch in [1], I noticed that ever since > 00b41463c, it's now suboptimal to do the following: > > switch (bms_membership(relids)) > { > case BMS_EMPTY_SET: >/* handle empty set */ >break; > case

Re: common signal handler protection

Thanks for taking a look. On Wed, Nov 22, 2023 at 02:59:45PM -0800, Andres Freund wrote: > On 2023-11-22 15:59:44 -0600, Nathan Bossart wrote: >> +/* >> + * Except when called with SIG_IGN or SIG_DFL, pqsignal() sets up this >> function >> + * as the handler for all signals. This wrapper

Re: POC, WIP: OR-clause support for indexes

On Mon, Nov 27, 2023 at 1:04 PM Robert Haas wrote: > The use of op_mergejoinable() seems pretty random to me. Why should we > care about that? If somebody writes a<1 or a<2 or a<3 or a<4, you can > transform that to a good idea, but I think it's a legal transformation. That kind of

Re: logical decoding and replication of sequences, take 2

FWIW, here are some more minor review comments for v20231127-3-0001 == doc/src/sgml/logicaldecoding.sgml 1. + The txn parameter contains meta information about + the transaction the sequence change is part of. Note however that for + non-transactional updates, the transaction

Re: Don't use bms_membership in places where it's not needed

On Fri, 24 Nov 2023 at 19:54, Richard Guo wrote: > +1 to the idea. > > I think you have a typo in distribute_restrictinfo_to_rels. We should > remove the call of bms_singleton_member and use relid instead. Thanks for reviewing. I've now pushed this. David

Re: proposal: change behavior on collation version mismatch

On Mon, Nov 27, 2023 at 9:30 PM Jeff Davis wrote: > > On Mon, 2023-11-27 at 11:06 -0800, Jeremy Schneider wrote: > > If we want to have a GUC that > > allows warning behavior, I think that's OK but I think it should be > > superuser-only and documented as a "developer" setting similar to > >

Re: Partial aggregates pushdown

Robert Haas writes: > On Mon, Nov 27, 2023 at 3:59 PM Tom Lane wrote: >> TBH, I think this entire proposal is dead in the water. Which is >> sad from a performance standpoint, but I can't see any way that >> we would not regret shipping a feature that makes such assumptions. > I think it's

Re: autovectorize page checksum code included elsewhere

On Sat, Nov 25, 2023 at 02:09:14PM +0700, John Naylor wrote: > On Thu, Nov 23, 2023 at 11:51 PM Nathan Bossart > wrote: >> >> On Thu, Nov 23, 2023 at 05:50:48PM +0700, John Naylor wrote: >> > On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart >> > wrote: >> >> One half-formed idea I have is to

Re: Partial aggregates pushdown

On Mon, Nov 27, 2023 at 3:59 PM Tom Lane wrote: > Even if the partial-aggregate serialization value isn't "internal" > but some more-narrowly-defined type, it is still an internal > implementation detail of the aggregate. You have no right to assume > that the remote server implements the

Dynamically generate a nested JSON file

Hi, I want to dynamically generate a nested json file. I have written a function for it in PL/PGSQL that accepts 3 arrays. First one is an array of all json fields, second one is an array of all json fields with columns from tables present in db, third one mentions the type for all the fields

Re: Missing docs on AT TIME ZONE precedence?

On 2023-11-27 Mo 15:34, Tom Lane wrote: Alvaro Herrera writes: (TBH I don't think the added comments really explain the problems fully. That's most likely because I don't actually understand what the problems are.) The actual problem is that nobody has applied a cluestick to the SQL

Re: POC, WIP: OR-clause support for indexes

On Mon, Nov 27, 2023 at 3:02 AM Andrei Lepikhov wrote: > On 25/11/2023 08:23, Alexander Korotkov wrote: > > I think patch certainly gets better in this aspect. One thing I can't > > understand is why do we use home-grown code for resolving > > hash-collisions. You can just define custom hash

Re: locked reads for atomics

Here's a v2 of the patch set in which I've attempted to address all feedback. I've also added a pg_write_membarrier_u* pair of functions that provide an easy way to write to an atomic variable with full barrier semantics. In the generic implementation, these are just aliases for an atomic

Re: Partial aggregates pushdown

Robert Haas writes: > Also, I want to make one other point here about security and > reliability. Right now, there is no way for a user to feed arbitrary > data to a deserialization function. Since serialization and > deserialization functions are only used in the context of parallel > query, we

Re: proposal: change behavior on collation version mismatch

On Mon, 2023-11-27 at 20:19 +0100, Laurenz Albe wrote: > I forgot to add that the problem will remain a problem until the > day we start keeping our own copy of the ICU library in the source > tree... Another option is for packagers to keep specific ICU versions around for an extended time, and

Re: Missing docs on AT TIME ZONE precedence?

Alvaro Herrera writes: > (TBH I don't think the added comments really explain the problems fully. > That's most likely because I don't actually understand what the problems > are.) The actual problem is that nobody has applied a cluestick to the SQL committee about writing an unambiguous grammar

Re: proposal: change behavior on collation version mismatch

On Mon, 2023-11-27 at 11:06 -0800, Jeremy Schneider wrote: > I've been tracking the discussions around collation here on the lists > and I've had a number of conversations with folks working deeply in > this > area inside and outside of AWS, and I was part of the effort to > address > it at AWS

Re: Table AM Interface Enhancements

> On Nov 25, 2023, at 9:47 AM, Alexander Korotkov wrote: > >> Should the patch at least document which parts of the EState are expected to >> be in which states, and which parts should be viewed as undefined? If the >> implementors of table AMs rely on any/all aspects of EState, doesn't

Re: Partial aggregates pushdown

On Wed, Nov 22, 2023 at 5:16 AM fujii.y...@df.mitsubishielectric.co.jp wrote: > I did not choose Approach2 because I was not confident that the disadvantage > mentioned in 2.(2)(a) > would be accepted by the PostgreSQL development community. > If it is accepted, I think Approach 2 is smarter. >

Re: proposal: change behavior on collation version mismatch

I forgot to add that the problem will remain a problem until the day we start keeping our own copy of the ICU library in the source tree... Yours, Laurenz Albe

Re: proposal: change behavior on collation version mismatch

On Mon, 2023-11-27 at 11:06 -0800, Jeremy Schneider wrote: > First: I'd suggest that a collation version mismatch should cause an > ERROR rather than a WARNING by default. If we want to have a GUC that > allows warning behavior, I think that's OK but I think it should be > superuser-only and

Re: Do away with a few backwards compatibility macros

On Mon, Nov 27, 2023 at 04:29:18PM +0530, Bharath Rupireddy wrote: > I think it's easy to miss/enforce a documented policy. IMV, moving > towards pg_attribute_deprecated as Alvaro Herrera said in the other > thread > https://www.postgresql.org/message-id/202311141920.edtj56saukiv%40alvherre.pgsql

Re: Partial aggregates pushdown

On Wed, Nov 22, 2023 at 1:32 AM Alexander Pyhalov wrote: > Hi. HAVING is also a problem. Consider the following query > > SELECT count(a) FROM t HAVING count(a) > 10 - we can't push it down to > foreign server as HAVING needs full aggregate result, but foreign server > don't know it. I don't see

proposal: change behavior on collation version mismatch

I had some interesting conversations with a couple PostgreSQL community members at PASS Data Summit the week before last about the collation problem, and then - just in this last week - I saw two more people on public channels hitting corruption problems. One person on the public PostgreSQL Slack,

Re: trying again to get incremental backup

On Thu, Nov 23, 2023 at 11:18 PM Thomas Munro wrote: > Robert pinged me to see if I had any ideas. Thanks, Thomas. > The reason it fails on Windows is because there is a special code path > for WIN32 in the patch's src/bin/pg_combinebackup/copy_file.c, but it > is incomplete: it returns early

Re: New instability in stats regression test

Andres Freund writes: > I am probably under-caffeinated: What precisely is the potential race? Just > that the timestamps on some system might not be granular enough? The problem as I see it is that this test: SELECT :io_stats_post_reset < :io_stats_pre_reset; requires an assumption that less

Re: Add recovery to pg_control and remove backup_label

On Sun, Nov 26, 2023 at 3:42 AM Stephen Frost wrote: > What would really be helpful would be hearing from these individuals > directly as to what the issues are with the changes, such that perhaps > we can do things better in the future to avoid whatever the issue is > they're having with the

Re: Assert failure on 'list_member_ptr(rel->joininfo, restrictinfo)'

On Mon, Nov 27, 2023 at 8:07 PM Andres Freund wrote: > > On 2023-11-27 11:29:48 +0530, Ashutosh Bapat wrote: > > How do we ensure that we are not making unnecessary copies of Bitmapsets? > > We don't - but that's not specific to this patch. Bitmapsets typically aren't > very large, I doubt that

Re: SSL tests fail on OpenSSL v3.2.0

Here is a v2 which adds back a comment that was not meant to be removed. -- Tristan Partin Neon (https://neon.tech) From 4bcb73eab9ceba950581a890c52820a81134f7e4 Mon Sep 17 00:00:00 2001 From: Tristan Partin Date: Mon, 27 Nov 2023 11:49:52 -0600 Subject: [PATCH v2] Use BIO_{get,set}_app_data()

Re: SSL tests fail on OpenSSL v3.2.0

Nazir, Thanks for opening a thread. Was just about to start one, here what we came up with so far. Homebrew users discovered a regression[0] when using Postgres compiled and linked against OpenSSL version 3.2. $ psql "postgresql://$DB?sslmode=require" psql: error: connection to server at

Re: Assert failure on 'list_member_ptr(rel->joininfo, restrictinfo)'

On 2023-11-27 11:29:48 +0530, Ashutosh Bapat wrote: > How do we ensure that we are not making unnecessary copies of Bitmapsets? We don't - but that's not specific to this patch. Bitmapsets typically aren't very large, I doubt that it's a significant proportion of the memory usage. Adding

SSL tests fail on OpenSSL v3.2.0

Hi, SSL tests fail on OpenSSL v3.2.0. I tested both on macOS (CI) and debian (my local) and both failed with the same errors. To trigger these errors on CI, you may need to clear the repository cache; otherwise macOS won't install the v3.2.0 of the OpenSSL. 001_ssltests: psql exited with signal

Re: New instability in stats regression test

Hi, On 2023-11-27 11:56:19 +0900, Michael Paquier wrote: > I was ready to argue that we'd better keep this test and keep it close > to the end of stats.sql while documenting why things are kept in this > order, but two resets done on the same shared stats type would still > be prone to race

Re: New instability in stats regression test

Hi, On 2023-11-27 15:49:01 +0530, Bharath Rupireddy wrote: > On Mon, Nov 27, 2023 at 8:26 AM Michael Paquier wrote: > > but two resets done on the same shared stats type would still > > be prone to race conditions without all the previous activity done in > > the tests (like pg_stat_wal). > >

Re: remaining sql/json patches

Hi, On 2023-11-27 15:06:12 +0100, Alvaro Herrera wrote: > On 2023-Nov-27, Andrew Dunstan wrote: > > > Interesting. But inferring a speed effect from such changes is difficult. I > > don't have a good idea about measuring parser speed, but a tool to do that > > would be useful. Amit has made a

Re: Missing docs on AT TIME ZONE precedence?

We could do something like this. Is this good? I tried to merge WITH and WITHOUT with the precedence class immediately above, but that failed: the main grammar compiles fine and no tests fail, but ECPG does fail to compile the sqljson.pgc test, so there's some problem there. Now, the ecpg

Re: walwriter interacts quite badly with synchronous_commit=off

On 2023-11-27 17:55:34 +0200, Heikki Linnakangas wrote: > On 25/10/2023 21:59, Andres Freund wrote: > > > See attached. It's the same logic as in your patch, just formulatd more > > > clearly IMHO. > > Yep, makes sense! > > Pushed this. Thanks for the investigation! Thanks!

Re: Missing docs on AT TIME ZONE precedence?

On 2023-Nov-26, Tom Lane wrote: > I am, however, feeling a little bit on the warpath about the > grammar comments for the SQL/JSON keyword precedences: > > /* SQL/JSON related keywords */ > %nonassoc UNIQUE JSON > %nonassoc KEYS OBJECT_P SCALAR VALUE_P > %nonassoc WITH WITHOUT > >

Re: PATCH: Add REINDEX tag to event triggers

On Mon, Nov 27, 2023 at 6:58 PM Ajin Cherian wrote: > > I just started reviewing the patch. Some minor comments: > In patch 0001: > In standard_ProcessUtility(), since you are unconditionally calling > ProcessUtilitySlow() in case of T_ReindexStmt, you really don't need > the case statement for

Re: Improve tab completion for ALTER DEFAULT PRIVILEGE and ALTER TABLE

On Fri, 24 Nov 2023 at 18:37, Shubham Khanna wrote: > > n Fri, Nov 24, 2023 at 6:33 PM vignesh C wrote: > > > > Hi, > > > > Improved tab completion for "ALTER DEFAULT PRIVILEGE" and "ALTER TABLE": > > 1) GRANT, REVOKE and FOR USER keyword was not displayed in tab > > completion of alter default

Re: walwriter interacts quite badly with synchronous_commit=off

On 25/10/2023 21:59, Andres Freund wrote: See attached. It's the same logic as in your patch, just formulatd more clearly IMHO. Yep, makes sense! Pushed this. Thanks for the investigation! -- Heikki Linnakangas Neon (https://neon.tech)

Re: brininsert optimization opportunity

On 11/27/23 11:34, Tomas Vondra wrote: > > > On 11/27/23 08:37, Richard Guo wrote: >> >> On Mon, Nov 27, 2023 at 1:53 PM Soumyadeep Chakraborty >> mailto:soumyadeep2...@gmail.com>> wrote: >> >> On Sun, Nov 26, 2023 at 9:28 PM Richard Guo > > wrote: >> >

Re: Add semi-join pushdown to postgres_fdw

Alexander Korotkov писал(а) 2023-11-27 03:49: Thank you for the revision. I've revised the patch myself. I've replaced StringInfo with additional conds into a list of strings as I proposed before. I think the code became much clearer. Also, it gets rid of some unnecessary allocations. I

Re: Questions regarding Index AMs and natural ordering

On Fri, 24 Nov 2023, 19:58 Tom Lane, wrote: > > Peter Geoghegan writes: > > On Fri, Nov 24, 2023 at 8:44 AM Matthias van de Meent > > wrote: > >> Yes, the part where btree opclasses determine a type's ordering is > >> clear. But what I'm looking for is "how do I, as an index AM > >>

Re: pgoutput incorrectly replaces missing values with NULL since PostgreSQL 15

Thank you for turning this around so quickly!

Re: Synchronizing slots from primary to standby

Hi, On 11/27/23 1:23 PM, Zhijie Hou (Fujitsu) wrote: On Monday, November 27, 2023 8:05 PM Drouvot, Bertrand wrote: Hi, On 11/6/23 2:30 AM, Zhijie Hou (Fujitsu) wrote: On Friday, November 3, 2023 7:32 PM Amit Kapila I don't see a corresponding change in repl_gram.y. I think the

Re: remaining sql/json patches

On 2023-Nov-27, Andrew Dunstan wrote: > Interesting. But inferring a speed effect from such changes is difficult. I > don't have a good idea about measuring parser speed, but a tool to do that > would be useful. Amit has made a start on such measurements, but it's only a > start. I'd prefer to

Re: Random pg_upgrade test failure on drongo

On 2023-11-27 Mo 07:39, Andrew Dunstan wrote: On 2023-11-27 Mo 07:00, Alexander Lakhin wrote: Hello Kuroda-san, 25.11.2023 18:19, Hayato Kuroda (Fujitsu) wrote: Thanks for attaching a program. This helps us to understand the issue. I wanted to confirm your env - this failure was occurred

Re: remaining sql/json patches

On 2023-11-27 Mo 05:42, Alvaro Herrera wrote: On 2023-Nov-27, Amit Langote wrote: For example, the jump between 13 and 14 looks worse. (I do wonder what happened there.) The following commit sounds like it might be related? Yes, but not only that one. I did some more trolling in the

Re: logical decoding and replication of sequences, take 2

On 11/27/23 13:08, Hayato Kuroda (Fujitsu) wrote: > Dear Amit, Tomas, > I am wondering that instead of building the infrastructure to know whether a particular change is transactional on the decoding side, can't we have some flag in the WAL record to note whether the change

Re: logical decoding and replication of sequences, take 2

On 11/27/23 12:11, Amit Kapila wrote: > On Mon, Nov 27, 2023 at 4:17 PM Tomas Vondra > wrote: >> >> On 11/27/23 11:13, Amit Kapila wrote: >>> On Mon, Nov 27, 2023 at 11:34 AM Amit Kapila >>> wrote: On Mon, Nov 27, 2023 at 6:41 AM Tomas Vondra wrote: > > While going

Re: Testing autovacuum wraparound (including failsafe)

> On 27 Nov 2023, at 14:06, Masahiko Sawada wrote: > Is it true that we can modify the timeout after creating > BackgroundPsql object? If so, it seems we don't need to introduce the > new timeout argument. But how? I can't remember if that's leftovers that incorrectly remains from an earlier

  1   2   >