Re: Things I don't like about \du's "Attributes" column

On 11.07.2024 15:07, Rafia Sabih wrote: This looks much better than the current version. Thank you, for looking into this. Only thing is, I find the column name Valid until confusing. With that name I am in danger of taking it as the role's validity and not the passwords'. How about naming it

Re: Check lateral references within PHVs for memoize cache keys

On Fri, Jul 12, 2024 at 11:18 AM Andrei Lepikhov wrote: > I'm not sure about stability of output format of AVG aggregate across > different platforms. Maybe better to return the result of comparison > between the AVG() and expected value? I don't think this is a problem. AFAIK we use AVG() a lot

Re: pg_rewind WAL segments deletion pitfall

Hi, I'm reviewing patches in Commitfest 2024-07 from top to bottom: https://commitfest.postgresql.org/48/ This is the 1st patch: https://commitfest.postgresql.org/48/3874/ The latest patch can't be applied on master: https://www.postgresql.org/message-id/CAFh8B=nnjtm9ke4_1mhpwgz2pv9yoyf6hmnyh5xa

Re: Restart pg_usleep when interrupted

Hi, On Thu, Jul 11, 2024 at 10:15:41AM -0500, Sami Imseih wrote: > > > I did a few tests with the patch and did not see any "large" drifts like the > > ones observed above. > > Thanks for testing. > > > I think it could be "simplified" by making use of instr_time instead of > > timespec > > fo

Re: pg_rewind WAL segments deletion pitfall

