Re: BF mamba failure

On Wed, Jun 12, 2024 at 08:00:00PM +0300, Alexander Lakhin wrote: > With extra logging added, I see the following events happening: > 1) pgstat_rc_1.setup calls pgstat_create_replslot(), gets >   ReplicationSlotIndex(slot) = 0 and calls >   pgstat_get_entry_ref_locked(PGSTAT_KIND_REPLSLOT, InvalidO

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

On Thu, Jun 13, 2024 at 09:07:42PM +0300, m.litsa...@postgrespro.ru wrote: > 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 w

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

On 2024-06-13 17:01, Michael Paquier wrote: 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. Thanks for applyin

Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

Hi Robert, Since this patch had been reviewed at PgConf.dev Patch Review Workshop. And I have updated the patch according to the review advice. Now there are no others to comment this patch. The status of this patch on commitfest have stayed "need review" for a long time. I want to know if it

Re: Remove dependence on integer wrapping

On Thu, Jun 13, 2024 at 10:48 PM Joseph Koshakow wrote: >I've attached >v4-0002-Handle-overflow-in-money-arithmetic.patch which adds some >overflow checks and tests. I didn't address the float multiplication >because I didn't see any helper methods in int.h. I did some some >us

Re: Remove dependence on integer wrapping

On Thu, Jun 13, 2024 at 12:00 AM Alexander Lakhin wrote: > >Let me remind you of bug #18240. Yes, that was about float8, but with >-ftrapv we can get into the trap with: >SELECT 1_000_000_000::money * 1_000_000_000::int; >server closed the connection unexpectedly Interesting, it l

Re: race condition in pg_class

On Fri, Jun 14, 2024 at 09:58:59AM +0900, Michael Paquier wrote: > Looking at inplace031-inj-wait-event.. > > The comment at the top of GetWaitEventCustomNames() requires an > update, still mentioning extensions. Thanks. Fixed locally. > GetWaitEventCustomIdentifier() is incorrect, and should r

Re: jsonpath: Missing Binary Execution Path?

On 06/13/24 22:16, David E. Wheeler wrote: > But even inside filters I don’t understand why &&, ||, at least, > currently only work if their operands are predicate expressions. > Seems weird; and your notes above suggest that rule applies only to !, > which makes slightly more sense. It's baked ri

Re: jsonpath: Missing Binary Execution Path?

On Jun 13, 2024, at 21:58, Chapman Flack 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 documen

Re: jsonpath: Missing Binary Execution Path?

On Thursday, June 13, 2024, Chapman Flack wrote: > 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 questi

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >