Re: generic plans and "initial" pruning

On Sat, Feb 22, 2025 at 11:13 AM Amit Langote wrote: > On Sat, Feb 22, 2025 at 12:55 AM Tom Lane wrote: > > Amit Langote writes: > > > The short of it is that the cached-plan-inval test in the > > > delay_execution suite can never be made to work under > > > CLOBBER_CACHE_ALWAYS. The test assume

Re: MAX_BACKENDS size (comment accuracy)

On Sat, Feb 22, 2025 at 7:27 AM Andres Freund wrote: +#define MAX_BACKENDS_BITS18 +#define MAX_BACKENDS((1 << MAX_BACKENDS_BITS)-1) +1 for working forwards from the bits. But why not call it PROC_NUMBER_BITS? After 024c5211 and 024c5211^, the ID for backends is a ProcNumber,

Re: Statistics Import and Export

> > > > Yeah, I can't get excited about the cost of that for normal user > dumps. The 002_pg_dump test does run a dump with --schema pg_catalog, > but it's dubious that that test is worth its cycles. > > Attached is the first optimization, which gets rid of the pg_class queries entirely, instead g

Re: ReplicationSlotRelease() crashes when the instance is in the single user mode

On Thu, Feb 20, 2025 at 6:21 PM Hayato Kuroda (Fujitsu) wrote: > > Dear hackers, > > Thanks everyone for giving comments! PSA new version. > What's new: > > - Message format was modified to {"cannot use function %s in single-user > mode", "function_name"} > - Reporting funcname was adjusted based

Update docs for UUID data type

The attached patch file makes some modest changes to the docs for the UUID data type (Section 8.12. UUID Type). The main goal is to inform the reader that there are multiple versions of UUID generation algorithms (presently 8); however, once generated, PostgreSQL treats all UUIDs uniformly. Regard

Re: a very significant fraction of the buildfarm is now pink

On Fri, Feb 21, 2025 at 9:14 PM Andres Freund wrote: > I'd also say that breaking CI and BF is probably something I'd consider more > urgent, as that could indicate the commit was just generally less well tested. This is possible, but I think we oversell it by quite a lot. It's quite possible for

Re: TAP test command_fails versus command_fails_like

On Thu, Feb 13, 2025 at 12:58 AM Dagfinn Ilmari Mannsåker wrote: > > Ashutosh Bapat writes: > > > On Wed, Feb 12, 2025 at 10:36 AM Peter Smith wrote: > >> > >> Hi hackers, > >> > >> Recently, while writing some new TAP tests my colleague inadvertently > >> called the command_fails() subroutine i

Re: explain analyze rows=%.0f

On Fri, Feb 21, 2025 at 9:11 PM Tom Lane wrote: > I apologize if I ruffled your feathers. But the buildfarm is a shared > resource and it doesn't do to leave it significantly broken over a > weekend, which I feared you might be about to do. Committing stuff > at 4PM on a Friday is perhaps not th

Re: explain analyze rows=%.0f

Hi, On 2025-02-21 21:11:07 -0500, Tom Lane wrote: > Robert Haas writes: > > Yeah, I pushed an attempt at a band-aid fix. Hopefully that will make > > it clear whether there are other problems and how bad they are. It > > looks like the XversionUpgrade tests are not this commit's fault. > > They

Re: a very significant fraction of the buildfarm is now pink

Hi, On 2025-02-21 20:09:24 -0500, Robert Haas wrote: > In the case of my commit today, the failures are the result of a > 2-line regression diff with no functional impact that neither CI nor > any of the 11 reviewers noticed. That just shouldn't be the sort of > thing that results in somebody havi

Re: generic plans and "initial" pruning

On Sat, Feb 22, 2025 at 12:55 AM Tom Lane wrote: > Amit Langote writes: > > The short of it is that the cached-plan-inval test in the > > delay_execution suite can never be made to work under > > CLOBBER_CACHE_ALWAYS. The test assumes that locks on partitions for a > > reused generic plan are not

Re: explain analyze rows=%.0f

Robert Haas writes: > Yeah, I pushed an attempt at a band-aid fix. Hopefully that will make > it clear whether there are other problems and how bad they are. It > looks like the XversionUpgrade tests are not this commit's fault. They are not, they're Jeff's problem. I apologize if I ruffled your

Re: explain analyze rows=%.0f

