Re: Logical Replication of sequences

On Thu, Jun 13, 2024 at 11:53 AM vignesh C wrote: > > On Thu, 13 Jun 2024 at 10:27, Dilip Kumar wrote: > > Thanks for the explanation, but I am still not getting it completely, > > do you mean to say unless all the sequences are not synced any of the > > sequences would not be marked "ready" in

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

Hi All, Frist of all really appreciate the review of my patch. I've seperated the patch into two: patch_support_tls1.3 for tls1.3 support and patch_support_curves_group for a set of curves list. TLS1.3 support - patch_support_tls1.3 I agree with Jelte that it's better to have different option

Re: Logical Replication of sequences

On Thu, 13 Jun 2024 at 10:27, Dilip Kumar wrote: > > On Thu, Jun 13, 2024 at 10:10 AM vignesh C wrote: > > > > > So, you're saying that when we synchronize the sequence values on the > > > subscriber side, we will create a new relfilenode to allow reverting > > > to the old state of the sequence

Re: Conflict Detection and Resolution

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 first part focuses on conflict detection, which aims to > identify and rep

Re: [PATCH] pg_permissions

Hmm, strange, the commitfest system didn't pick up the email with patch 0006 for some reason, with message id 0c5a6b79-408c-4910-9b2e-4aa9a7b30...@app.fastmail.com It's rebased to latest HEAD, so not sure why. Maybe it got confused when I quickly afterwards sent a new email without a patch? He

Re: Logical Replication of sequences

On Thu, Jun 13, 2024 at 10:10 AM vignesh C wrote: > > > So, you're saying that when we synchronize the sequence values on the > > subscriber side, we will create a new relfilenode to allow reverting > > to the old state of the sequence in case of an error or transaction > > rollback? But why would

Re: Conflict Detection and Resolution

On Wed, Jun 12, 2024 at 5:26 PM Tomas Vondra wrote: > > >> I agree having a separate update_deleted conflict would be beneficial, > >> I'm not arguing against that - my point is actually that I think this > >> conflict type is required, and that it needs to be detected reliably. > >> > > > > When

Re: Logical Replication of sequences

On Wed, 12 Jun 2024 at 17:09, Dilip Kumar wrote: > > 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 d

Re: Remove dependence on integer wrapping

10.06.2024 04:57, 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. Whatever cases you may have discovered by running the regression tests will be at best the tip of the iceberg. Is there any chance of using static analysis

Re: 001_rep_changes.pl fails due to publisher stuck on shutdown

On Wed, Jun 12, 2024 at 6:43 AM Kyotaro Horiguchi wrote: > > At Tue, 11 Jun 2024 14:27:28 +0530, Amit Kapila > wrote in > > On Tue, Jun 11, 2024 at 12:34 PM Kyotaro Horiguchi > > wrote: > > > > > > At Tue, 11 Jun 2024 11:32:12 +0530, Amit Kapila > > > wrote in > > > > Sorry, it is not clear t

Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

Hi, On Wed, Jun 12, 2024 at 11:35 PM John H wrote: > > > But, I also agree with Jelte, it should be a property of a control file, > > rather than a user controlled parameter, so that an attacker can't opt out. > This will be addressed in the next patch version. > +1. Also curious what happens

Re: Harmonizing pg_bsd_indent parameter names

On Wed, Jun 12, 2024 at 9:58 PM Tom Lane wrote: > We could probably assume that we'll treat their code as though > HAVE_POSIX_DECLS is true and so this whole stanza goes away. > But I'd just as soon not think about it until I have the energy > to do that sync. Unless somebody else is hot to do it

Re: Changing default -march landscape

On Thu, Jun 13, 2024 at 01:20:17PM +1200, Thomas Munro wrote: > The way I think about it, it's not our place to require anything (I > mean, we can't literally put -march=XXX into our build files, or if we > do the Debian et al maintainers will have to remove them by local > patch because they are i

Re: [PATCH] pg_permissions

