Re:Re: Re: Re: Add support to TLS 1.3 cipher suites and curves lists

Hi Jelte and Daniel, Based on my understanding currently there is no setting that controls the cipher choices used by TLS version 1.3 connections but the default value(HIGH:MEDIUM:+3DES:!aNULL) is used. So if I want to connect to Postgres (eg. Postgres 14) with different TLS versions of custom

RE: Doc: fix a description regarding WAL summarizer on glossary page

>> While searching the definition of auxiliary processes, I noticed that >> the description of the WAL summarizer is incorrect. Additionally, I >> think it's better to add a description for the WAL writer similar to >> other Auxiliary processes. What do you think? > > Good catch. Would you like to

Re: Logical Replication of sequences

On Wed, Jun 12, 2024 at 6:59 PM Amit Kapila wrote: > > On Wed, Jun 12, 2024 at 10:44 AM Masahiko Sawada > wrote: > > > > On Tue, Jun 11, 2024 at 7:36 PM vignesh C wrote: > > > > > > 1) CREATE PUBLICATION syntax enhancement: > > > CREATE PUBLICATION ... FOR ALL SEQUENCES; > > > The addition of a

Re: Changing default -march landscape

On 13.06.24 04:00, Nathan Bossart wrote: That's true, but my point is that as soon as we start avoiding function pointers more commonly, it becomes difficult to justify adding them back in order to support new instruction sets. Should we just compile in the SSE 4.2 version, or should we take a c

Re: Proposal: Document ABI Compatibility

On 12.06.24 16:47, Robert Haas wrote: On Mon, Jun 3, 2024 at 3:39 PM Tom Lane wrote: Me either. There are degrees of ABI compatibility Exactly this! What I think would be useful to document is our usual practices e.g. adding new struct members at the end of structs, trying to avoid changing

Pluggable cumulative statistics

Hi all, While looking at ways to make pg_stat_statements more scalable and dynamically manageable (no more PGC_POSTMASTER for the max number of entries), which came out as using a dshash, Andres has mentioned me off-list (on twitter/X) that we'd better plug in it to the shmem pgstats facility, mov

Re: Doc: fix a description regarding WAL summarizer on glossary page

On Thu, Jun 13, 2024 at 07:24:10AM +, masahiro.ik...@nttdata.com wrote: > Thanks for your response. Please take a look at the attached patch. > I've confirmed that it passes all tests. Thanks for the patch. Will check and apply. -- Michael signature.asc Description: PGP signature

Re: Incorrect matching of sql/json PASSING variable names

On Thu, Jun 6, 2024 at 6:20 PM Amit Langote wrote: > > Hi, > > Alvaro reported off-list that the following should really fail, > because the jsonpath expression refers to a PASSING variable that > doesn't exist: > > select json_query('"1"', jsonpath '$xy' passing 2 AS xyz); > json_query > ---

Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

Hi, Please find the attached patch addressing all the comments. I kindly request your review and feedback. Your thoughts are greatly appreciated. -- With Regards, Ashutosh Sharma. v3-0001-Introduce-a-new-control-file-flag-called-protected-f.patch Description: Binary data

Re: Changing default -march landscape

On Thu, Jun 13, 2024 at 9:41 AM Peter Eisentraut wrote: > On 13.06.24 04:00, Nathan Bossart wrote: > > That's true, but my point is that as soon as we start avoiding function > > pointers more commonly, it becomes difficult to justify adding them back > in > > order to support new instruction set

Re: Proposal to add page headers to SLRU pages

> On Jun 10, 2024, at 16:01, Michael Paquier wrote: > > External Email > > From: Michael Paquier > Subject: Re: Proposal to add page headers to SLRU pages > Date: June 10, 2024 at 16:01:50 GMT+8 > To: Bertrand Drouvot > Cc: "Li, Yong" , Jeff Davis , Aleksander > Alekseev , PostgreSQL Hacker

Re: Show WAL write and fsync stats in pg_stat_io

Hi, Thank you for looking into this! And, sorry for the late answer. On Mon, 13 May 2024 at 17:12, Bharath Rupireddy wrote: > > On Fri, Apr 19, 2024 at 1:32 PM Nazir Bilal Yavuz wrote: > > > > > I wanted to inform you that the 73f0a13266 commit changed all WALRead > > > calls to read variable b