On Fri, Feb 21, 2025 at 7:04 PM Tom Lane wrote: > Sounds plausible. I note that this run: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skimmer&dt=2025-02-21%2023%3A00%3A10 > > got through a couple of iterations of the core tests before failing, > showing that it's not 100% reproduc

a very significant fraction of the buildfarm is now pink

On Fri, Feb 21, 2025 at 7:04 PM Tom Lane wrote: > A very significant fraction of the buildfarm is now pink. > If you don't have a fix pretty nearly ready, please revert. When we're going to do a release, you want no commits for at least 24 hours before the release so that we can make sure the bui

Re: GetRelationPath() vs critical sections

On Sat, Feb 22, 2025 at 1:30 PM Thomas Munro wrote: > procnumber.h seems like the right place, at least without a separate > discussion of the ramifications of making it configurable, no? (I > thought there were ideas about squeezing it down to 16 bits so you > could jam two of 'em into an atomic

Re: GetRelationPath() vs critical sections

On Sat, Feb 22, 2025 at 5:15 AM Andres Freund wrote: > On 2025-02-21 18:20:39 +1300, Thomas Munro wrote: > > On Fri, Feb 21, 2025 at 9:28 AM Andres Freund wrote: > > Do we even check the binary digits? BTW I see a place in lwlock.c > > that still talks about 2^23-1, looks like it is out of date.

Re: explain analyze rows=%.0f

Robert Haas writes: > Well, not quite yet, at least. There are two buildfarm failures since > I committed this. The first is here: A very significant fraction of the buildfarm is now pink. If you don't have a fix pretty nearly ready, please revert. > I imagine what happened here is that the para

Re: Statistics Import and Export

Andres Freund writes: > Looking at the query log, the biggest culprit is a *lot* of additional > queries, I think primarily these two: > SELECT c.oid::regclass AS relation, current_setting('server_version_num') AS > version, c.relpages, c.reltuples, c.relallvisible FROM pg_class c JOIN > pg_nam

Re: Missing [NO] INDENT flag in XMLSerialize backward parsing

On Fri, Feb 21, 2025 at 08:38:55PM +0900, Michael Paquier wrote: > Thanks. I have used that after a second check. Let's see how it > goes. The buildfarm has turned green on v16 and v17. It is still red because of a different issue, while mine is gone. So we should be good. -- Michael signatu

Re: Psql meta-command conninfo+

> If we want to include 'role' in this output, what I'd propose is to > have \conninfo issue "SHOW role", which is accepted by every server > version. If it fails (say because we're in an aborted transaction), > just omit that row from the output. v37- would have handled this as the list of PQ pa

Re: Restrict copying of invalidated replication slots

On Fri, Feb 21, 2025 at 4:30 AM Shlok Kyal wrote: > > On Fri, 21 Feb 2025 at 01:14, Masahiko Sawada wrote: > > > > On Wed, Feb 19, 2025 at 3:46 AM Shlok Kyal wrote: > > > > > > On Tue, 18 Feb 2025 at 15:26, Zhijie Hou (Fujitsu) > > > wrote: > > > > > > > > On Monday, February 17, 2025 7:31 PM S

Re: explain analyze rows=%.0f

On Wed, Feb 19, 2025 at 9:01 AM Ilia Evdokimov wrote: > The idea of indicating to the user that different iterations produced > varying numbers of rows is quite reasonable. Most likely, this would > require adding a new boolean field to the Instrumentation structure, > which would track this infor

Re: TAP test started using meson, can get a tcp port already used by another test.

On 2025-02-21 Fr 11:49 AM, Andres Freund wrote: Hi, On 2025-02-21 11:04:49 -0500, Andrew Dunstan wrote: On 2025-02-21 Fr 10:50 AM, Andres Freund wrote: Can we explicitly set the MESON_BUILD_ROOT environment variable when running a test? With included patch for the src/tools/testwrap file, ea

Re: Statistics Import and Export

Hi, On 2025-02-21 16:24:38 -0500, Tom Lane wrote: > Oy. Those are outright horrid, even without any consideration of > pre-preparing them. We know the OID of the table we want to dump, > we should be doing "FROM pg_class WHERE oid = whatever" and lose > the join to pg_namespace altogether. The

Re: Statistics Import and Export

Andres Freund writes: > The times get way worse if you dump stats for catalog tables, because there > some of arrays are regproc and regprocout calls FuncnameGetCandidates(), which > then ends up iterating over a long cached list... I think that's basically > O(N^2)? Can't be that bad. I don't s