On Thu, Jun 13, 2024, at 00:14, Joel Jacobson wrote: > Changes since patch 0005 from 2021-03-25: > * 0006-pg_privileges-and-pg_ownerships.patch - Also much faster now thanks to pg_get_acl(): Test with 10 tables: SELECT COUNT(*) FROM pg_permissions_union_all; Time: 1466.504 ms (00:01.467) Tim

Re: Harmonizing pg_bsd_indent parameter names

Nathan Bossart writes: > On Wed, Jun 12, 2024 at 05:59:14PM -0400, Peter Geoghegan wrote: >> There is also one oddball case, not quite in either category. This >> involves zic.c's declaration of >> link(), when it should actually just be using the #include >> declaration. > That one seems to be

Re: Harmonizing pg_bsd_indent parameter names

On Wed, Jun 12, 2024 at 05:59:14PM -0400, Peter Geoghegan wrote: > There is also one oddball case, not quite in either category. This > involves zic.c's declaration of > link(), when it should actually just be using the #include > declaration. That's another weird upstream code thing -- this isn'

Re: Changing default -march landscape

On Thu, Jun 13, 2024 at 1:09 PM Nathan Bossart wrote: > Now, let's say we require x86-64-v2. Once we have that, we can avoid the > function pointer on many more x86 machines. While that sounds great, now > we have a different problem. If someone wants to add, say, AVX-512 support > [0], which i

Re: Changing default -march landscape

On Thu, Jun 13, 2024 at 11:11:56AM +1200, Thomas Munro wrote: > David R and I were discussing vectorisation and microarchitectures and > what you can expect the target microarchitecture to be these days, and > it seemed like some of our choices are not really very > forward-looking. > > Distros ta

Re: Row pattern recognition

I gave a talk on RPR in PGConf.dev 2024. https://www.pgevents.ca/events/pgconfdev2024/schedule/session/114-implementing-row-pattern-recognition/ (Slides are available from the link). Vik Faring and Jacob Champion were one of the audiences and we had a small discussion after the talk. We continued

Re: Columnar format export in Postgres

Hi, In "Columnar format export in Postgres" on Wed, 12 Jun 2024 22:26:30 +0530, Sushrut Shivaswamy wrote: > I have been working on adding support for columnar format export to > Postgres to speed up analytics queries. FYI: I'm proposing making COPY format extendable: * https://www.postgr

Changing default -march landscape

Hi, David R and I were discussing vectorisation and microarchitectures and what you can expect the target microarchitecture to be these days, and it seemed like some of our choices are not really very forward-looking. Distros targeting x86-64 traditionally assumed the original AMD64 K8 instructio

Re: race condition in pg_class

On Wed, Jun 12, 2024 at 12:32:23PM -0700, Noah Misch wrote: > On Wed, Jun 12, 2024 at 02:08:31PM -0400, Robert Haas wrote: >> Personally, I think the fact that injection point wait events were put >> under Extension is a design mistake that should be corrected before 17 >> is out of beta. Well, is

Re: RFC: adding pytest as a supported test framework

On Wed, 12 Jun 2024 at 21:07, Robert Haas wrote: > Yeah, I don't think depending on psycopg2 is practical at all. We can > either shell out to psql like we do now, or we can use something like > CFFI. Quick clarification I meant psycopg3, not psycopg2. And I'd very much like to avoid using psql f

Re: RFC: adding pytest as a supported test framework

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 example, the last release of Test::Simp

Re: [PATCH] pg_permissions

On Thu, Mar 10, 2022, at 22:02, Chapman Flack wrote: > It looked to me as if the -hackers messages of 25 and 26 March 2021 had > found a consensus that a pg_get_acl() function would be a good thing, > with the views to be implemented over that. > > I'm just not seeing any later patch that adds such

Re: Harmonizing pg_bsd_indent parameter names

On Wed, Jun 12, 2024 at 5:32 PM Nathan Bossart wrote: > I would be surprised if this 2-line patch created anything approaching a > significant amount of work down the road. FWIW commit 10d34fe already > changed one line in indent.c. I missed that. > > I'd like to push this patch now. It's gener

Re: RFC: adding pytest as a supported test framework