Re: Optimize numeric.c mul_var() using the Karatsuba algorithm

On Tue, Jun 11, 2024, at 19:16, Aaron Altman wrote: > Hi Joel, thanks for posting this.  Although I have only a cursory > familiarity with fast multiplication algorithms, I'd like to try and > give it a review.  To start with, can you help me understand the choice > of this algorithm versus othe

Re: Show WAL write and fsync stats in pg_stat_io

Hi, Thank you for looking into this! On Sun, 9 Jun 2024 at 18:05, Nitin Jadhav wrote: > > > If possible, let's have all the I/O stats (even for WAL) in > > pg_stat_io. Can't we show the WAL data we get from buffers in the hits > > column and then have read_bytes or something like that to know th

Re: RFC: adding pytest as a supported test framework

> On 13 Jun 2024, at 00:34, Melanie Plageman wrote: > FWIW, I felt a lot of pain trying to write recovery TAP tests with > IPC::Run's pumping functionality. It was especially painful (as > someone who knows even less Perl than the "street fighting Perl" > Thomas Munro has described having) before

Re: Conflict Detection and Resolution

On Thu, Jun 13, 2024 at 11:41 AM Masahiko Sawada wrote: > > On Wed, Jun 5, 2024 at 3:32 PM Zhijie Hou (Fujitsu) > wrote: > > > > Hi, > > > > This time at PGconf.dev[1], we had some discussions regarding this > > project. The proposed approach is to split the work into two main > > components. The

Re: CI and test improvements

Hi, Thanks for working on this! On Wed, 12 Jun 2024 at 16:10, Justin Pryzby wrote: > > On Fri, Jun 24, 2022 at 08:38:50AM +1200, Thomas Munro wrote: > > > I've also sent some patches to Thomas for cfbot to help progress some of > > > these > > > patches (code coverage and documentation upload a

Re: Improve the granularity of PQsocketPoll's timeout parameter?

Em qua., 12 de jun. de 2024 às 16:45, Tom Lane escreveu: > I wrote: > > v3 attached uses pg_usec_time_t, and fixes one brown-paper-bag > > bug the cfbot noticed in v2. > > Oh, I just remembered that there's a different bit of > pqConnectDBComplete that we could simplify now: > > if (timeo

Re: CI and test improvements

On Thu, Jun 13, 2024 at 02:38:46PM +0300, Nazir Bilal Yavuz wrote: > On Wed, 12 Jun 2024 at 16:10, Justin Pryzby wrote: > > On Fri, Jun 24, 2022 at 08:38:50AM +1200, Thomas Munro wrote: > > > > I've also sent some patches to Thomas for cfbot to help progress some > > > > of these > > > > patches

Re: Track the amount of time waiting due to cost_delay

Hi, On Tue, Jun 11, 2024 at 08:26:23AM +, Bertrand Drouvot wrote: > Hi, > > On Tue, Jun 11, 2024 at 04:07:05PM +0900, Masahiko Sawada wrote: > > > Thank you for the proposal and the patch. I understand the motivation > > of this patch. > > Thanks for looking at it! > > > Beside the point N

Re: Add support to TLS 1.3 cipher suites and curves lists

> On 13 Jun 2024, at 09:07, Erica Zhang wrote: > How can I achieve the value for TLS1.3? Do you mean I can set the > Ciphersuites in openssl.conf, then Postgres will pick up and use this value > accordingly? Yes, you should be able to restrict the ciphersuites for TLSv1.3 with openssl.conf on

MultiXactMemberFreezeThreshold can make autovacuum *less* aggressive

The purpose of MultiXactMemberFreezeThreshold() is to make the effective autovacuum_multixact_freeze_max_age smaller, if the multixact members SLRU is approaching wraparound. Per comment there: * To prevent that, if more than a threshold portion of the members space is * used, we effectively

Re: Logical Replication of sequences

On Thu, Jun 13, 2024 at 1:09 PM Masahiko Sawada wrote: > > On Wed, Jun 12, 2024 at 6:59 PM Amit Kapila wrote: > > > > > > Yeah, starting with a single worker sounds good for now. Do you think > > we should sync all the sequences in a single transaction or have some > > threshold value above which

Re: Logical Replication of sequences

On Thu, Jun 13, 2024 at 7:06 PM Amit Kapila wrote: > > On Thu, Jun 13, 2024 at 1:09 PM Masahiko Sawada wrote: > > > > On Wed, Jun 12, 2024 at 6:59 PM Amit Kapila wrote: > > > > > > > > > Yeah, starting with a single worker sounds good for now. Do you think > > > we should sync all the sequences

Re: Conflict Detection and Resolution

On 23.05.24 08:36, shveta malik wrote: Conflict Resolution a) latest_timestamp_wins:The change with later commit timestamp wins. b) earliest_timestamp_wins: The change with earlier commit timestamp wins. c) apply: Always apply the remote change. d) skip:Remote change

Re: Conflict Detection and Resolution

On 2024-Jun-07, Tomas Vondra wrote: > On 6/3/24 09:30, Amit Kapila wrote: > > On Sat, May 25, 2024 at 2:39 AM Tomas Vondra > > wrote: > >> How is this going to deal with the fact that commit LSN and timestamps > >> may not correlate perfectly? That is, commits may happen with LSN1 < > >> LSN2 b

Re: RFC: adding pytest as a supported test framework

On Wed, Jun 12, 2024 at 6:43 PM Jelte Fennema-Nio wrote: > I agree it's not a technical issue. It is a people issue. There are > very few people skilled in Perl active in the community. And most of > those are very senior hackers that have much more important things to > do that make our Perl test

Re: Keeping track of buildfarm animals' personality

On 2024-Jun-12, Thomas Munro wrote: > On Wed, Jun 12, 2024 at 4:13 AM Andrew Dunstan wrote: > > There are two problems with this system, and have been since the get-go. > > First, owners forget to run the upgrade-personalty.pl script when the > > upgrade the OS and./or compiler. Second, there is

Re: Contributing test cases to improve coverage

On Thu, Jun 13, 2024 at 1:22 AM J F wrote: > > I am quite confused about what is the point of this. You have not > > found any actual bug, nor have you demonstrated that this test case > > could discover a likely future bug that wouldn't be detected another > > way. Moreover, it seems like the

Re: Contributing test cases to improve coverage

On 12.06.24 18:44, J F wrote: (a) The regression test suite is run by a parallel scheduler, with some test cases dependent on previous test cases. If I just add my test case as part of the parallel scheduler’s tests, it might not work, since previous test cases in the scheduler might already cr

Re: Improve the granularity of PQsocketPoll's timeout parameter?

Ranier Vilela writes: > I'm unsure if the documentation matches the code? > " connect_timeout # > > Maximum time to wait while connecting, in seconds (write as a decimal > integer, e.g., 10). Zero, negative

Re: libpq contention due to gss even when not using gss

> On Mon, Jun 10, 2024 at 11:12:12AM GMT, Andres Freund wrote: > Hi, > > To investigate a report of both postgres and pgbouncer having issues when a > lot of new connections aree established, I used pgbench -C. Oddly, on an > early attempt, the bottleneck wasn't postgres+pgbouncer, it was pgbench.

Re: Avoid orphaned objects dependencies, take 3

On Fri, Jun 7, 2024 at 4:41 AM Bertrand Drouvot wrote: > Do you still find the code hard to maintain with v9? I don't think it substantially changes my concerns as compared with the earlier version. > > but we're not similarly careful about other operations e.g. > > ConstraintSetParentConstraint

jsonpath: Missing Binary Execution Path?

Hackers, Another apparent inconsistency I’ve noticed in jsonpath queries is the treatment of the && and || operators: They can’t operate on scalar functions, only on other expressions. Some examples: david=# select jsonb_path_query('true', '$ && $'); ERROR: syntax error at or near "&&" of json

Re: MultiXactMemberFreezeThreshold can make autovacuum *less* aggressive

On Thu, Jun 13, 2024 at 8:29 AM Heikki Linnakangas wrote: > However, the value that the function calculates can sometimes be > *greater* than autovacuum_multixact_freeze_max_age. That was definitely not what I intended and is definitely bad. > In any case, I think the function > should clamp the

Re: jsonpath: Missing Binary Execution Path?

On Jun 13, 2024, at 11:32, David E. Wheeler wrote: > Should && and || not also work on scalar operands? I see the same issue for unary !, too: david=# select jsonb_path_query('true', '!$'); ERROR: syntax error at or near "$" of jsonpath input LINE 1: select jsonb_path_query('true', '!$');

