Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

Hi Ashutosh, Apologies for any confusion, but I'm not entirely following your > explanation. Could you kindly provide further clarification? > Additionally, would you mind reviewing the problem description > outlined in the initial email? > I know about the problem and have seen the original emai

Re: Partial aggregates pushdown

On Wed, 12 Jun 2024 at 07:27, fujii.y...@df.mitsubishielectric.co.jp wrote: > Could you please clarify what you mean? > Are you referring to: > Option 1: Modifying existing aggregate functions to minimize the use of > internal state values. > Option 2: Not supporting the push down of partial

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hi, Alexander, Here, I made some improvements according to your discussion with Heikki. On 2024-04-11 18:09, Alexander Korotkov wrote: On Thu, Apr 11, 2024 at 1:46 AM Heikki Linnakangas wrote: In a nutshell, it's possible for the loop in WaitForLSN to exit without cleaning up the process from

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

On Mon, 10 Jun 2024 at 12:31, Daniel Gustafsson wrote: > Regarding the ciphersuites portion of the patch. I'm not particularly > thrilled > about having a GUC for TLSv1.2 ciphers and one for TLSv1.3 ciphersuites, users > not all that familiar with TLS will likely find it confusing to figure out

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

On Wed, 12 Jun 2024 at 04:32, Erica Zhang wrote: > There are certain government, financial and other enterprise organizations > that have very strict requirements about the encrypted communication and more > specifically about fine grained params like the TLS ciphers and curves that > they use.

Re: Conflict Detection and Resolution

On Tue, Jun 11, 2024 at 7:44 PM Tomas Vondra wrote: > > > > On 6/11/24 10:35, shveta malik wrote: > > On Mon, Jun 10, 2024 at 5:24 PM Tomas Vondra > > wrote: > >> > >> > >> > >> On 6/10/24 12:56, shveta malik wrote: > >>> On Fri, Jun 7, 2024 at 6:08 PM Tomas Vondra > >>> wrote: > > >>>

Re: Logical Replication of sequences

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 new column titled "all sequences" in the > > pg_publication system tab

Re: RFC: adding pytest as a supported test framework

On 2024-06-11 Tu 19:48, Noah Misch wrote: On Mon, Jun 10, 2024 at 06:49:11PM -0700, Andres Freund wrote: On 2024-06-10 16:46:56 -0400, Andrew Dunstan wrote: On 2024-06-10 Mo 16:04, Andres Freund wrote: Just for context for the rest the email: I think we desperately need to move off perl for

Re: Logical Replication of sequences

On Wed, 12 Jun 2024 at 10:51, Dilip Kumar wrote: > > On Tue, Jun 11, 2024 at 4:06 PM vignesh C wrote: > > > > Amit and I engaged in an offline discussion regarding the design and > > contemplated that it could be like below: > > If I understand correctly, does this require the sequences to alread

Re: Track the amount of time waiting due to cost_delay

Hi, On Tue, Jun 11, 2024 at 11:40:36AM -0500, Nathan Bossart wrote: > On Tue, Jun 11, 2024 at 07:25:11AM +, Bertrand Drouvot wrote: > > So I think that in v2 we could: 1) measure the actual wait time instead, 2) > > count the number of times the vacuum slept. We could also 3) reports the > > e

Re: Showing applied extended statistics in explain Part 2

Hello Yamada-san, I finally got to look at this patch again - apologies for taking so long, I'm well aware it's rather frustrating to wait for feedback. I'll try to pay more attention to this patch, and don't hesitate to ping me off-list if immediate input is needed. I looked at the patch from Ma

Re: Track the amount of time waiting due to cost_delay

Hi, On Tue, Jun 11, 2024 at 02:48:30PM -0400, Robert Haas wrote: > On Tue, Jun 11, 2024 at 2:47 PM Nathan Bossart > wrote: > > I'm struggling to think of a scenario in which the number of waits would be > > useful, assuming you already know the amount of time spent waiting. If we provide the ac

Re: Postgresql OOM