Re: TAP test started using meson, can get a tcp port already used by another test.

Hi, On 2025-02-21 11:04:49 -0500, Andrew Dunstan wrote: > On 2025-02-21 Fr 10:50 AM, Andres Freund wrote: > > > Can we explicitly set the MESON_BUILD_ROOT environment variable when > > > running > > > a test? With included patch for the src/tools/testwrap file, each instance > > > gets an unique

Re: Redact user password on pg_stat_statements

Matheus Alcantara writes: > Attached a patch to redact the password value from pg_stat_statements_view > when > executing: > { CREATE|ALTER} {USER|ROLE|GROUP } identifier { [WITH] [ENCRYPTED] > PASSWORD 'value' } Please see previous threads about hiding this sort of information, most recently [1

PATCH: warn about, and deprecate, clear text passwords

There have been a few complaints lately about the fact that we cavalierly allow clear text passwords to be sent when doing CREATE USER or ALTER USER. These, of course, can end up in many places, such as pg_stat_activity, pg_stat_statements, .psql_history, and the server logs. It is a genuinely vali

Re: Statistics Import and Export

Hi, On 2025-02-21 15:49:10 -0500, Tom Lane wrote: > Andres Freund writes: > > Which to me rather strongly suggests pg_dump has gotten a *lot* slower with > > this change. > > Well, it's doing strictly more work, so somewhat slower is to be > expected. Yea, if we had talked a few percent, I'd not

Re: Statistics Import and Export

Corey Huinker writes: >> I wonder whether we ought to issue different queries depending on >> whether we're superuser. The pg_stats view is rather expensive >> because of its security restrictions, and if we're superuser we >> could just look directly at pg_statistic. Maybe those checks are >> f

Re: Statistics Import and Export

> > Oy. Those are outright horrid, even without any consideration of > pre-preparing them. We know the OID of the table we want to dump, > we should be doing "FROM pg_class WHERE oid = whatever" and lose > the join to pg_namespace altogether. The explicit casts to regclass > are quite expensive

Re: BitmapHeapScan streaming read user and prelim refactoring

Thanks for the review! While editing this, I found a few things I could improve. For one, I actually wasn't using the parallel state member that I had added as a parameter to one of the table AM callbacks. So, I was able to remove that. On Thu, Feb 20, 2025 at 7:32 PM Thomas Munro wrote: > > On

Re: explain analyze rows=%.0f

On Fri, Feb 21, 2025 at 4:20 PM Robert Haas wrote: > So, I've committed v11-0001. I'm not altogether convinced that > v11-0002 is necessary -- no portion of the documentation that it > modifies is falsified by the committed patch. Maybe we can just call > this one done for now and move on? Well,

Re: [PoC] Federated Authn/z with OAUTHBEARER

> On 21 Feb 2025, at 18:18, Andres Freund wrote: > One question about interruptability. The docs say: > > Afaict the only real way to do safely across platforms is to never call > blocking functions, e.g. by using non-blocking sockets and waiting for > readiness using latches. Fair point,

Re: Statistics Import and Export

Hi, On 2025-02-21 15:23:00 -0500, Andres Freund wrote: > On 2025-02-20 01:39:34 -0800, Jeff Davis wrote: > > Committed with some revisions on top of v48: > > This made the pg_upgrade tests considerably slower. > > In an assert build without optimization (since that's what I use for normal > dev wo

Re: Amcheck verification of GiST and GIN

> On Feb 21, 2025, at 12:16 PM, Mark Dilger > wrote: > > The pgbench script is not corrupting anything overtly, so this looks to > either be a bug in gin or a bug in the check. I suspected the AccessShareLock taken by verify_gin() might be too weak, and upgraded that to ShareRowExclusiveL

Re: Statistics Import and Export

Andres Freund writes: > Which to me rather strongly suggests pg_dump has gotten a *lot* slower with > this change. Well, it's doing strictly more work, so somewhat slower is to be expected. But yeah, more than 2x slower is not nice. In a quick look at the committed patch, it doesn't seem to hav

Re: Psql meta-command conninfo+

Sami Imseih writes: >> Maybe keeping track of 'role' via ParameterStatus messages is a good >> idea for reasons unrelated to this patch -- maybe it can be useful for >> applications to be aware of role changes -- but I'm not 100% sure about >> that, and in particular I'm not sure how heavy the pro

Re: Statistics Import and Export

Hi, On 2025-02-20 01:39:34 -0800, Jeff Davis wrote: > Committed with some revisions on top of v48: This made the pg_upgrade tests considerably slower. In an assert build without optimization (since that's what I use for normal dev work): 1fd1bd87101^ 65.03s 1fd1bd87101 86.84s Looking

Re: Amcheck verification of GiST and GIN

> On Feb 21, 2025, at 9:07 AM, Mark Dilger wrote: > > I infer that you intend to make v34-0004, v34-0006, and v35-0001 apply > cleanly without the other patches and commit it that way. If that is > correct, be advised that I'm doing a review and will respond back shortly, > maybe in a few h

Re: Psql meta-command conninfo+

> Maybe keeping track of 'role' via ParameterStatus messages is a good > idea for reasons unrelated to this patch -- maybe it can be useful for > applications to be aware of role changes -- but I'm not 100% sure about > that, and in particular I'm not sure how heavy the protocol traffic is > going

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

On Thu, Feb 20, 2025 at 3:31 PM Masahiko Sawada wrote: > > On Thu, Feb 20, 2025 at 2:07 PM Noah Misch wrote: > > > > On Wed, Feb 19, 2025 at 10:48:29AM -0800, Masahiko Sawada wrote: > > > Thank you for reviewing the patches. I've fixed these issues and > > > attached the updated patches. > > > >

Re: AIO v2.2

Hi, I was just going through comments about LWLockDisown() and was reminded of this: On 2025-01-07 18:08:51 +0200, Heikki Linnakangas wrote: > On LWLockDisown(): > > + * NB: This will leave lock->owner pointing to the current backend (if > > + * LOCK_DEBUG is set). We could add a separate flag in

Re: Psql meta-command conninfo+

>You don't get "There were only 99 Luftballons" or any such nonsense, and I >don't see why \conninfo gets to play different rules. So I got rid of >\conninfo+. >From my perspective across this, I support this approach. Regards, Maiquel.

Re: Psql meta-command conninfo+

Alvaro Herrera writes: > Do people hate the question marks? They feel not per our usual style. I think the output would be equally readable without them. Otherwise, +1 for this general approach. I agree we can just kick the current output format to the curb. regards, t

Re: Psql meta-command conninfo+

I suggest the attached, which gets 99% there with 10% of the complexity, and has \conninfo (no plus sign) output this: Connection Information Parámetro │ Valor ───┼ Base de Datos │ alvherre Client Use

Re: MAX_BACKENDS size (comment accuracy)

Hi, On 2025-01-26 12:55:15 -0800, Jacob Brazeal wrote: > The patch series looks good. Thanks for reviewing! And sorry for not getting back to you about your review comments earlier. > > StaticAssertDecl((MAX_BACKENDS & LW_FLAG_MASK) == 0, > > "MAX_BACKENDS and LW_FLAG_MASK overlap"); > > Sh

Re: Extend postgres_fdw_get_connections to return remote backend pid

Hi Fujii, > Could you update that? I apologize. Updated documentation. Please review and let me know if you have suggestions to improve wording. On Fri, Feb 21, 2025 at 7:56 PM Fujii Masao wrote: > > > > On 2025/02/21 22:43, Sagar Shedge wrote: > > Hi Fujii, > > > > Please review the latest patc

Re: Amcheck verification of GiST and GIN

> On 21 Feb 2025, at 19:29, Tomas Vondra wrote: > > I see this patch didn't move since December :-( I still think these > improvements would be useful, it certainly was very helpful when I was > working on the GIN/GiST parallel builds (the GiST builds stalled, but I > hope to push the GIN patc

Re: Amcheck verification of GiST and GIN

On 2/21/25 18:07, Mark Dilger wrote: > > >> On Feb 21, 2025, at 6:29 AM, Tomas Vondra wrote: >> >> Hi, >> >> I see this patch didn't move since December :-( I still think >> these improvements would be useful, it certainly was very helpful >> when I was working on the GIN/GiST parallel builds

Re: Virtual generated columns

On Fri, 21 Feb 2025 at 06:16, Richard Guo wrote: > > Yeah, it's annoying that the two replace_rte_variables callbacks have > so much code duplication. I think it's a win to make them share > common code. What do you think about making this refactor a separate > patch, as it doesn't seem directly

Re: [PoC] Federated Authn/z with OAUTHBEARER

Hi, On 2025-02-20 09:28:36 -0800, Jacob Champion wrote: > On Thu, Feb 20, 2025 at 8:30 AM Daniel Gustafsson wrote: > > I spent a few more hours staring at this, and ran it through a number of CI > > and > > local builds, without anything showing up. Pushed to master with the first > > set > >

Re: Redact user password on pg_stat_statements

Andrew Dunstan writes: > On 2025-02-21 Fr 11:08 AM, Tom Lane wrote: >> Please see previous threads about hiding this sort of information, >> most recently [1]. It's a slippery slope for which there are no >> real fixes, and even partial fixes like this one are horrid kluges. > I don't think this

Re: Amcheck verification of GiST and GIN

> On Feb 21, 2025, at 6:29 AM, Tomas Vondra wrote: > > Hi, > > I see this patch didn't move since December :-( I still think these > improvements would be useful, it certainly was very helpful when I was > working on the GIN/GiST parallel builds (the GiST builds stalled, but I > hope to push

Re: Redact user password on pg_stat_statements

Greg Sabino Mullane writes: > I'm wondering what else we can do to discourage this pattern, however. > There are more secure ways to set/change a password, but we keep seeing > plain text pop up in various contexts. Maybe a strong warning+hint when > someone uses these commands? A future GUC to di

Re: Redact user password on pg_stat_statements

On 2025-02-21 Fr 11:08 AM, Tom Lane wrote: Matheus Alcantara writes: Attached a patch to redact the password value from pg_stat_statements_view when executing: { CREATE|ALTER} {USER|ROLE|GROUP } identifier { [WITH] [ENCRYPTED] PASSWORD 'value' } Please see previous threads about hiding this

Re: GetRelationPath() vs critical sections

Hi, On 2025-02-21 18:20:39 +1300, Thomas Munro wrote: > On Fri, Feb 21, 2025 at 9:28 AM Andres Freund wrote: > > The patch curently uses a hardcoded 6 for the length of MAX_BACKENDS. Does > > anybody have a good idea for how to either > > > > a) derive 6 from MAX_BACKENDS in a way that can be use

Re: Redact user password on pg_stat_statements

> It's a slippery slope for which there are no > real fixes, and even partial fixes like this one are horrid kluges. +1, For example I don't think the current patch can deal with passwords set in ALTER/CREATE inside DO blocks, and there is probably not a sensible way to deal with that either. Re

Re: TAP test started using meson, can get a tcp port already used by another test.

On 2025-02-21 Fr 10:50 AM, Andres Freund wrote: Can we explicitly set the MESON_BUILD_ROOT environment variable when running a test? With included patch for the src/tools/testwrap file, each instance gets an unique TCP port. I don't like that, feels like a "namespace violation" to set a MES

Re: generic plans and "initial" pruning

Amit Langote writes: > The short of it is that the cached-plan-inval test in the > delay_execution suite can never be made to work under > CLOBBER_CACHE_ALWAYS. The test assumes that locks on partitions for a > reused generic plan are not taken until InitPlan(). However, under > CLOBBER_CACHE_ALWA

Re: TAP test started using meson, can get a tcp port already used by another test.

Hi, On 2025-02-21 15:58:45 +0700, Zharkov Roman wrote: > We running TAP tests which operates with a lot of instances. And some of > these tests randomly fail due "address already in use". It turned out that > the meson does not set environment variable MESON_BUILD_ROOT when running > the test() fu

Re: Redact user password on pg_stat_statements

The idea and the patch looks good to me at first glance, +1. I'm wondering what else we can do to discourage this pattern, however. There are more secure ways to set/change a password, but we keep seeing plain text pop up in various contexts. Maybe a strong warning+hint when someone uses these com

Redact user password on pg_stat_statements

Hi hackers! Attached a patch to redact the password value from pg_stat_statements_view when executing: { CREATE|ALTER} {USER|ROLE|GROUP } identifier { [WITH] [ENCRYPTED] PASSWORD 'value' } To redact the password from the pg_stat_statements view a new field location was added on String type which

Re: SQL:2011 application time

On 17.02.25 07:42, Paul Jungwirth wrote: After staring at this a bit more, I think my interpretation above was not correct.  This seems better: The clause "Execution of referential actions" in the SQL standard only talks about referenced and referencing columns, not periods.  The RESTRICT erro

Re: Missing [NO] INDENT flag in XMLSerialize backward parsing

Michael Paquier writes: > On Fri, Feb 21, 2025 at 12:29:12PM +0100, Jim Jones wrote: >> For future reference, what’s the best way to verify this myself? The >> buildfarm was all green. > Don't worry, we are all trapped by that at some point. Yeah, I leave that to the buildfarm too. If I have to

Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints

On 2025-Feb-21, Alvaro Herrera wrote: > I see a nonrepeatable problem under valgrind which I'm going to look > into. Sorry, pilot error. The pg_upgrade test works fine under valgrind. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Having your biases confirmed

Re: Fix logging for invalid recovery timeline

On 2/20/25 4:40 PM, David Steele wrote: Benoit -- this was your idea. Did you want to submit a patch yourself? Here is an attempt at that. I kept the wording I used above. Is it fine to repeat the whole ereport block twice? -- Benoit Lobréau Consultant http://dalibo.com From 44459bf799fca517

Doubts regarding pg_freespacemap extension

Hi PostgreSQL Community, While exploring the pg_freespacemap extension, I came across a few doubts and would appreciate any insights or clarifications: 1. In the code, it defines NonLeafNodesPerPage as (BLCKSZ / 2 - 1) as can be seen here: https://github.com/postgres/postgres/blob/master/src/in

Re: Enhancing Memory Context Statistics Reporting

On 2/20/25 14:26, Rahila Syed wrote: > Hi, > > Please find attached the updated patches after some cleanup and test > fixes.   > > Thank you, > Rahila Syed > > On Tue, Feb 18, 2025 at 6:35 PM Rahila Syed > wrote: > > Hi, > > > Thanks for updating th

Re: dblink: Add SCRAM pass-through authentication

Hi, thanks for all the reviews. Attached v3 with some fixes. > They also check for GSS delegation. I think SCRAM passthrough should > ideally be considered a second form of credentials delegation, from > the perspective of those functions. > Changed dblink_connstr_check and dblink_security_check t

Re: Amcheck verification of GiST and GIN

Hi, I see this patch didn't move since December :-( I still think these improvements would be useful, it certainly was very helpful when I was working on the GIN/GiST parallel builds (the GiST builds stalled, but I hope to push the GIN patches soon). So I'd like to get some of this in too. I'm no

Re: Extend postgres_fdw_get_connections to return remote backend pid

On 2025/02/21 22:43, Sagar Shedge wrote: Hi Fujii, Please review the latest patch. Thanks for updating the patch! Could you add descriptions for postgres_fdw_get_connections()? Done. Thanks! But, I realize my previous comment may have been unclear. I was referring to updating doc/src/

Re: Doc fix of aggressive vacuum threshold for multixact members storage

> Maybe we could also add a comment in multixact.c to update the doc > accordingly if > the computation changes? (I think that will be easy to miss). Thanks for the comments! I rather we not touch the .c file for this update. It's unlikely the actual computation will change. Regards, Sami Imse

Re: Support for NO INHERIT to INHERIT state change with named NOT NULL constraints

Thanks, Alvaro. I have revised the patch as per your last update. Please find attached v5 for further review. -- Thanks & Regards, Suraj kharage, enterprisedb.com On Wed, Feb 19, 2025 at 9:16 PM Alvaro Herrera wrote: > On 2025-Feb-10, Suraj Kharage wrote: >

Re: Extend postgres_fdw_get_connections to return remote backend pid

Hi Fujii, Please review the latest patch. > Could you add descriptions for postgres_fdw_get_connections()? Done. > how about verifying it against pg_stat_activity? Yes. This approach will make tests more reliable. Updated. On Fri, Feb 21, 2025 at 8:15 AM Fujii Masao wrote: > > > > On 2025/02/

Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints

On 2025-Feb-21, Ashutosh Bapat wrote: > If I apply your patches, build binaries, I see failure. I reverted > your patches, built binaries, I don't see failure. I apply your > patches again, built binaries, it fails again. I can't reproduce the problem either. Are you running asserts disabled or

Re: Restrict copying of invalidated replication slots

On Fri, 21 Feb 2025 at 01:14, Masahiko Sawada wrote: > > On Wed, Feb 19, 2025 at 3:46 AM Shlok Kyal wrote: > > > > On Tue, 18 Feb 2025 at 15:26, Zhijie Hou (Fujitsu) > > wrote: > > > > > > On Monday, February 17, 2025 7:31 PM Shlok Kyal > > > wrote: > > > > > > > > On Thu, 13 Feb 2025 at 15:54

Re: Missing [NO] INDENT flag in XMLSerialize backward parsing

On 21.02.25 12:46, Michael Paquier wrote: > One way would be to generate by yourself dumps from an older version > by yourself, as documented by src/bin/pg_upgrade/TESTING, part DETAILS > (the part about USE_MODULE_DB=1 is very important). Then you can > reuse the SQL files by specifying an old

Re: Support POSITION with nondeterministic collations

On 12.02.25 05:31, Euler Taveira wrote: On Mon, Dec 2, 2024, at 6:09 AM, Peter Eisentraut wrote: On 26.08.24 08:09, Peter Eisentraut wrote: > This patch allows using text position search functions with > nondeterministic collations.  These functions are > > - position, strpos > - replace > - spl

Re: Missing [NO] INDENT flag in XMLSerialize backward parsing

On Fri, Feb 21, 2025 at 12:29:12PM +0100, Jim Jones wrote: > For future reference, what’s the best way to verify this myself? The > buildfarm was all green. Don't worry, we are all trapped by that at some point. One way would be to generate by yourself dumps from an older version by yourself, as

Re: Simplify the logic a bit (src/bin/scripts/reindexdb.c)

Em sex., 14 de fev. de 2025 às 10:19, Ranier Vilela escreveu: > Em sex., 14 de fev. de 2025 às 09:13, Ranier Vilela > escreveu: > >> Hi Álvaro. >> >> Em qui., 13 de fev. de 2025 às 18:38, Álvaro Herrera < >> alvhe...@alvh.no-ip.org> escreveu: >> >>> On 2025-Feb-13, Ranier Vilela wrote: >>> >>> >

Re: Missing [NO] INDENT flag in XMLSerialize backward parsing

On Fri, Feb 21, 2025 at 05:46:52AM -0500, Andrew Dunstan wrote: > I think so. Looks good to me Thanks. I have used that after a second check. Let's see how it goes. -- Michael signature.asc Description: PGP signature

Re: Missing [NO] INDENT flag in XMLSerialize backward parsing

Hi Michael & Andrew On 21.02.25 11:46, Andrew Dunstan wrote: >> On Feb 21, 2025, at 4:55 AM, Michael Paquier wrote: >> >> On Fri, Feb 21, 2025 at 04:36:07AM -0500, Andrew Dunstan wrote: >>> The fix has broken cross version upgrade test. Maybe we need to filter out >>> NO INDENT in releases prior

Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning

> On Mon, Nov 25, 2024 at 11:20:05AM GMT, Ashutosh Bapat wrote: > > I've tried to reproduce some subset of those results, in case if I would > > be able to notice anything useful. Strangely enough, I wasn't able to > > get much boost in planning time e.g. with 4 first patches, 100 > > partitions an

Fix crash during recovery when redo segment is missing

Hi, In [1], Andres reported a bug where PostgreSQL crashes during recovery if the segment containing the redo pointer does not exist. I have attempted to address this issue and I am sharing a patch for the same. The problem was that PostgreSQL did not PANIC when the redo LSN and checkpoint LSN we

Re: pg_recvlogical requires -d but not described on the documentation

On Fri, Feb 21, 2025 at 2:25 PM Hayato Kuroda (Fujitsu) wrote: > > Dear Ashutosh, > > Thanks for the reply. > > > > ISTM the inconsistency is introduced since the initial commit. I think > > > they should > > be unified either > > > 1) update the doc or 2) accept when -d is not specified. Persona

