Re: Exposing the lock manager's WaitForLockers() to SQL

I got some very helpful off-list feedback from Robert Haas that this needed more self-contained explanation/motivation. So here goes. :-) This patch set adds a new SQL function pg_wait_for_lockers(), which waits for transactions holding specified table locks to commit or roll back. This can be use

Re: Exposing the lock manager's WaitForLockers() to SQL

I should add that the latest patches remove permissions checks because pg_locks doesn't have any, and improve the commit messages. Hope I didn't garble anything doing this late after the dev conference. :-) Robert asked me about other existing functions that could be leveraged, such as GetConflict

Re: meson "experimental"?

Hi. > "Alternatively, PostgreSQL can be built using Meson. This is the only > option for building PostgreSQL in Windows using Visual Something[*]. > For other platforms, using Meson is currently experimental." +1 good catch > [*] What is the correct name for this? I believe in this section it

Re: meson "experimental"?

Hi, > > [*] What is the correct name for this? > > I believe in this section it should be "Visual Studio" as we specify > elsewhere [1][2]. In [2] we name specific required versions. Maybe we > should reference this section. > > While on it, in [2] section 17.7.5 is named "Visual". I don't think >

Re: Implementing CustomScan over an index

Hi, > So I started implementing a CustomScan. It's not trivial. > > I've learned that the system executes ExecInitCustomScan automatically, but I > probably need it to do most of the stuff in ExecInitIndexScan, and then > execute the scan mostly the way it's done in IndexNext. > > Basically, I w

The xversion-upgrade test fails to stop server

Hello Andrew, While reviewing recent buildfarm failures, I came across this one: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2024-05-23%2004%3A11%3A03 upgrade.crake/REL_16_STABLE/REL9_5_STABLE-ctl4.log waiting for server to shut down.

Re: meson "experimental"?

On Thu, May 30, 2024 at 6:32 AM Aleksander Alekseev < aleksan...@timescale.com> wrote: > > > By a quick look on the buildfarm we seem to use Ninja >= 1.11.1. > However since Meson can use both Ninja and VS as a backend I'm not > certain which section would be most appropriate for naming the minima

Re: Add LSN <-> time conversion functionality

Hi everyone! Me, Bharath, and Ilya are on patch review session at the PGConf.dev :) Maybe we got everything wrong, please consider that we are just doing training on reviewing patches. === Purpose of the patch === Currently, we have checkpoint_timeout and max_wal size to know when we need a c

Re: The xversion-upgrade test fails to stop server

Sent from my iPhone > On May 30, 2024, at 8:00 AM, Alexander Lakhin wrote: > > Hello Andrew, > > While reviewing recent buildfarm failures, I came across this one: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2024-05-23%2004%3A11%3A03 > > upgrade.crake/REL_16_STABLE/RE

Vacuum statistics

Hello, everyone! I think we don't have enough information to analyze vacuum functionality. Needless to say that the vacuum is the most important process for a database system. It prevents problems like table and index bloating and emergency freezing if we have a wraparound problem. Furthermore

Re: [PATCH] psql: \dn+ to show size of each schema (and \dA+ for AMs)

Hi Justin, Thanks for the patch and the work on it. In reviewing the basic feature, I think this is something that has utility and is worthwhile at the high level. A few more specific notes: The pg_namespace_size() function can stand on its own, and probably has some utility for the released Po

Re: Vacuum statistics

On 30.05.2024 10:33, Alena Rybakina wrote: I suggest gathering information about vacuum resource consumption for processing indexes and tables and storing it in the table and index relationships (for example, PgStat_StatTabEntry structure like it has realized for usual statistics). It will al

Re: Vacuum statistics

Hi, Th, 30/05/2024 at 10:33 -0700, Alena Rybakina wrote: > I suggest gathering information about vacuum resource consumption for > processing indexes and tables and storing it in the table and index > relationships (for example, PgStat_StatTabEntry structure like it has > realized for usual stati

Re: Add memory context type to pg_backend_memory_contexts view

Hi David, Giving this a once-through, this seems straightforward and useful. I have a slight preference for keeping "name" the first field in the view and moving "type" to the second, but that's minor. Just confirming that the allocator types are not extensible without a recompile, since it's us

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

On Tue, 2024-04-23 at 16:59 +0800, Tender Wang wrote: > [ cut ] > > I have rebased master and fixed a plan diff case. We (me, Paul Jungwirth, and Yuki Fujii) reviewed this patch at PgConf.dev Patch Review Workshop. Here are our findings. Patch tries to allow for using materialization together w

Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids)

Hello, I am looking through some outstanding CommitFest entries; I wonder if this particular patch is already effectively fixed by 5278d0a2, which is both attributed to the original author as well as an extremely similar approach. Can this entry (https://commitfest.postgresql.org/48/4553/) be clo

Re: POC: GROUP BY optimization

Hi! On Thu, May 30, 2024 at 7:22 AM Andrei Lepikhov wrote: > On 5/29/24 19:53, Alexander Korotkov wrote: > > Thank you for your feedback. > > > > On Wed, May 29, 2024 at 11:08 AM Andrei Lepikhov > > wrote: > >> On 5/27/24 19:41, Alexander Korotkov wrote: > >>> Any thoughts? > >> About 0001: > >>

Re: Add memory context type to pg_backend_memory_contexts view

On Fri, 31 May 2024 at 07:21, David Christensen wrote: > Giving this a once-through, this seems straightforward and useful. I > have a slight preference for keeping "name" the first field in the > view and moving "type" to the second, but that's minor. Not having it first make sense, but I don't

Explicit specification of index ensuring uniqueness of foreign columns

I'd like to resurrect a subset of my proposal in [1], specifically that: The FOREIGN KEY constraint syntax gains a [ USING INDEX index_name ] clause optionally following the referenced column list. The index specified by this clause is used to support the foreign key constraint, and it mu

Cluster forcefully removal without user input

Hello, I have installed PostgreSQL 15 and PostgreSQL 14 side by side and want to upgrade from 14 to 15. For upgrading purposes, I am using {postgresql-15-setup check_upgrade}. However, in my case, the installed 14 version is not compatible with the latest 15.7. After the installation and cluster

Re: Use generation memory context for tuplestore.c

On Sat, 4 May 2024 at 03:51, Matthias van de Meent wrote: > > On Fri, 3 May 2024 at 15:55, David Rowley wrote: > > master @ 8f0a97dff > > Storage: Memory Maximum Storage: 16577kB > > > > patched: > > Storage: Memory Maximum Storage: 8577kB > > Those are some impressive numbers. This patch need