Hi, > That's helpful, thanks! > > One thing to note is that postgres' work_mem is confusing - it applies to > individual query execution nodes, not the whole query. Additionally, when > you > use parallel workers, each of the parallel workers can use the "full" > work_mem, rather than work_mem be

Re: Logical Replication of sequences

On Wed, Jun 12, 2024 at 4:08 PM vignesh C wrote: > > On Wed, 12 Jun 2024 at 10:51, Dilip Kumar wrote: > > > > On Tue, Jun 11, 2024 at 4:06 PM vignesh C wrote: > > > > > > Amit and I engaged in an offline discussion regarding the design and > > > contemplated that it could be like below: > > > >

Re: RFC: adding pytest as a supported test framework

On Wed, 12 Jun 2024 at 01:48, Noah Misch wrote: > If we're going to test in a non-Perl language, I'd pick C over Python. There > would be several other unlikely-community-choice languages I'd pick over > Python (C#, Java, C++). My main goals of this thread are: 1. Allowing people to quickly writ

Re: RFC: adding pytest as a supported test framework

On Tue, Jun 11, 2024 at 5:31 PM Jacob Champion wrote: > On Mon, Jun 10, 2024 at 12:26 PM Alexander Korotkov > wrote: > > Thank you for working on this. > > Do you think you could re-use something from testgres[1] package? > > Possibly? I think we're all coming at this with our own bags of tricks

Re: Conflict Detection and Resolution

On 6/12/24 06:32, Dilip Kumar wrote: > On Tue, Jun 11, 2024 at 7:44 PM Tomas Vondra > wrote: > >>> Yes, that's correct. However, many cases could benefit from the >>> update_deleted conflict type if it can be implemented reliably. That's >>> why we wanted to give it a try. But if we can't achi

Re: RFC: adding pytest as a supported test framework

On Wed, Jun 12, 2024 at 2:48 PM Alexander Korotkov wrote: > On Tue, Jun 11, 2024 at 5:31 PM Jacob Champion > wrote: > > On Mon, Jun 10, 2024 at 12:26 PM Alexander Korotkov > > wrote: > > > Thank you for working on this. > > > Do you think you could re-use something from testgres[1] package? > >

Re: Track the amount of time waiting due to cost_delay

Hi, On Tue, Jun 11, 2024 at 01:13:48PM -0400, Robert Haas wrote: > On Tue, Jun 11, 2024 at 5:49 AM Bertrand Drouvot > wrote: > > As we can see the actual wait time is 30ms less than the intended wait time > > with > > this simple test. So I still think we should go with 1) actual wait time > >

Re: RFC: adding pytest as a supported test framework

On Wed, 12 Jun 2024 at 01:48, Noah Misch wrote: > If we're going to test in a non-Perl language, I'd pick C over Python. > > We'd need a library like today's Perl > PostgreSQL::Test to make C-language tests nice, but the same would apply to > any new language. P.P.S. We already write tests in C,

Re: Proposal: Document ABI Compatibility

On 11.06.24 16:55, David E. Wheeler wrote: On Jun 10, 2024, at 15:39, Andres Freund wrote: That's 6 years ago, not sure we can really learn that much from that. And it's not like it's actually impossible, #ifdefs aren't great, but they are better than nothing. Right, it’s just that extensio

Re: ON ERROR in json_query and the like

> On 11.06.2024, at 03:58, jian he wrote: > > On Tue, May 28, 2024 at 5:29 PM Markus Winand wrote: >> >> Hi! >> >> I’ve noticed two “surprising” (to me) behaviors related to >> the “ON ERROR” clause of the new JSON query functions in 17beta1. >> >> 1. JSON parsing errors are not subject to

Re: Proposal: Document ABI Compatibility

On Wed, 12 Jun 2024 at 14:44, Peter Eisentraut wrote: > I think since around 6 years ago we have been much more vigilant about > avoiding ABI breaks. So if there aren't any more recent examples of > breakage, then maybe that was ultimately successful, and the upshot is, > continue to be vigilant

Re: race condition in pg_class

