Re: fix cost subqueryscan wrong parallel cost

On Fri, Apr 15, 2022 at 05:16:44PM +0800, Richard Guo wrote: > Not related to this topic but I noticed another problem from the plan. > Note the first Sort node which is to unique-ify the result of the UNION. > Why cannot we re-arrange the sort keys from (a, b, c) to (a, c, b) so > that we can

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

On Thu, Apr 14, 2022 at 4:26 PM Tom Lane wrote: > > > Well, if that's true, then I agree that it's a good argument against > > that approach. But I guess I'm confused as to why we'd end up in that > > situation. Suppose we do these two things: > > > 1. Decree that SnapshotResetXmin calls

Re: pgsql: Add TAP test to automate the equivalent of check_guc

Re: Michael Paquier > > I was confusing that with this: The problem that led to the pg_config > > patch years ago was that we have a /usr/bin/pg_config in > > (non-major-version-dependant) libpq-dev, and > > /usr/lib/postgresql/NN/bin/pg_config in the individual > > postgresql-server-dev-NN

Re: CLUSTER on partitioned index

Thanks for the patch -- I have pushed it now, with some wording changes and renaming the role to regress_* to avoid buildfarm's ire. Michaël in addition proposes an isolation test. I'm not sure; is it worth the additional test run time? It doesn't seem a critical issue. But if anybody feels

Re: Re: fix cost subqueryscan wrong parallel cost

> Generally it should be. But there's no subquery scan visible here. I wrote a patch for distinct/union and aggregate support last year(I want restart it again). https://www.postgresql.org/message-id/2021091517250848215321%40sohu.com If not apply this patch, some parallel paths will naver be

Inconsistent "ICU Locale" output on older server versions

Re: To Peter Eisentraut > This hardly fits in normal-size terminals: > > =# \l > List of databases >Name│ Owner │ Encoding │ Collate │ Ctype│ ICU Locale │ Locale > Provider │ Access privileges >

Re: fix cost subqueryscan wrong parallel cost

On Fri, Apr 15, 2022 at 12:50 AM Robert Haas wrote: > On Tue, Apr 12, 2022 at 2:57 AM bu...@sohu.com wrote: > > The cost_subqueryscan function does not judge whether it is parallel. > > I don't see any reason why it would need to do that. A subquery scan > isn't parallel aware. > > > regress >

Re: Intermittent buildfarm failures on wrasse

The morning's first result is that during a failing run, the vacuum in test_setup sees 2022-04-15 16:01:43.064 CEST [4436:75] pg_regress/test_setup LOG: statement: VACUUM ANALYZE tenk1; 2022-04-15 16:01:43.064 CEST [4436:76] pg_regress/test_setup LOG: vacuuming

Re: Intermittent buildfarm failures on wrasse

Hi, On April 15, 2022 11:12:10 AM EDT, Andres Freund wrote: >Hi, > >On 2022-04-15 10:15:32 -0400, Tom Lane wrote: >> The morning's first result is that during a failing run, >> the vacuum in test_setup sees >> >> 2022-04-15 16:01:43.064 CEST [4436:75] pg_regress/test_setup LOG: >> statement:

Re: Inconsistent "ICU Locale" output on older server versions

On Fri, Apr 15, 2022, at 11:58 AM, Christoph Berg wrote: > When running psql 15 against PG 14, the output is this: > > $ psql -l > List of databases >Name│ Owner │ Encoding │ Collate │ Ctype│ ICU Locale │ > Locale Provider │

Re: Intermittent buildfarm failures on wrasse