On Wed, 12 Jun 2024 at 18:46, Daniele Varrazzo wrote: > This is true, but [citation needed] :D I assume the pointer wanted to > be https://www.psycopg.org/psycopg3/docs/api/pq.html#pq-impl Ugh, yes I definitely meant to add a link to that [1]. I meant this one though: [1]: https://www.psycopg.o

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

> -Original Message- > From: Andres Freund > Sent: Wednesday, June 12, 2024 1:12 PM > To: Amonson, Paul D > FWIW, I tried the v2 patch on my Xeon Gold 5215 workstation, and dies early > on with SIGILL: Nice catch!!! I was testing the bit for the vpclmulqdq in EBX instead of the corre

Re: Harmonizing pg_bsd_indent parameter names

On Wed, Jun 12, 2024 at 5:33 PM Tom Lane wrote: > Peter Geoghegan writes: > > Attached patch harmonizes pg_bsd_indent's function parameter names, so > > that they match the names used in corresponding function definitions. > > Hmm, these aren't really harmonizing inconsistencies, but overruling >

Re: RFC: adding pytest as a supported test framework

Hi, (I don't have an opinion which language should be selected here.) In "Re: RFC: adding pytest as a supported test framework" on Wed, 12 Jun 2024 12:31:23 -0700, Jacob Champion wrote: > - I like Ruby as a language but have no experience using it for > testing. (RSpec did come up during

Re: Harmonizing pg_bsd_indent parameter names

Peter Geoghegan writes: > Attached patch harmonizes pg_bsd_indent's function parameter names, so > that they match the names used in corresponding function definitions. Hmm, these aren't really harmonizing inconsistencies, but overruling somebody's style decision to leave parameter names out of t

Re: Harmonizing pg_bsd_indent parameter names

On Wed, Jun 12, 2024 at 05:14:44PM -0400, Peter Geoghegan wrote: > I have been putting this off because I wasn't sure that the policy > should be the same for pg_bsd_indent. Is there any reason to think > that this will create more work down the line? It seems like it might, > due to some kind of n

Harmonizing pg_bsd_indent parameter names

Attached patch harmonizes pg_bsd_indent's function parameter names, so that they match the names used in corresponding function definitions. I have been putting this off because I wasn't sure that the policy should be the same for pg_bsd_indent. Is there any reason to think that this will create m

Re: Allow non-superuser to cancel superuser tasks.

I adjusted 0001 based on my upthread feedback. -- nathan >From 118f95346fcf8099ab28d2f9186185171e3b88af Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Wed, 12 Jun 2024 15:38:14 -0500 Subject: [PATCH v5 1/1] Introduce pg_signal_autovacuum_worker. Since commit 3a9b18b309, roles with privileg

Re: RFC: adding pytest as a supported test framework

On Wed, Jun 12, 2024 at 01:40:30PM +0200, Jelte Fennema-Nio wrote: > On Wed, 12 Jun 2024 at 01:48, Noah Misch wrote: > > I also want the initial scope to be the new language coexisting with the > > existing Perl tests. If a bulk translation ever happens, it should happen > > long after the debut

Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

On Wed, 2024-06-12 at 15:36 -0400, Robert Haas wrote: > But I think there's another problem, which is > that if the extension is relocatable, how do you set a secure > search_path? You could say SET search_path = foo, pg_catalog if you > know the extension will be installed in schema foo, but if yo

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

Hi, On 2024-05-01 15:56:08 +, Amonson, Paul D wrote: > Comparing the current SSE4.2 implementation of the CRC32C algorithm in > Postgres, to an optimized AVX-512 algorithm [0] we observed significant > gains. The result was a ~6.6X average multiplier of increased performance > measured on 3 di

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

On Jun 12, 2024, at 4:02 PM, David G. Johnston wrote: > Adding Andrew. Thank you. > I'm willing to call this an open item against this feature as I don't see any > documentation explaining that string() behaves differently than the others. Maybe there’s some wording in the standard on this t

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

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 > (2 rows) > > The obvious exceptions are size() and type(), whi

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

  1   2   >