Hi Sutou, Thank you for picking it up! On Fri, 12 Jul 2024 at 09:24, Sutou Kouhei wrote: Here are my review comments: > > @@ -217,6 +221,26 @@ findLastCheckpoint(const char *datadir, XLogRecPtr > forkptr, int tliIndex, > + charxlogfname[MAXFNAMELEN]; > + > +

Re: Things I don't like about \du's "Attributes" column

On Fri, 12 Jul 2024 at 09:06, Pavel Luzanov wrote: > > On 11.07.2024 15:07, Rafia Sabih wrote: > > This looks much better than the current version. > > Thank you, for looking into this. > > Only thing is, I find > the column name Valid until confusing. With that name I am in danger > of taking it

Re: Restart pg_usleep when interrupted

On 2024-Jul-11, Nathan Bossart wrote: > I'm imagining something like this: > > struct timespec delay; > TimestampTz end_time; > > end_time = TimestampTzPlusMilliseconds(GetCurrentTimestamp(), msec); > > do > { > longsecs; > int microsecs; > >

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi, > A comment about v3-0001. > > -* If true, use long segment filenames formed from lower 48 bits of > the > -* segment number, e.g. pg_xact/1234. Otherwise, use short > -* filenames formed from lower 16 bits of the segment number e.g. > -* pg_xact/1234.

Re: Missed opportunity for bsearch() in TransactionIdIsCurrentTransactionId()?

Nathan Bossart wrote: > On Wed, Jul 10, 2024 at 05:00:13PM +0200, Antonin Houska wrote: > > I don't quite understand why TransactionIdIsCurrentTransactionId() > > implements > > binary search in ParallelCurrentXids "from scratch" instead of using > > bsearch(). > > I believe there are a number

RE: Showing applied extended statistics in explain Part 2

Hi, Thanks for working the feature. As a user, I find it useful, and I'd like to use it in v18! Although I've just started start looking into it, I have a few questions. (1) Is it better to make the order of output consistent? For example, even though there are three clauses shown in the below

Re: MERGE/SPLIT partition commands should create new partitions in the parent's tablespace?

On Wed, Jul 10, 2024 at 9:36 PM Masahiko Sawada wrote: > > On Wed, Jul 10, 2024 at 5:14 PM Masahiko Sawada wrote: > > > > On Wed, Jul 10, 2024 at 4:14 PM Fujii Masao > > wrote: > > > > > > > > > > > > On 2024/07/10 12:13, Masahiko Sawada wrote: > > > > On Sat, Jul 6, 2024 at 4:06 PM Fujii Masao

Re: Flush pgstats file during checkpoints

Hi, On Fri, Jul 05, 2024 at 01:52:31PM +0900, Michael Paquier wrote: > On Sat, Jun 29, 2024 at 11:13:04PM +0200, Tomas Vondra wrote: > > I think those are two independent issues - knowing that the snapshot is > > from the last checkpoint, and knowing that it's correct (not corrupted). > > And yeah

Re: Removing unneeded self joins

Hi, Andrei! On Fri, Jul 12, 2024 at 6:05 AM Andrei Lepikhov wrote: > > On 7/11/24 14:43, jian he wrote: > > On Tue, Jul 9, 2024 at 2:06 PM Andrei Lepikhov wrote: > >> > >> On 7/2/24 07:25, jian he wrote: > >>> to make sure it's correct, I have added a lot of tests, > >>> Some of this may be cont

Partition-wise join with whole row vars

Hello. I was looking at enabling partition-wise join with whole row vars. My main motivation was to enable push down DML with partition-wise join in postgres_fdw. The work is based on the earlier patches of Ashutosh Bapat [1]. Partition-wise joins are disabled when whole row vars from relatio

Re: race condition when writing pg_control

On Sat, May 18, 2024 at 05:29:12PM +1200, Thomas Munro wrote: > On Fri, May 17, 2024 at 4:46 PM Thomas Munro wrote: > > The specific problem here is that LocalProcessControlFile() runs in > > every launched child for EXEC_BACKEND builds. Windows uses > > EXEC_BACKEND, and Windows' NTFS file syste

Re: Flush pgstats file during checkpoints

Hi, On Fri, Jul 12, 2024 at 03:42:21PM +0900, Michael Paquier wrote: > On Fri, Jul 05, 2024 at 01:52:31PM +0900, Michael Paquier wrote: > > On Sat, Jun 29, 2024 at 11:13:04PM +0200, Tomas Vondra wrote: > >> I think those are two independent issues - knowing that the snapshot is > >> from the last

Re: Amcheck verification of GiST and GIN

On 7/10/24 18:01, Tomas Vondra wrote: > ... > > That's all for now. I'll add this to the stress-testing tests of my > index build patches, and if that triggers more issues I'll report those. > As mentioned a couple days ago, I started using this patch to validate the patches adding parallel build

Re: MERGE/SPLIT partition commands should create new partitions in the parent's tablespace?

On Thu, Jul 11, 2024 at 8:14 PM Fujii Masao wrote: > > > > On 2024/07/10 22:35, Masahiko Sawada wrote: > > BTW the new regression tests don't check the table and index names. > > Isn't it better to show table and index names for better > > diagnosability? > > Sounds good to me. I've updated the pa

Re: Optimize mul_var() for var1ndigits >= 8

On Sun, 7 Jul 2024 at 20:46, Joel Jacobson wrote: > > This patch adds a mul_var_large() that is dispatched to from mul_var() > for var1ndigits >= 8, regardless of rscale. > > -- var1ndigits == var2ndigits == 16384 > SELECT COUNT(*) FROM n_max WHERE product = var1 * var2; > Time: 3191.145 ms (00:03

Re: Flush pgstats file during checkpoints

Hi, On Fri, Jul 12, 2024 at 12:10:26PM +, Bertrand Drouvot wrote: > Need to spend more time and thoughts on 0002+. I think there is a corner case, say: 1. shutdown checkpoint at LSN1 2. startup->reads the stat file (contains LSN1)->all good->read stat file and remove it 3. crash (no checkpoi

Re: Pluggable cumulative statistics

> On Thu, Jul 11, 2024 at 04:42:22PM GMT, Michael Paquier wrote: > > So we are down to the remaining parts of the patch, and this is going > to need a consensus about a few things because this impacts the > developer experience when implementing one's own custom stats: > - Are folks OK with the poi

Re: Removing unneeded self joins

On Fri, Jul 12, 2024 at 1:30 PM Alexander Korotkov wrote: > On Fri, Jul 12, 2024 at 6:05 AM Andrei Lepikhov wrote: > > On 7/11/24 14:43, jian he wrote: > > > On Tue, Jul 9, 2024 at 2:06 PM Andrei Lepikhov wrote: > > >> > > >> On 7/2/24 07:25, jian he wrote: > > >>> to make sure it's correct, I h

Re: CREATE OR REPLACE MATERIALIZED VIEW

That is expected because AccessExclusiveLock is acquired on the existing matview. This is also the case for CREATE OR REPLACE VIEW. Right, had this case many times. My initial idea, while writing the patch, was that one could replace the matview without populating it and then run the conc

Re: Send duration output to separate log files

On Thu, Jul 11, 2024 at 6:47 AM Alastair Turner wrote: > The other category of logging which would benefit from a separate file is > audit. It also can create massive volumes of log content. Splitting audit > information off into a separate file for use by a separate team or function > is also a

Can't find bugs to work on

Hey there, I am new to contributing in PostgreSQL and I've just installed the source code and built the system successfully from the source code and trying to find a bug to start working on but I face some problems with the pgsql-bugs mailing list as I can't filter them by which are solved and whi

Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

On Mon, Jun 24, 2024 at 3:10 PM Jeff Davis wrote: > A special search_path variable "$extension_schema" would be a better > solution to this problem. We need something like that anyway, in case > the extension is relocated, so that we don't have to dig through the > catalog and update all the setti

Re: Can't find bugs to work on

On Fri, Jul 12, 2024 at 7:59 AM Mohab Yaser wrote: > > So if anyone faced the same problem please let me know. I agree that it's rough at the moment. I don't pretend to have any solutions, but you might check the Bug Fixes section of the current Commitfest, to help review: https://commitfest

Re: Can't find bugs to work on

Jacob Champion writes: > On Fri, Jul 12, 2024 at 7:59 AM Mohab Yaser > wrote: >> So if anyone faced the same problem please let me know. > I agree that it's rough at the moment. I don't pretend to have any > solutions, but you might check the Bug Fixes section of the current > Commitfest, to hel

Re: Missed opportunity for bsearch() in TransactionIdIsCurrentTransactionId()?

On Fri, Jul 12, 2024 at 12:01:11PM +0200, Antonin Houska wrote: > Nathan Bossart wrote: >> My concern with switching them to bsearch() would be the performance impact >> of using a function pointer for the comparisons. Perhaps we could add a >> couple of inlined binary search implementations for

Re: Can't find bugs to work on

On Fri, Jul 12, 2024 at 8:44 AM Tom Lane wrote: > > As this example shows, it's now standard for PG commit log messages > to include a link to the relevant email thread, so all you need > is the message-ID of the first message in the thread to search > the commit log with. > > Cross-posting my co

Re: Amcheck verification of GiST and GIN

OK, one mere comment - it seems the 0001 patch has incorrect indentation in bt_index_check_callback, triggering this: -- verify_nbtree.c: In function ‘bt_index_check_callback’: verify_nbtree.c:331:25: warning: this ‘if’ clause doe

Re: Allow non-superuser to cancel superuser tasks.

On Fri, Jul 12, 2024 at 02:21:09PM +0900, Michael Paquier wrote: > On Thu, Jul 11, 2024 at 08:50:57PM -0500, Nathan Bossart wrote: >> I'm not following how this is guaranteed to trigger an autovacuum quickly. >> Shouldn't we set autovacuum_vacuum_insert_threshold to 1 so that it is >> eligible for

Re: Remove dependence on integer wrapping

On Sat, Jul 06, 2024 at 07:04:38PM -0400, Joseph Koshakow wrote: > I've added another patch, 0004, to resolve the jsonb wrap-arounds. > > The other patches, 0001, 0002, and 0003 are unchanged but have their > version number incremented. IIUC some of these changes are bug fixes. Can we split out

Re: Restart pg_usleep when interrupted

> > I'm imagining something like this: > >struct timespec delay; >TimestampTz end_time; > >end_time = TimestampTzPlusMilliseconds(GetCurrentTimestamp(), msec); > >do >{ >longsecs; >int microsecs; > >TimestampDifference(GetCurrentTimes

Re: gcc 13 warnings

Hi, On 2024-07-05 14:19:12 +0300, Aleksander Alekseev wrote: > There is still a warning previously reported by Melanie: > > ``` > [1391/1944] Compiling C object src/pl/plpgsql/src/plpgsql.so.p/pl_exec.c.o > In file included from ../src/include/access/htup_details.h:22, > from ../s

Re: Amcheck verification of GiST and GIN

OK, one more issue report. I originally thought it's a bug in my patch adding parallel builds for GIN indexes, but it turns out it happens even with serial builds on master ... If I build any GIN index, and then do gin_index_parent_check() on it, I get this error: create index jsonb_hash on messa

Re: Restart pg_usleep when interrupted

On Fri, Jul 12, 2024 at 12:14:56PM -0500, Sami Imseih wrote: > 1/ TimestampDifference has a dependency on gettimeofday, > while my proposal utilizes clock_gettime. There are old discussions > that did not reach a conclusion comparing both mechanisms. > My main conclusion from these hacker discuss

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

> On 11 Jul 2024, at 23:16, Peter Eisentraut wrote: > It would be worth checking the discussion at > > about strtok()/strtok_r() issues. First, for list parsing, it sometimes > gives the wrong sem

Re: Restart pg_usleep when interrupted

> What does your testing show when you don't have > the extra check, i.e., > > struct timespec delay; > struct timespec remain; > > delay.tv_sec = microsec / 100L; > delay.tv_nsec = (microsec % 100L) * 1000; > > while (nanosleep(&delay, &remain) == -1 && er

Re: Internal error codes triggered by tests

> On 10 Jul 2024, at 06:42, Michael Paquier wrote: >> SELECT format('BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; >> SET TRANSACTION SNAPSHOT ''%s''', repeat('-', 1000)) >> \gexec >> ERROR: XX000: could not open file "pg_snapshots/-...---" for reading: >> File name too long >> LOCATION:

Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

> On 11 Jul 2024, at 23:22, Peter Eisentraut wrote: > The 0001 patch removes the functions pgtls_init_library() and pgtls_init() > but keeps the declarations in libpq-int.h. This should be fixed. Ah, nice catch. Done in the attached rebase. -- Daniel Gustafsson v14-0002-Remove-pg_strong_ra

Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows

Hi, I'm reviewing patches in Commitfest 2024-07 from top to bottom: https://commitfest.postgresql.org/48/ This is the 2st patch: https://commitfest.postgresql.org/48/4573/ FYI: https://commitfest.postgresql.org/48/4681/ is my patch. In "Re: pg_ctl start may return 0 even if the postmaster ha

Re: MAINTAIN privilege -- what do we need to un-revert it?

On Thu, 2024-07-11 at 05:52 -0700, Noah Misch wrote: > > I could try to refactor it into two statements and execute them > > separately, or I could try to rewrite the statement to use a fully- > > qualified destination table before execution. Thoughts? > > Those sound fine.  Also fine: just adding

REINDEX not updating partition progress

Hi, While working on CIC for partitioned tables [1], I noticed that REINDEX for partitioned tables is not tracking keeping progress of partitioned tables, so I'm creating a separate thread for this fix as suggested. The way REINDEX for partitioned tables works now ReindexMultipleInternal tre

Re: Parent/child context relation in pg_get_backend_memory_contexts()

Hi David, Thanks for v8 patch. Please see attached v9. David Rowley , 11 Tem 2024 Per, 04:16 tarihinde şunu yazdı: > I did a bit more work in the attached. I changed "level" to be > 1-based and because it's the column before "path" I find it much more > intuitive (assuming no prior knowledge) t

Re: CREATE INDEX CONCURRENTLY on partitioned index

On 12.07.2024 01:01, Michael Paquier wrote: Please let's move this point to its own thread and deal with it with an independent patch. Hiding that in a thread that's already quite long is not a good idea. This needs proper review, and a separate thread with a good subject to describe the probl

Re: Parent/child context relation in pg_get_backend_memory_contexts()

Hi Robert, Robert Haas , 11 Tem 2024 Per, 23:09 tarihinde şunu yazdı: > > Ideally, no CTE would be needed here, but unfortunately, there's no > > way to know the CacheMemoryContext's ID beforehand. We could make the > > ID more stable if we did a breadth-first traversal of the context. > > i.e.,

Re: MAINTAIN privilege -- what do we need to un-revert it?

On Fri, Jul 12, 2024 at 02:50:52PM -0700, Jeff Davis wrote: > On Thu, 2024-07-11 at 05:52 -0700, Noah Misch wrote: > > > I could try to refactor it into two statements and execute them > > > separately, or I could try to rewrite the statement to use a fully- > > > qualified destination table before

Re: MAINTAIN privilege -- what do we need to un-revert it?

On Fri, 2024-07-12 at 16:11 -0700, Noah Misch wrote: > Since refresh->relation is a RangeVar, this departs from the standard > against > repeated name lookups, from CVE-2014-0062 (commit 5f17304). Interesting, thank you. I did a rough refactor and attached v3. Aside from cleanup issues, is this w

Re: Why is citext/regress failing on hamerkop?

On Fri, May 17, 2024 at 12:00 AM Alexander Lakhin wrote: > I've tested v2 and can confirm that it works as v1, `vcregress check` > passes with no failures on REL_16_STABLE, `meson test` with the basic > configuration too. Pushed, including back-branches. This is all not very nice code and I hope