Hello, everyone. I am not sure, but I think that issue may be related to the issue described in https://www.postgresql.org/message-id/CANtu0ojXmqjmEzp-%3DaJSxjsdE76iAsRgHBoK0QtYHimb_mEfsg%40mail.gmail.com It looks like REINDEX CONCURRENTLY could interfere with ON CONFLICT UPDATE in some strange w

Re: CI and test improvements

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 as artifacts). > > https://github.com/justinpryzby/cfbot/commits/master > > Thanks, sorry for la

Re: ON ERROR in json_query and the like

On Wednesday, June 12, 2024, Markus Winand wrote: > > > 10.14 SR 1: The declared type of the simply contained > in the immediately contained in the item> shall be a string type or a JSON type. > It might be best to think of it as two separate functions, overloaded: > > JSON_VALUE(context_item

Re: ON ERROR in json_query and the like

> On 04.06.2024, at 07:00, jian he wrote: > > On Tue, May 28, 2024 at 5:29 PM Markus Winand wrote: > >> 2. EMPTY [ARRAY|OBJECT] ON ERROR implies ERROR ON EMPTY >> >> 17beta1=# SELECT JSON_QUERY('[]', '$[*]' EMPTY ARRAY ON ERROR) a; >>a >> >>[] >> (1 row) >> >> As NULL O

Re: relfilenode statistics

Hi, On Tue, Jun 11, 2024 at 03:35:23PM +0900, Kyotaro Horiguchi wrote: > At Mon, 10 Jun 2024 08:09:56 +, Bertrand Drouvot > wrote in > > > > My idea was to move all that is in pg_statio_all_tables to relfilenode stats > > and 1) add new stats to pg_statio_all_tables (like heap_blks_written

Re: ON ERROR in json_query and the like

On Tuesday, May 28, 2024, Markus Winand wrote: > > 2. EMPTY [ARRAY|OBJECT] ON ERROR implies ERROR ON EMPTY > >17beta1=# SELECT JSON_QUERY('[]', '$[*]' EMPTY ARRAY ON ERROR) a; > a > > [] >(1 row) > >As NULL ON EMPTY is implied, it should give the same result as >ex

Re: RFC: adding pytest as a supported test framework

> On Jun 12, 2024, at 6:40 AM, Jelte Fennema-Nio wrote: > > I think C#, Java, Go, Rust, Kotlin, and Swift would be acceptable > choices for me (and possibly some more). They allow some type of > introspection, they have a garbage collector, and their general > tooling is quite good. > Having

Re: ON ERROR in json_query and the like

> On 12.06.2024, at 15:31, David G. Johnston wrote: > > On Tuesday, May 28, 2024, Markus Winand wrote: > > 2. EMPTY [ARRAY|OBJECT] ON ERROR implies ERROR ON EMPTY > >17beta1=# SELECT JSON_QUERY('[]', '$[*]' EMPTY ARRAY ON ERROR) a; > a > > [] >(1 row) > >As NUL

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

On 12.06.24 10:51, Jelte Fennema-Nio wrote: On Mon, 10 Jun 2024 at 12:31, Daniel Gustafsson wrote: Regarding the ciphersuites portion of the patch. I'm not particularly thrilled about having a GUC for TLSv1.2 ciphers and one for TLSv1.3 ciphersuites, users not all that familiar with TLS will l

Re: Proposal: Document ABI Compatibility

On Jun 12, 2024, at 8:43 AM, Peter Eisentraut wrote: >> Right, it’s just that extension authors could use some notification that >> such a change is coming so they can update their code, if necessary. > > I think since around 6 years ago we have been much more vigilant about > avoiding ABI bre

Re: SQL:2011 application time

On Wed, Jun 5, 2024 at 4:56 PM Paul Jungwirth wrote: > **Option 2**: Add a new operator, called &&&, that works like && except an > empty range *does* > overlap another empty range. Empty ranges should still not overlap anything > else. This would fix the > exclusion constraint. You could add `(

Re: Proposal: Document ABI Compatibility

On Jun 12, 2024, at 8:58 AM, Jelte Fennema-Nio wrote: > While not strictly an ABI break I guess, the backport of 32d5a4974c81 > broke building Citus against 13.10 and 14.7[1]. > > [1]: https://github.com/citusdata/citus/pull/6711 Interesting one. We might want to advise projects to use deferent

Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade

On Tue, Jun 11, 2024 at 10:39:51AM +0200, Matthias van de Meent wrote: > On Tue, 11 Jun 2024 at 04:01, Nathan Bossart wrote: >> It looks like pg_dump always uses template0, so AFAICT we don't even need >> the suggested manual checkpoint after restoring template1. > > Thanks for reminding me. It s

Re: Proposal: Document ABI Compatibility

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 public function signatures. If we docum

Re: RFC: adding pytest as a supported test framework

Jelte Fennema-Nio: As scripting languages go, the ones that are still fairly heavily in use are Javascript, Python, Ruby, and PHP. I think all of those could probably work, but my personal order of preference would be Python, Ruby, Javascript, PHP. Finally, I'm definitely biased towards using Py

Re: Remove dependence on integer wrapping

On Tue, Jun 11, 2024 at 09:10:44PM -0400, Joseph Koshakow wrote: > The attached patch has updated this file too. For some reason I was > under the impression that I should leave the ecpg/ files alone, though > I can't remember why. Thanks. This looks pretty good to me after a skim, so I'll see ab

Re: Proposal: Document ABI Compatibility

On Jun 12, 2024, at 10:47, Robert Haas wrote: > 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 public function signatures. If we document promises to > extension authors, I don't know how much diff

Re: Windows: openssl & gssapi dislike each other

Hi I removed the macro from the sslinfo.c as suggested by Andrew. Then I was thinking maybe we can undo some other similar code. I rearranged the headers to their previous position in be-secure-openssl.c and in fe-secure-openssl.c. I was able to compile with gssapi and openssl enabled. You can lo

Re: Proposal: Document ABI Compatibility

On 2024-06-11 10:55:38 -0400, David E. Wheeler wrote: > ABI Policy > == > > The PostgreSQL core team maintains two application binary interface (ABI) > guarantees: one for major releases and one for minor releases. I.e. for major versions it's "there is none"? > Major Releases > ---

Re: Proposal: Document ABI Compatibility

Hi, On 2024-06-12 14:58:04 +0200, Jelte Fennema-Nio wrote: > On Wed, 12 Jun 2024 at 14:44, Peter Eisentraut wrote: > > I think since around 6 years ago we have been much more vigilant about > > avoiding ABI breaks. So if there aren't any more recent examples of > > breakage, then maybe that was

Re: RFC: adding pytest as a supported test framework

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 substantially more efficient (no fork > required). It

Re: Proposal: Document ABI Compatibility

On Mon, Jun 3, 2024 at 3:38 PM Tom Lane wrote: > > Thus I am not really on board with this statement as-is. > > Me either. There are degrees of ABI compatibility, and we'll choose > the least invasive way, but it's seldom the case that no conceivable > extension will be broken. For example, if w

Re: RFC: adding pytest as a supported test framework

On Wed, 12 Jun 2024 at 15:49, FWS Neil wrote: > I believe that anyone coming out of school these days would have a relatively > easy transition to any of Go, Rust, Kotlin, Swift, etc. In other words, any > of > the modern languages. Agreed, which is why I said they'd be acceptable to me. But I

Re: Remove dependence on integer wrapping

Nathan Bossart writes: > Thanks. This looks pretty good to me after a skim, so I'll see about > committing/back-patching it in the near future. IIUC there is likely more > to come in this area, but I see no need to wait. Uh ... what of this would we back-patch? It seems like v18 material to me

Re: SQL:2011 application time

On Wed, 5 Jun 2024 at 22:57, Paul Jungwirth wrote: > > On Thu, May 9, 2024 at 5:44 PM Matthias van de Meent > wrote: > > Additionally, because I can't create my own non-constraint-backing > > unique GIST indexes, I can't pre-create my unique constraints > > CONCURRENTLY as one could do for t

Re: RFC: adding pytest as a supported test framework

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 basically > > unmaintained and just abou

Re: Proposal: Document ABI Compatibility

On Tue, Jun 11, 2024 at 10:55 AM David E. Wheeler wrote: > Right, it’s just that extension authors could use some notification that such > a change is coming so they can update their code, if necessary. In general our strategy around ABI breaks is to avoid them whenever possible. We also make th

Re: Remove dependence on integer wrapping

On Wed, Jun 12, 2024 at 11:45:20AM -0400, Tom Lane wrote: > Nathan Bossart writes: >> Thanks. This looks pretty good to me after a skim, so I'll see about >> committing/back-patching it in the near future. IIUC there is likely more >> to come in this area, but I see no need to wait. > > Uh ...

Re: RFC: adding pytest as a supported test framework

On Wed, 12 Jun 2024 at 17:50, Andres Freund wrote: > > The OAuth pytest suite makes extensive use of > > - psycopg, to easily drive libpq; > > That's probably not going to fly. It introduces painful circular dependencies > between building postgres (for libpq), building psycopg (requiring libpq) a

Re: RFC: adding pytest as a supported test framework

On Wed, Jun 12, 2024 at 7:08 PM Jelte Fennema-Nio wrote: > On Wed, 12 Jun 2024 at 17:50, Andres Freund wrote: > > > The OAuth pytest suite makes extensive use of > > > - psycopg, to easily drive libpq; > > > > That's probably not going to fly. It introduces painful circular > > dependencies > >

Re: Use WALReadFromBuffers in more places

Hi, On Sat, Jun 8, 2024 at 5:24 PM Nitin Jadhav wrote: > > I spent some time examining the patch. Here are my observations from the review. Thanks. > - I believe there’s no need for an extra variable ‘nbytes’ in this > context. We can repurpose the ‘count’ variable for the same function. > If n

RE: Proposal for Updating CRC32C with AVX-512 Algorithm.

> The project is currently in feature-freeze in preparation for the next major > release so new development and ideas are not the top priority right now. > Additionally there is a large developer meeting shortly which many are busy > preparing for. Excercise some patience, and I'm sure there will

Contributing test cases to improve coverage

Hello All, I am working on a project that aims to produce test cases that improve mutation coverage of a dbms's test suite. The rough workflow of the project goes as follows: (a) apply mutation at a souce code level (b) compile and check if the mutated installation passed existing testsuite (c) I

Re: RFC: adding pytest as a supported test framework

> On 12 Jun 2024, at 18:08, Jelte Fennema-Nio wrote: > On Wed, 12 Jun 2024 at 17:50, Andres Freund wrote: >> One thing worth thinking about is that such dependencies have to work on a >> relatively large number of platforms / architectures. A lot of projects >> don't... > > Do they really? A b

Re: RFC: adding pytest as a supported test framework

On Wed, 12 Jun 2024 at 18:08, Jelte Fennema-Nio wrote: > > On Wed, 12 Jun 2024 at 17:50, Andres Freund wrote: > > > The OAuth pytest suite makes extensive use of > > > - psycopg, to easily drive libpq; > > > > That's probably not going to fly. It introduces painful circular > > dependencies > >

Columnar format export in Postgres

Hey Postgres team, I have been working on adding support for columnar format export to Postgres to speed up analytics queries. I've created an extension that achieves this functionality here . I"m looking to improve the performance of this extension to

Re: BF mamba failure

Hello hackers, 20.03.2023 09:10, Peter Smith wrote: Using this I was also able to reproduce the problem. But test failures were rare. The make check-world seemed OK, and indeed the test_decoding tests would also appear to PASS around 14 out of 15 times. I've stumbled upon this assertion failu

Re: Remove dependence on integer wrapping

On Mon, Jun 10, 2024 at 2:30 PM Andres Freund wrote: > On 2024-06-09 21:57:54 -0400, Tom Lane wrote: > > BTW, while I approve of trying to get rid of our need for -fwrapv, > > I'm quite scared of actually doing it. IMV it's perfectly fine to defensively assume that we need -fwrapv, even given a t

Re: Revive num_dead_tuples column of pg_stat_progress_vacuum

On Thu, Jun 6, 2024 at 9:23 PM Masahiko Sawada wrote: > num_dead_item_ids seems good to me. I've updated the patch that > incorporated the comment from Álvaro[1]. Great, thank you. -- Peter Geoghegan

Re: RFC: adding pytest as a supported test framework

On Wed, Jun 12, 2024 at 7:34 PM Alexander Korotkov wrote: > On Wed, Jun 12, 2024 at 7:08 PM Jelte Fennema-Nio wrote: > > On Wed, 12 Jun 2024 at 17:50, Andres Freund wrote: > > > > The OAuth pytest suite makes extensive use of > > > > - psycopg, to easily drive libpq; > > > > > > That's probably

Re: Columnar format export in Postgres

Em qua., 12 de jun. de 2024 às 13:56, Sushrut Shivaswamy < sushrut.shivasw...@gmail.com> escreveu: > Hey Postgres team, > > I have been working on adding support for columnar format export to > Postgres to speed up analytics queries. > I've created an extension that achieves this functionality her

Re: RFC: adding pytest as a supported test framework

> On 12 Jun 2024, at 17:50, Andres Freund wrote: > On 2024-06-11 07:28:23 -0700, Jacob Champion wrote: >> The OAuth pytest suite makes extensive use of >> - psycopg, to easily drive libpq; > > That's probably not going to fly. It introduces painful circular dependencies > between building postgr

Re: RFC: adding pytest as a supported test framework

On Wed, 12 Jun 2024 at 19:30, Daniel Gustafsson wrote: > I might be missing something obvious, but if we use a third-party libpq driver > in the testsuite doesn't that imply that a patch adding net new functionality > to libpq also need to add it to the driver in order to write the tests? I'm >

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

Robert Haas writes: > I agree this is not great. I guess I didn't think about it very hard > because, after all, we were just exposing an API that we'd already > been using internally. But I think it's reasonable to adjust the API > to allow for better resolution, as you propose. A second is a ver

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Wed, Jun 5, 2024 at 10:06 AM Jelte Fennema-Nio wrote: > Patch 1 & 2: Minor code changes with zero effect until we actually > bump the protocol version or add protocol parameters. I hope these can > be merged rather soon to reduce the number of patches in the patchset. 0001 looks like a bug fix

Re: race condition in pg_class

On Tue, Jun 11, 2024 at 01:37:21PM +0900, Michael Paquier wrote: > On Mon, Jun 10, 2024 at 07:19:27PM -0700, Noah Misch wrote: > > On Fri, Jun 07, 2024 at 09:08:03AM -0400, Robert Haas wrote: > >> I think the core code should provide an "Injection Point" wait event > >> type and let extensions add

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

On Wed, Jun 12, 2024 at 1:53 PM Tom Lane wrote: > * I decided to invent a typedef > > typedef pg_int64 PGusec_time_t; > > instead of writing "pg_int64" explicitly everywhere. This is perhaps > not as useful as it was when I was thinking the definition would be > "long long int", but it st

Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

Hi, > I know about the problem and have seen the original email. I'm sympathetic to the problem of potential privilege escalation when executing functions. At the same time I'm not sure if there's that much of a difference between 'CREATE EXTENSION' vs superusers copying a series of 'CREATE FUNC

Re: Proposal for Updating CRC32C with AVX-512 Algorithm.

"Amonson, Paul D" writes: > I had our OSS internal team, who are experts in OSS licensing, review > possible conflicts between the PostgreSQL license and the BSD-Clause 3-like > license for the CRC32C AVX-512 code, and they found no issues. Therefore, > including the new license into the Postgr

Re: race condition in pg_class

On Wed, Jun 12, 2024 at 1:54 PM Noah Misch wrote: > If I were making a list of changes always welcome post-beta, it wouldn't > include adding wait event types. But I don't hesitate to add one if it > unblocks a necessary test for a bug present in all versions. However, injection points themselve

Re: On disable_cost

Hi, On 2024-06-12 11:35:48 -0400, Robert Haas wrote: > Subject: [PATCH v2 3/4] Treat the # of disabled nodes in a path as a separate > cost metric. > > Previously, when a path type was disabled by e.g. enable_seqscan=false, > we either avoided generating that path type in the first place, or > m

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

Em qua., 12 de jun. de 2024 às 14:53, Tom Lane escreveu: > Robert Haas writes: > > I agree this is not great. I guess I didn't think about it very hard > > because, after all, we were just exposing an API that we'd already > > been using internally. But I think it's reasonable to adjust the API

Re: Contributing test cases to improve coverage

J F writes: > For postgres, I am looking at adding test cases to test suite in > test/src/regress/. I have gone through (a)-(e), and managed to produced > some test cases. As an example, I claim the test case > ``` > CREATE RECURSIVE VIEW a(b) AS SELECT'' ; > SELECT FROM a WHERE NULL; > ``` > coul

Re: Proposal for Updating CRC32C with AVX-512 Algorithm.

On Wed, Jun 12, 2024 at 02:08:02PM -0400, Tom Lane wrote: > "Amonson, Paul D" writes: > > I had our OSS internal team, who are experts in OSS licensing, review > > possible conflicts between the PostgreSQL license and the BSD-Clause 3-like > > license for the CRC32C AVX-512 code, and they found

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

Robert Haas writes: > On Wed, Jun 12, 2024 at 1:53 PM Tom Lane wrote: >> * I decided to invent a typedef >> typedef pg_int64 PGusec_time_t; > I don't think it's a bad idea to have a typedef, but that particular > one is pretty unreadable. Mmm, let's separate some things with > underscores and ot

Re: On disable_cost

On Wed, Jun 12, 2024 at 2:11 PM Andres Freund wrote: > > > In an extreme case i can see a tiny bit of overhead, but not enough to be > worth worrying about. Mostly because we're so profligate in doing > bms_overlap() that cost comparisons don't end up mattering as much - I seem to > recall that b

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

On Wed, Jun 12, 2024 at 2:25 PM Tom Lane wrote: > Robert Haas writes: > > On Wed, Jun 12, 2024 at 1:53 PM Tom Lane wrote: > >> * I decided to invent a typedef > >> typedef pg_int64 PGusec_time_t; > > > I don't think it's a bad idea to have a typedef, but that particular > > one is pretty unreada

Re: On disable_cost

Hi, On 2024-06-12 14:33:31 -0400, Robert Haas wrote: > On Wed, Jun 12, 2024 at 2:11 PM Andres Freund wrote: > > > > > > In an extreme case i can see a tiny bit of overhead, but not enough to be > > worth worrying about. Mostly because we're so profligate in doing > > bms_overlap() that cost comp

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

Robert Haas writes: > On Wed, Jun 12, 2024 at 2:25 PM Tom Lane wrote: >> "PG" as a prefix for typedefs in libpq-fe.h is a pretty ancient >> precedent. I'm not wedded to any of the rest of it --- do you >> have a better idea? > Hmm, well, one thing I notice is that most of the other typedefs in

Re: RFC: adding pytest as a supported test framework

On Wed, Jun 12, 2024 at 1:30 PM Daniel Gustafsson wrote: > > On 12 Jun 2024, at 17:50, Andres Freund wrote: > > On 2024-06-11 07:28:23 -0700, Jacob Champion wrote: > > >> The OAuth pytest suite makes extensive use of > >> - psycopg, to easily drive libpq; > > > > That's probably not going to fly.

Multi-transactional statements and statistics for autovacuum

Hello. Before the advent of procedures in PostgreSQL 11 that can manage transactions, there could only be one transaction in one statement. Hence the end of the transaction also meant the end of the statement. Apparently, this is why the corresponding restriction is described differently in dif

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

On Wed, Jun 12, 2024 at 3:00 PM Tom Lane wrote: > Hmm ... pg_int64 is the only such typedef I'm seeing in that file. I grepped the whole directory for '^} '. > But okay, it's a precedent. The thing I'm having difficulty with > is that I'd like the typedef name to allude to time_t, and I don't >

Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

On Wed, 2024-06-12 at 12:13 +0530, Ashutosh Bapat wrote: > > Alternatively, we could leverage the extension dependency > > information > > to determine whether the function is created by an extension or > > not. > > That will be simpler. We do that sort of thing for identity > sequences. So there'

Re: On disable_cost

On Wed, Jun 12, 2024 at 2:48 PM Andres Freund wrote: > Sorry, should have been more precise. With "set" I didn't mean set to true, > but that that it's only modified within select_mergejoin_clauses(). Oh. "set" has more than one relevant meaning here. > > It starts out true, and always stays tru

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

Robert Haas writes: > On Wed, Jun 12, 2024 at 3:00 PM Tom Lane wrote: >> So how about one of >> pg_usec_time_t >> pg_time_t_usec >> ? > The former seems better to me, since having _t not at the end does not > seem too intuitive. True. We can guess about how POSIX might spell this if

Re: RFC: adding pytest as a supported test framework

On Tue, Jun 11, 2024 at 4:48 PM Noah Misch wrote: > If we're going to test in a non-Perl language, I'd pick C over Python. We already test in C, though? If the complaint is that those tests are driven by Perl, I agree that something like libcheck or GTest or whatever people are using nowadays wou

Re: RFC: adding pytest as a supported test framework

On Wed, Jun 12, 2024 at 4:40 AM Jelte Fennema-Nio wrote: > I think C#, Java, Go, Rust, Kotlin, and Swift would be acceptable > choices for me (and possibly some more). They allow some type of > introspection, they have a garbage collector, and their general > tooling is quite good. > > But I think

Re: RFC: adding pytest as a supported test framework

On Wed, Jun 12, 2024 at 4:48 AM Alexander Korotkov wrote: > Generally, testgres was initially designed as Python analogue of what > we have in src/test/perl/PostgreSQL/Test. In particular its > testgres.PostgresNode is analogue of PostgreSQL::Test::Cluster. It > comes under PostgreSQL License.

Re: race condition in pg_class

On Wed, Jun 12, 2024 at 02:08:31PM -0400, Robert Haas wrote: > On Wed, Jun 12, 2024 at 1:54 PM Noah Misch wrote: > > If I were making a list of changes always welcome post-beta, it wouldn't > > include adding wait event types. But I don't hesitate to add one if it > > unblocks a necessary test fo

Re: RFC: adding pytest as a supported test framework

On Wed, Jun 12, 2024 at 8:50 AM Andres Freund wrote: > I think I might have formulated my paragraph above badly - I didn't mean that > we should move away from perl tests tomorrow, but that we need a path forward > that allows folks to write tests without perl. Okay, agreed. > > - Tests aren't c

Re: RFC: adding pytest as a supported test framework

On Wed, Jun 12, 2024 at 10:30 AM Daniel Gustafsson wrote: > I might be missing something obvious, but if we use a third-party libpq driver > in the testsuite doesn't that imply that a patch adding net new functionality > to libpq also need to add it to the driver in order to write the tests? I us

Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

On Wed, Jun 12, 2024 at 2:05 PM John H wrote:> > I'm sympathetic to the problem of potential privilege escalation when > executing functions. At the same time I'm not sure if there's that > much of a difference between 'CREATE EXTENSION' vs superusers copying > a series of 'CREATE FUNCTION' where

Re: Proposal for Updating CRC32C with AVX-512 Algorithm.

Hi, I'm wonder if this isn't going in the wrong direction. We're using CRCs for something they're not well suited for in my understanding - and are paying a reasonably high price for it, given that even hardware accelerated CRCs aren't blazingly fast. CRCs are used for things like ethernet, iSCSI

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

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 (timeout > 0) { /* * Rounding could cause conn

Re: race condition in pg_class

On Wed, Jun 12, 2024 at 03:02:43PM +0200, Michail Nikolaev wrote: > I am not sure, but I think that issue may be related to the issue described > in > https://www.postgresql.org/message-id/CANtu0ojXmqjmEzp-%3DaJSxjsdE76iAsRgHBoK0QtYHimb_mEfsg%40mail.gmail.com > > It looks like REINDEX CONCURRENTLY

Re: Contributing test cases to improve coverage

> 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 process would lead to some very > large number of equ

Re: race condition in pg_class

Hello! > 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 following logic: * A pg_class race condition can cause table indexes to look

  1   2   >