Re: Improve the granularity of PQsocketPoll's timeout parameter?

Em qui., 13 de jun. de 2024 às 12:25, Tom Lane escreveu: > Ranier Vilela writes: > > I'm unsure if the documentation matches the code? > > " connect_timeout # > > < > https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-CONNECT-TIMEOUT > > > > > Maximum time to wait while con

strange context message in spi.c?

Hi I am found strange switch: <--><-->switch (carg->mode) <--><-->{ <--><--><-->case RAW_PARSE_PLPGSQL_EXPR: <--><--><--><-->errcontext("SQL expression \"%s\"", query); <--><--><--><-->break; <--><--><-->case RAW_PARSE_PLPGSQL_ASSIGN1: <--><--><-->case RAW_PARSE_PLPGSQL_ASSIGN2: <--><--><-->case

Re: MultiXactMemberFreezeThreshold can make autovacuum *less* aggressive

On 13/06/2024 17:40, Robert Haas wrote: On Thu, Jun 13, 2024 at 8:29 AM Heikki Linnakangas wrote: However, the value that the function calculates can sometimes be *greater* than autovacuum_multixact_freeze_max_age. That was definitely not what I intended and is definitely bad. In any case,

Re: libpq contention due to gss even when not using gss

Hi, On 2024-06-13 17:33:57 +0200, Dmitry Dolgov wrote: > > On Mon, Jun 10, 2024 at 11:12:12AM GMT, Andres Freund wrote: > > Hi, > > > > To investigate a report of both postgres and pgbouncer having issues when a > > lot of new connections aree established, I used pgbench -C. Oddly, on an > > earl

Re: RFC: adding pytest as a supported test framework

Robert Haas writes: > On Wed, Jun 12, 2024 at 6:43 PM Jelte Fennema-Nio wrote: >> I agree it's not a technical issue. It is a people issue. There are >> very few people skilled in Perl active in the community. And most of >> those are very senior hackers that have much more important things to >>

Re: RFC: adding pytest as a supported test framework

Jelte Fennema-Nio writes: > You don't have to be fluent in writing Python to be able to read and > understand tests written in it. [ shrug... ] I think the same can be said of Perl, with about as much basis. It matters a lot if you have previous experience with the language.

Re: Conflict Detection and Resolution

On 6/13/24 7:28 AM, Amit Kapila wrote: You are right that users would wish to detect the conflicts and probably the extra effort would only be in the 'update_differ' case where we need to consult committs module and that we will only do when 'track_commit_timestamp' is true. BTW, I think for Ins

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 11:19 AM Tom Lane wrote: > I wonder if we should be checking out some of the other newer > languages that were mentioned upthread. It feels like going to > Python here will lead to having two testing infrastructures with > mas-o-menos the same capabilities, leaving us with

Re: SQL function which allows to distinguish a server being in point in time recovery mode and an ordinary replica

Hi! Michael, I have fixed the patches according to your comments. merge both local variables into a single bits32 store? This is done in v3-0001-Standby-mode-requested.patch Then this could be used with a function that returns a text[] array with all the states retrieved? Placed this in the

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 7:27 AM Daniel Gustafsson wrote: > > > On 13 Jun 2024, at 00:34, Melanie Plageman > > wrote: > > > FWIW, I felt a lot of pain trying to write recovery TAP tests with > > IPC::Run's pumping functionality. It was especially painful (as > > someone who knows even less Perl t

Re: Avoid orphaned objects dependencies, take 3

On Thu, Jun 13, 2024 at 12:52 PM Bertrand Drouvot wrote: > > > table_open(childRelId, ...) would lock any "ALTER TABLE DROP > > > CONSTRAINT" > > > already. Not sure I understand your concern here. > > > > I believe this is not true. This would take a lock on the table, not > > the constraint it

Re: Columnar format export in Postgres

Thanks for the response. I had considered using COPY TO to export columnar data but gave up on it since the formats weren't extensible. It's great to see that you are making it extensible. I'm still going through the thread of comments on your patch but I have some early thoughts about using it f

Re: Conflict Detection and Resolution

On Thu, May 23, 2024 at 2:37 AM shveta malik wrote: > c) update_deleted: The row with the same value as that incoming > update's key does not exist. The row is already deleted. This conflict > type is generated only if the deleted row is still detectable i.e., it > is not removed by VACUUM yet. If