Andres Freund writes: > Off for a bit, but I realized that we likely don't exclude the launcher > because it's not database associated... Yeah. I think this bit in ComputeXidHorizons needs rethinking: /* * Normally queries in other databases are ignored for anything but

Re: Intermittent buildfarm failures on wrasse

On Fri, Apr 15, 2022 at 10:43 AM Andres Freund wrote: > I think it'd be interesting - particularly for large relations or when > looking to adjust autovac cost limits. > Something like: > removable cutoff: %u, age at start: %u, age at end: %u... Part of the problem here is that we determine

Re: Intermittent buildfarm failures on wrasse

Hi, On April 15, 2022 2:14:47 PM EDT, Tom Lane wrote: >Andres Freund writes: >> On 2022-04-15 12:36:52 -0400, Tom Lane wrote: >>> Yeah, I was also thinking about a flag in PGPROC being a more reliable >>> way to do this. Is there anything besides walsenders that should set >>> that flag? > >>

Re: Intermittent buildfarm failures on wrasse

I wrote: > the vacuum in test_setup sees > ... > removable cutoff: 724, older by 26 xids when operation ended > ... BTW, before I forget: the wording of this log message is just awful. On first sight, I thought that it meant that we'd computed OldestXmin a second time and discovered that

Re: deparsing utility commands

On Wed, Apr 13, 2022 at 2:12 PM Shulgin, Oleksandr wrote: > > >> You seem to have squashed the patches? Please keep the split out. > > > Well, if that makes the review process easier :-) > > -- > Alex > I've rebased patches 1, 2 and 5 (now 1,2 and 3). Patches 3 and 4 seem to be related to the

Re: Intermittent buildfarm failures on wrasse

Peter Geoghegan writes: > On Fri, Apr 15, 2022 at 8:14 AM Tom Lane wrote: >> BTW, before I forget: the wording of this log message is just awful. >> [ so how about ] >> "removable cutoff: %u, which was %d xids old when operation ended\n" > How the output appears when placed right before the

Re: Inconsistent "ICU Locale" output on older server versions

"Euler Taveira" writes: > On Fri, Apr 15, 2022, at 11:58 AM, Christoph Berg wrote: >> When running psql 15 against PG 14, the output is this: >> The "ICU Locale" column is now populated, that seems wrong. > Good catch! Indeed. > Since dataiculocale allows NULL, my suggestion is to use NULL

Re: Intermittent buildfarm failures on wrasse

On Fri, Apr 15, 2022 at 9:40 AM Tom Lane wrote: > > Do you think that this juxtaposition works well? > > Seems all right to me; do you have a better suggestion? No. At first I thought that mixing "which is" and "which was" wasn't quite right. I changed my mind, though. Your new wording is fine.

Re: Intermittent buildfarm failures on wrasse

Hi, (Sent again, somehow my editor started to sometimes screw up mail headers, and ate the From:, sorry for the duplicate) On 2022-04-15 12:36:52 -0400, Tom Lane wrote: > Andres Freund writes: > > On April 15, 2022 11:23:40 AM EDT, Tom Lane wrote: > >> The something is the logical replication

Re: Intermittent buildfarm failures on wrasse

On Fri, Apr 15, 2022 at 10:05 AM Andres Freund wrote: > I don't think they're actually that comparable. One shows how much > relfrozenxid advanced, to a large degree influenced by the time between > aggressive (or "unintentionally aggressive") vacuums. It matters more in the extreme cases. The

Re: Intermittent buildfarm failures on wrasse

On Fri, Apr 15, 2022 at 8:14 AM Tom Lane wrote: > BTW, before I forget: the wording of this log message is just awful. > On first sight, I thought that it meant that we'd computed OldestXmin > a second time and discovered that it advanced by 26 xids while the VACUUM > was running. > "removable

Re: Intermittent buildfarm failures on wrasse

Andres Freund writes: > On April 15, 2022 11:23:40 AM EDT, Tom Lane wrote: >> The something is the logical replication launcher. In the failing runs, >> it is advertising xmin = 724 (the post-initdb NextXID) and continues to >> do so well past the point where tenk1 gets vacuumed. > That

Re: Intermittent buildfarm failures on wrasse

I wrote: > Um, this is the logical replication launcher, not the autovac launcher. > Your observation that a sleep in get_database_list() reproduces it > confirms that, and I don't entirely see why the timing of the LR launcher > would have changed. Oh, to clarify: I misread "get_database_list()"

Re: Intermittent buildfarm failures on wrasse

Hi, On 2022-04-15 09:29:20 -0700, Peter Geoghegan wrote: > On Fri, Apr 15, 2022 at 8:14 AM Tom Lane wrote: > > BTW, before I forget: the wording of this log message is just awful. > > On first sight, I thought that it meant that we'd computed OldestXmin > > a second time and discovered that it

Re: Intermittent buildfarm failures on wrasse

On Fri, Apr 15, 2022 at 10:15 AM Tom Lane wrote: > > As well as the age of OldestXmin at the start of VACUUM. > > Is it worth capturing and logging both of those numbers? Why is > the age at the end more interesting than the age at the start? As Andres said, that's often more interesting

Re: Intermittent buildfarm failures on wrasse

Hi, On 2022-04-15 10:15:32 -0400, Tom Lane wrote: > The morning's first result is that during a failing run, > the vacuum in test_setup sees > > 2022-04-15 16:01:43.064 CEST [4436:75] pg_regress/test_setup LOG: statement: > VACUUM ANALYZE tenk1; > 2022-04-15 16:01:43.064 CEST [4436:76]

Re: Intermittent buildfarm failures on wrasse

I wrote: > So there's no longer any doubt that something is holding back OldestXmin. > I will go put some instrumentation into the code that's computing that. The something is the logical replication launcher. In the failing runs, it is advertising xmin = 724 (the post-initdb NextXID) and

Re: Intermittent buildfarm failures on wrasse

Hi, On April 15, 2022 11:23:40 AM EDT, Tom Lane wrote: >I wrote: >> So there's no longer any doubt that something is holding back OldestXmin. >> I will go put some instrumentation into the code that's computing that. > >The something is the logical replication launcher. In the failing runs,

Re: deparsing utility commands

On Thu, Apr 14, 2022 at 12:19 AM Peter Eisentraut wrote: > The patch you posted contains neither a detailed commit message nor > documentation or test changes, so it's impossible to tell what it's > supposed to do. > Sorry, I was only rebasing the patches and have kept the same commit messages

Re: Intermittent buildfarm failures on wrasse

Hi, On 2022-04-15 12:36:52 -0400, Tom Lane wrote: > Andres Freund writes: > > On April 15, 2022 11:23:40 AM EDT, Tom Lane wrote: > >> The something is the logical replication launcher. In the failing runs, > >> it is advertising xmin = 724 (the post-initdb NextXID) and continues to > >> do so

Crash in new pgstats code

mylodon just showed a new-to-me failure mode [1]: Core was generated by `postgres: cascade: startup recovering 00010002'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 49

Re: Intermittent buildfarm failures on wrasse

Hi, On 2022-04-15 10:23:56 -0700, Peter Geoghegan wrote: > On Fri, Apr 15, 2022 at 10:15 AM Tom Lane wrote: > > > As well as the age of OldestXmin at the start of VACUUM. > > > > Is it worth capturing and logging both of those numbers? Why is > > the age at the end more interesting than the age

Re: Intermittent buildfarm failures on wrasse

Andres Freund writes: > On 2022-04-15 12:36:52 -0400, Tom Lane wrote: >> Yeah, I was also thinking about a flag in PGPROC being a more reliable >> way to do this. Is there anything besides walsenders that should set >> that flag? > Not that I can think of. It's only because of hs_feedback that

Re: Intermittent buildfarm failures on wrasse

Andres Freund writes: > On 2022-04-15 10:15:32 -0400, Tom Lane wrote: >> removable cutoff: 724, older by 26 xids when operation ended > The horizon advancing by 26 xids during tenk1's vacuum seems like quite > a bit, given there's no normal concurrent activity during test_setup. Hah, so you

Re: Intermittent buildfarm failures on wrasse

Peter Geoghegan writes: > On Fri, Apr 15, 2022 at 10:05 AM Andres Freund wrote: >> The other shows >> the age of OldestXmin at the end of the vacuum. Which is influenced by >> what's currently running. > As well as the age of OldestXmin at the start of VACUUM. Is it worth capturing and logging

Re: Intermittent buildfarm failures on wrasse

Andres Freund writes: > On April 15, 2022 2:14:47 PM EDT, Tom Lane wrote: >> I could use some help filling in the XXX comments, because it's far >> from clear to me *why* walsenders need this to happen. > If you want to commit before: The reason is that walsenders use their xmin > to

GSOC-2022 | Improve pgarchives proposal review

Hello, I am a pre-final year student of IIT Jodhpur, pursuing my BTech in computer science and engineering. As a part of GSOC 2022, I would like to work on the project *Improve pgarchives*. I have prepared the final draft of the proposal and would like to receive suggestions/feedback on it.

Re: [GSOC-22] Proposal Review

Thanks for the proposal, Arjun! This looks good to me. Ilaria On 14.04.22 17:33, Arjun Prashanth wrote: Hello, Herewith attach my GSOC22 Proposal and request for reviews and comments Looking

Re: Crash in new pgstats code

I wrote: > mylodon just showed a new-to-me failure mode [1]: Another occurrence here: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kestrel=2022-04-15%2022%3A42%3A07 I've added an open item. regards, tom lane

Re: GSOC: New and improved website for pgjdbc (JDBC) (2022)

Hello Keshav, I quickly went through your proposal and it seems like it could be extended a bit. Do you have in mind a potential layout for the deliverables? Can you split the timeline week by week or at least in 2 week blocks? Can you state any major issues with the current website and how

Add version and data directory to initdb output

Hackers, initdb is already pretty chatty, and the version of the cluster being installed seems useful to include as well. The data directory is probably less so - though I am thinking that the absolute path would be useful to report, especially when a relative path is specified (I didn't figure

Re: pgsql: Add TAP test to automate the equivalent of check_guc

On Fri, Apr 15, 2022 at 04:49:28PM +0200, Christoph Berg wrote: > Since build-time testing broke again about two weeks ago due to > Debian's pg_config patch, I revisited the situation and found that the > patch is in fact no longer necessary to support pg_config in /usr/bin: > > To support

Re: Skipping logical replication transactions on subscriber side

On Thu, Apr 07, 2022 at 08:39:58PM +0900, Masahiko Sawada wrote: > On Thu, Apr 7, 2022 at 7:28 PM Amit Kapila wrote: > > On Thu, Apr 7, 2022 at 8:25 AM Amit Kapila wrote: > > > I'll take care of this today. I think we can mark the new function > > > get_column_offset() being introduced by this

WIP: Aggregation push-down - take2

Hi everyone. I develop postgresql's extension such as fdw in my work. I'm interested in using postgresql for OLAP. After [1] having been withdrawn, I reviewed [1]. I think that this patch is realy useful when using OLAP queries. Furthermore, I think it would be more useful if this patch works

Re: Printing backtrace of postgres processes

At Thu, 14 Apr 2022 10:33:50 +0530, vignesh C wrote in > On Wed, Apr 6, 2022 at 12:29 PM vignesh C wrote: > > > > On Tue, Apr 5, 2022 at 9:18 PM Robert Haas wrote: > > > This looks like a grotty hack. > > > > I have changed it so that the backtrace is set and returned to the > > caller. The

Re: Add --{no-,}bypassrls flags to createuser

At Fri, 15 Apr 2022 14:55:48 +0900, Shinya Kato wrote in > I understand. For backward compatibility, I left the ROLE clause > option as it is and changed the IN ROLE clause option to --membership > option. Thanks! - printf(_(" -g, --role=ROLE new role will be a member of this

Re: BufferAlloc: don't take two simultaneous locks

At Thu, 14 Apr 2022 11:02:33 -0400, Robert Haas wrote in > It seems to me that whatever hazards exist must come from the fact > that the operation is no longer fully atomic. The existing code > acquires every relevant lock, then does the work, then releases locks. > Ergo, we don't have to worry