Re: Missing [NO] INDENT flag in XMLSerialize backward parsing

> On Feb 21, 2025, at 4:55 AM, Michael Paquier wrote: > > On Fri, Feb 21, 2025 at 04:36:07AM -0500, Andrew Dunstan wrote: >> The fix has broken cross version upgrade test. Maybe we need to filter out >> NO INDENT in releases prior to 16 in AdjustUpgrade.pm?s > > Yes, I was just looking at t

Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints

On Fri, Feb 21, 2025 at 3:37 PM Rushabh Lathia wrote: > > > > On Fri, Feb 21, 2025 at 2:59 PM Ashutosh Bapat > wrote: >> >> On Fri, Feb 21, 2025 at 11:43 AM Alvaro Herrera >> wrote: >> > >> > I have not looked at the pg_dump code yet, so the changes included here >> > are just pgindent. >> > >

Re: Bibliography section, some references cannot be found

> On 14 May 2024, at 08:51, Daniel Gustafsson wrote: > >> On 14 May 2024, at 07:40, jian he wrote: > >> I googled around, still cannot find [olson93] related pdf or html link. > > Judging by the bibliography reference it's a technical report from UCB, and > searching for the T7 identifier in t

Remove vardata parameters from eqjoinsel_inner

Hi hackers, When calculating selectivity for an inner equijoin, we call eqjoinsel_inner, which uses unused parameters vardata1 and vardata2. These parameters might have been left behind accidentally when we moved getting sslots out of the function. I suggest removing them, as they can be adde