Re: Columnar format export in Postgres

> > If you want to have any hope, the license must be BSD. > GPL is incompatible. Ack, will update the license to BSD. Thanks On Wed, Jun 12, 2024 at 10:49 PM Ranier Vilela wrote: > Em qua., 12 de jun. de 2024 às 13:56, Sushrut Shivaswamy < > sushrut.shivasw...@gmail.com> escreveu: > >> Hey Po

Re: strange context message in spi.c?

> On 13 Jun 2024, at 19:21, Pavel Stehule wrote: > Is the message "SQL expression ..." for RAW_PLPGSQL_EXPR correct? That indeed seems incorrect. > Should there be a "PL/pgSQL expression" instead? I think that would make more sense. -- Daniel Gustafsson

Re: RFC: adding pytest as a supported test framework

On Thu, 13 Jun 2024 at 17:19, Tom Lane wrote: > I wonder if we should be checking out some of the other newer > languages that were mentioned upthread. If this is actually something that we want to seriously evaluate, I think that's a significant effort. And I think the people that want a languag

Re: Improve the granularity of PQsocketPoll's timeout parameter?

Ranier Vilela writes: > +1 for push. Done. I noticed in final review that libpq-fe.h's "#include ", which I'd feared to remove because I thought we'd shipped that already, actually was new in f5e4dedfa. So there shouldn't be anything depending on it, and I thought it best to take it out again.

Re: [multithreading] extension compatibility

On Thu, Jun 6, 2024 at 10:32 AM Heikki Linnakangas wrote: > > Well, OK, so it sounds like I'm outvoted, at least at the moment. > > Maybe that will change as more people vote, but for now, that's where > > we are. Given that, I suppose we want something more like Tristan's > > patch, but with a mo

Re: Avoid orphaned objects dependencies, take 3

Hi, On Thu, Jun 13, 2024 at 10:49:34AM -0400, Robert Haas wrote: > On Fri, Jun 7, 2024 at 4:41 AM Bertrand Drouvot > wrote: > > Do you still find the code hard to maintain with v9? > > I don't think it substantially changes my concerns as compared with > the earlier version. Thanks for the feed

Re: RFC: adding pytest as a supported test framework

On Thu, 13 Jun 2024 at 15:38, Robert Haas wrote: > For whatever reason, it seems like every piece of > infrastructure that the PostgreSQL community has suffers from severe > neglect. Literally everything I know of either has one or maybe two > very senior hackers maintaining it, or no maintainer a

improve predefined roles documentation

IMHO there are a couple of opportunities for improving the predefined roles documentation [0]: * Several of the roles in the table do not have corresponding descriptions in the paragraphs below the table (e.g., pg_read_all_data, pg_write_all_data, pg_checkpoint, pg_maintain, pg_use_reserved_

Re: Shouldn't jsonpath .string() Unwrap?

On 2024-06-12 We 16:02, David G. Johnston wrote: On Sat, Jun 8, 2024 at 3:50 PM David E. Wheeler wrote: Hackers, Most of the jsonpath methods auto-unwrap in lax mode: david=# select jsonb_path_query('[-2,5]', '$.abs()');  jsonb_path_query --  2  5

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 3:28 PM Jacob Champion wrote: > (that's not the proposal and I know/think you know that but having my > original email twisted into that is making me feel a bit crispy) I definitely did not mean to imply that. I took your original email as a goal, rather than a proposal or

Re: RFC: adding pytest as a supported test framework

On 2024-06-12 We 11:28, Andres Freund wrote: Hi, On 2024-06-11 08:04:57 -0400, Andrew Dunstan wrote: Some time ago I did some work on wrapping libpq using the perl FFI module. It worked pretty well, and would mean we could probably avoid many uses of IPC::Run, and would probably be substantia

Re: improve predefined roles documentation

On Thu, Jun 13, 2024 at 12:48 PM Nathan Bossart wrote: > I think we could improve matters by abandoning the table and instead > documenting these roles more like we document GUCs, i.e., each one has a > section below it where we can document it in as much detail as we want. > > One of the main at

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 12:20 PM Robert Haas wrote: > I interpreted Jacob's original email as articulating a goal ("For the > v18 cycle, I would like to try to get pytest [1] in as a supported > test driver, in addition to the current offerings") rather than a > plan. That's the first part of it.

Re: improve predefined roles documentation

On Thu, Jun 13, 2024 at 01:05:33PM -0700, David G. Johnston wrote: > One of the main attributes for the GUCs is their category. If we want to > improve organization we'd need to assign categories first. We already > implicitly do so in the description section where we do group them together > and

Re: RFC: adding pytest as a supported test framework

On 2024-06-12 We 18:34, Melanie Plageman wrote: On Tue, Jun 11, 2024 at 8:05 AM Andrew Dunstan wrote: On 2024-06-10 Mo 21:49, Andres Freund wrote: Hi, On 2024-06-10 16:46:56 -0400, Andrew Dunstan wrote: I'm not sure what part of the testing infrastructure you think is unmaintained. For ex

Re: race condition in pg_class

On Wed, Jun 12, 2024 at 10:02:00PM +0200, Michail Nikolaev wrote: > > Can you say more about the connection you see between $SUBJECT and that? > That > > looks like a valid report of an important bug, but I'm not following the > > potential relationship to $SUBJECT. > > I was guided by the followi

Re: RFC: adding pytest as a supported test framework

> On 13 Jun 2024, at 20:09, Melanie Plageman wrote: > > On Thu, Jun 13, 2024 at 7:27 AM Daniel Gustafsson wrote: >> >>> On 13 Jun 2024, at 00:34, Melanie Plageman >>> wrote: >> >>> FWIW, I felt a lot of pain trying to write recovery TAP tests with >>> IPC::Run's pumping functionality. It was

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 4:06 PM Jacob Champion wrote: > There was a four-step plan sketch at the end of that email, titled "A > Plan". That was not intended to be "the final detailed plan", because > I was soliciting feedback on the exact pieces people wanted to try to > implement first, and I am

Re: RFC: adding pytest as a supported test framework

On 2024-06-12 We 11:50, Andres Freund wrote: Hi, On 2024-06-11 07:28:23 -0700, Jacob Champion wrote: On Mon, Jun 10, 2024 at 1:04 PM Andres Freund wrote: Just for context for the rest the email: I think we desperately need to move off perl for tests. The infrastructure around our testing is

Re: RFC: adding pytest as a supported test framework

On 2024-06-13 Th 15:16, Greg Sabino Mullane wrote: I'm very proficient with Perl. Yes you are, and just as well! cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 9:38 AM Robert Haas wrote: > I agree with you, but I'm skeptical that solving it will be as easy as > switching to Python. For whatever reason, it seems like every piece of > infrastructure that the PostgreSQL community has suffers from severe > neglect. Literally everythi

Re: jsonpath: Missing Binary Execution Path?

On Jun 13, 2024, at 3:33 PM, Andrew Dunstan wrote: > What does the spec say about these? What do other implementations do? Paging Mr. Eisentraut! :-) D

Re: jsonpath: Missing Binary Execution Path?

On 2024-06-13 Th 11:37, David E. Wheeler wrote: On Jun 13, 2024, at 11:32, David E. Wheeler wrote: Should && and || not also work on scalar operands? I see the same issue for unary !, too: What does the spec say about these? What do other implementations do? cheers andrew -- Andrew D

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 11:11 AM Robert Haas wrote: > I feel like I already agreed to this in a previous email and you're > continuing to argue with me as if I were disagreeing. I also think that maybe arguments are starting to sail past each other, and the temperature is starting to climb. (And

Re: RFC: adding pytest as a supported test framework

On 2024-06-12 We 18:43, Jelte Fennema-Nio wrote: I agree it's not a technical issue. It is a people issue. There are very few people skilled in Perl active in the community. And most of those are very senior hackers that have much more important things to do that make our Perl testing framewor

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 3:17 PM Greg Sabino Mullane wrote: > I feel at least some of this is a visibility / marketing problem. I've not > seen any dire requests for help come across on the lists, nor things on the > various todos/road maps/ blog posts people make from time to time. If I had, >

Re: RFC: adding pytest as a supported test framework

On Thu, 13 Jun 2024 at 20:11, Robert Haas wrote: > > But Perl is at the next level of unmaintained infrastructure. It is > > actually clear how you can contribute to it, but still no new > > community members actually want to contribute to it. Also, it's not > > only unmaintained by us but it's al

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 1:08 PM Jelte Fennema-Nio wrote: > I think 1 & 3 could be addressed by more easily giving commit/merge > access to these tools than to the main PG repo. And I think 2 could be > addressed by writing on the relevant wiki page where to go, and > probably putting a link to the

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 2:52 PM Jelte Fennema-Nio wrote: > I understand and agree with your final stated goal of not ending up in > another big mess. It's also clear to me that you don't think the > current proposal achieves that goal. So I assume you have some > additional ideas for the proposal

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 4:54 PM Andrew Dunstan wrote: > FTR, I have put a lot of effort into maintaining and improving the > infrastructure over the years. And I don't think there is anything much > more important. So I'm going to put more effort in. And I'm not alone. > Andres, Alvaro, Noah and T

Re: RFC: adding pytest as a supported test framework

On 2024-06-13 Th 17:23, Robert Haas wrote: On Thu, Jun 13, 2024 at 4:54 PM Andrew Dunstan wrote: FTR, I have put a lot of effort into maintaining and improving the infrastructure over the years. And I don't think there is anything much more important. So I'm going to put more effort in. And I

Re: RFC: adding pytest as a supported test framework

On Thu, 13 Jun 2024 at 23:35, Andrew Dunstan wrote: > Clearly there are areas we can improve, and we need to be somewhat more > proactive about it. To follow that great suggestion, I updated meson wiki[1] after I realized some of the major gripes I had with the Perl tap test output were not actua

Re: Shouldn't jsonpath .string() Unwrap?

On Jun 13, 2024, at 3:53 PM, Andrew Dunstan wrote: > Hmm. You might be right. Many of these items have this code, but the string() > branch does not: > if (unwrap && JsonbType(jb) == jbvArray) >return executeItemUnwrapTargetArray(cxt, jsp, jb, found, >

Re: CI and test improvements

On Thu, Jun 13, 2024 at 06:56:20AM -0500, Justin Pryzby wrote: > On Thu, Jun 13, 2024 at 02:38:46PM +0300, Nazir Bilal Yavuz wrote: >>> I reintroduced the patch for ccache/windows -- v4.10 supports PCH, which >>> can make the builds 2x faster. >> >> I applied 0001 and 0002 to see ccache support on

Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

On Tue, Jun 11, 2024 at 01:00:00PM +0200, Michail Nikolaev wrote: > Probably something wrong with arbiter index selection for different > backends. I am afraid it could be a symptom of a more serious issue. ON CONFLICT selects an index that may be rebuilt in parallel of the REINDEX happening, and

Re: Logical Replication of sequences

On Thu, Jun 13, 2024 at 03:36:05PM +0530, Amit Kapila wrote: > Fair enough. However, this raises the question Dilip and Vignesh are > discussing whether we need a new relfilenode for sequence update even > during initial sync? As per my understanding, the idea is that similar > to tables, the CREAT

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 1:04 PM Robert Haas wrote: > One caveat here, > perhaps, is that the focus of the work you've done up until now and > the things that I and other community members may want as a condition > of merging stuff may be somewhat distinct. You will have naturally > been focused on

Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 1:27 PM Robert Haas wrote: > > On Thu, Jun 13, 2024 at 4:06 PM Jacob Champion > wrote: > > There was a four-step plan sketch at the end of that email, titled "A > > Plan". That was not intended to be "the final detailed plan", because > > I was soliciting feedback on the e

Re: Revive num_dead_tuples column of pg_stat_progress_vacuum

On Tue, Jun 11, 2024 at 10:38 PM Masahiko Sawada wrote: > > On Fri, Jun 7, 2024 at 10:22 AM Masahiko Sawada wrote: > > > > On Wed, Jun 5, 2024 at 7:19 PM Andrey M. Borodin > > wrote: > > > > > > > > > > > > > On 4 Jun 2024, at 00:26, Masahiko Sawada wrote: > > > > > > Thank you! Vacuum enhance

Re: Revive num_dead_tuples column of pg_stat_progress_vacuum

Masahiko Sawada writes: > I was about to push the patch but let me confirm just in case: is it > okay to bump the catversion even after post-beta1? Yes, that happens somewhat routinely. regards, tom lane

Re: Revive num_dead_tuples column of pg_stat_progress_vacuum

On Thu, Jun 13, 2024 at 08:38:05PM -0400, Tom Lane wrote: > Masahiko Sawada writes: >> I was about to push the patch but let me confirm just in case: is it >> okay to bump the catversion even after post-beta1? > > Yes, that happens somewhat routinely. Up to RC, even after beta2. This happens ro

Re: Changing default -march landscape

On Thu, Jun 13, 2024 at 8:15 PM Magnus Hagander wrote: > Yeah, I think it's completely unreasonable to push this on packagers and > just say "this is your problem now". If we do that, we can assume the only > people to get any benefit from these optimizations are those that use a fully > manag

Re: Revive num_dead_tuples column of pg_stat_progress_vacuum

On Fri, Jun 14, 2024 at 9:41 AM Michael Paquier wrote: > > On Thu, Jun 13, 2024 at 08:38:05PM -0400, Tom Lane wrote: > > Masahiko Sawada writes: > >> I was about to push the patch but let me confirm just in case: is it > >> okay to bump the catversion even after post-beta1? > > > > Yes, that happ

Re: race condition in pg_class

On Thu, Jun 13, 2024 at 05:35:49PM -0700, Noah Misch wrote: > I think the attached covers all comments to date. I gave everything v3, but > most patches have just a no-conflict rebase vs. v2. The exceptions are > inplace031-inj-wait-event (implements the holding from that branch of the > thread)

Re: jsonpath: Missing Binary Execution Path?

On 06/13/24 16:43, David E. Wheeler wrote: > Paging Mr. Eisentraut! I'm not Mr. Eisentraut, but I have at last talked my way into some access to the standard, so ... Note 487 emphasizes that JSON path predicates "are not expressions; instead they form a separate language that can only be invoked

Re: Revive num_dead_tuples column of pg_stat_progress_vacuum

On Fri, Jun 14, 2024 at 9:57 AM Masahiko Sawada wrote: > > On Fri, Jun 14, 2024 at 9:41 AM Michael Paquier wrote: > > > > On Thu, Jun 13, 2024 at 08:38:05PM -0400, Tom Lane wrote: > > > Masahiko Sawada writes: > > >> I was about to push the patch but let me confirm just in case: is it > > >> oka

Re: jsonpath: Missing Binary Execution Path?

On Thu, Jun 13, 2024 at 6:10 PM Chapman Flack wrote: > On 06/13/24 16:43, David E. Wheeler wrote: > > Paging Mr. Eisentraut! > > I'm not Mr. Eisentraut, but I have at last talked my way into some > access to the standard, so ... > > Note 487 emphasizes that JSON path predicates "are not expressio

Re: jsonpath: Missing Binary Execution Path?

On 06/13/24 21:24, David G. Johnston wrote: > I'm content that the operators in the 'filter operators' table need to be > within filter but then I cannot reconcile why this example worked: > > david=# select jsonb_path_query('1', '$ >= 1'); Good point. I can't either. No way I can see to parse th

Re: jsonpath: Missing Binary Execution Path?

On Thursday, June 13, 2024, Chapman Flack wrote: > On 06/13/24 21:24, David G. Johnston wrote: > > I'm content that the operators in the 'filter operators' table need to be > > within filter but then I cannot reconcile why this example worked: > > > > david=# select jsonb_path_query('1', '$ >= 1'

Re: Shouldn't jsonpath .string() Unwrap?

On 06/13/24 18:45, David E. Wheeler wrote: > On Jun 13, 2024, at 3:53 PM, Andrew Dunstan wrote: > >> Hmm. You might be right. Many of these items have this code, but the >> string() branch does not: >> if (unwrap && JsonbType(jb) == jbvArray) >>return executeItemUnwrapTargetArray(cxt, jsp, j

Re: jsonpath: Missing Binary Execution Path?

On 06/13/24 21:46, David G. Johnston wrote: >>> david=# select jsonb_path_query('1', '$ >= 1'); >> >> Good point. I can't either. No way I can see to parse that as >> a . > > Whether we note it as non-standard or not is an open question then, but it > does work and opens up a documentation questio

  1   2   >