Re: TAP test started using meson, can get a tcp port already used by another test.

On 2025-02-21 Fr 3:58 AM, Zharkov Roman wrote: Hello, We running TAP tests which operates with a lot of instances. And some of these tests randomly fail due "address already in use". It turned out that the meson does not set environment variable MESON_BUILD_ROOT when running the test() func

Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints

On Fri, Feb 21, 2025 at 2:59 PM Ashutosh Bapat wrote: > On Fri, Feb 21, 2025 at 11:43 AM Alvaro Herrera > wrote: > > > > I have not looked at the pg_dump code yet, so the changes included here > > are just pgindent. > > > > I ran pg_upgrade suite with the patches. 002_pg_upgrade fails with > fol

Re: Missing [NO] INDENT flag in XMLSerialize backward parsing

On Fri, Feb 21, 2025 at 04:36:07AM -0500, Andrew Dunstan wrote: > The fix has broken cross version upgrade test. Maybe we need to filter out > NO INDENT in releases prior to 16 in AdjustUpgrade.pm? Yes, I was just looking at that. The regex I am finishing with in AdjustUpgrade.pm is something lik

Re: TAP test started using meson, can get a tcp port already used by another test.

On 2025-02-21 16:32, Andrew Dunstan wrote: In the meantime you can do what the buildfarm client does and explicitly set PG_TEST_PORT_DIR. Thank you for the answer! We tried to set PG_TEST_PORT_DIR using the 'env' option and it works fine. Best regards, Roman Zharkov

Re: Doc fix of aggressive vacuum threshold for multixact members storage

Hi, On Tue, Feb 04, 2025 at 01:23:28PM -0600, Sami Imseih wrote: > I confirmed the 20GB value as is described here [1]. > 8k page can hold 409 member groups and each > member group can hold 4 members, thus > (2^32/(409 *4))*8192 = 20GB. > Thanks for the patch! I do agree that that's a bug in th

RE: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.

Dear Shubham, Thanks for updating the patch. Here are comments. 01. ``` /* * Create the subscriptions, adjust the initial location for logical * replication and enable the subscriptions. That's the last step for logical * replication setup. If 'drop_publications' is true, existing publications

Re: Missing [NO] INDENT flag in XMLSerialize backward parsing

On 2025-02-21 Fr 1:31 AM, Michael Paquier wrote: On Thu, Feb 20, 2025 at 02:27:42PM +0100, Jim Jones wrote: This patch adds the missing [NO] INDENT flag to XMLSerialize backward parsing. if (xexpr->op == IS_XMLSERIALIZE) + { appendStringInfo(buf, " AS %s",

Re: XMLSerialize: version and explicit XML declaration

On 30.09.24 10:08, Jim Jones wrote: > On 25.09.24 18:02, Tom Lane wrote: >> AFAICS, all we do with an embedded XML version string is pass it to >> libxml2's xmlNewDoc(), which is the authority on whether it means >> anything. I'd be inclined to do the same here. > Thanks. I used xml_is_document()

Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints

On Fri, Feb 21, 2025 at 11:43 AM Alvaro Herrera wrote: > > I have not looked at the pg_dump code yet, so the changes included here > are just pgindent. > I ran pg_upgrade suite with the patches. 002_pg_upgrade fails with following test log not ok 14 - run of pg_upgrade for new instance not ok 15

TAP test started using meson, can get a tcp port already used by another test.

Hello, We running TAP tests which operates with a lot of instances. And some of these tests randomly fail due "address already in use". It turned out that the meson does not set environment variable MESON_BUILD_ROOT when running the test() function [0]. As a result each test uses its own "por

  1   2   >