Re: Cleaning up threading code

On Mon, Jul 3, 2023 at 8:43 PM Heikki Linnakangas wrote: > On 10/06/2023 05:23, Thomas Munro wrote: > > 2. I don't like the way we have to deal with POSIX vs Windows at > > every site where we use threads, and each place has a different style > > of wrappers. I considered a few different approac

SupportRequestRows support function for generate_series_timestamptz

When looking at [1], I noticed that we don't have a prosupport function for the timestamp version of generate_series. We have this for the integer versions of generate_series(), per: postgres=# explain analyze select * from generate_series(1, 256, 2);

Re: In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)

Thanks to everyone! I will file a bug. Anyways, I just built a tool to work-around it all. It allows to run psql from processes which don't handle SIGINT in a proper shell-like manner (like yarn for instance): https://github.com/dimikot/run-in-separate-pgrp Basically, without this, an attempt to

Re: allow changing autovacuum_max_workers without restarting

> IIRC using GUC hooks to handle dependencies like this is generally frowned > upon because it tends to not work very well [0]. We could probably get it > to work for this particular case, but IMHO we should still try to avoid > this approach. Thanks for pointing this out. I agree, this could lea

Re: In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)

Thomas Munro writes: > On Sun, Apr 14, 2024 at 11:49 AM Tom Lane wrote: >> OK, I tried dtruss'ing psql on macOS. What I see is that with >> Apple's libedit, the response to SIGINT includes this: >> kill(0, 2) = 0 0 > https://github.com/NetBSD/src/blob/1de18f216411bce77e26740327b07

Re: In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)

On Sun, Apr 14, 2024 at 11:49 AM Tom Lane wrote: > Dmitry Koterov writes: > > I wish it was zsh... I tested it with zsh, but with bash (and with > > low-level kill syscall), I observed the same effect unfortunately. > > > So it's still a puzzle. > > > 1. Even more, when I send a kill() low-level

Re: In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)

> OK, I tried dtruss'ing psql on macOS. What I see is that with > Apple's libedit, the response to SIGINT includes this: > kill(0, 2) = 0 0 OK, so it's libedit who does this. I should've tried drtuss instead of not quite working lldb. I'll try to dig further. Thank you, Tom! > H

Re: In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)

Dmitry Koterov writes: > I wish it was zsh... I tested it with zsh, but with bash (and with > low-level kill syscall), I observed the same effect unfortunately. > So it's still a puzzle. > 1. Even more, when I send a kill() low-level syscall using e.g. Perl - perl > -e 'kill("INT", 16107)' - it

Re: In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)

On Sun, Apr 14, 2024 at 11:18 AM Dmitry Koterov wrote: > Can it be e.g. readline? Or something related to tty or session settings > which psql could modify (I did not find any in the source code though). I was wondering about that. Are you using libedit or libreadline? What happens if you build

Re: In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)

On Saturday, April 13, 2024, Dmitry Koterov wrote: > > > % psql --version > psql (PostgreSQL) 16.0 > How did you install this and can you install other, supported, versions? David J.

Why should I use fileno(stderr) instead of STDERR_FILENO

Dear pgsql hackers, I found a mixture of fileno(stderr) and STDERR_FILENO in PostgreSQL source code which in most cases mean the same. But I have found recently that Microsoft's fileno() _fileno() can return -2 sometimes. After some experiments I found that applications running as windows service

Re: Parallel CREATE INDEX for BRIN indexes

On 4/13/24 11:19, Tomas Vondra wrote: > On 4/13/24 10:36, Andres Freund wrote: >> Hi, >> >> While preparing a differential code coverage report between 16 and HEAD, one >> thing that stands out is the parallel brin build code. Neither on >> coverage.postgresql.org nor locally is that code reached d

Re: allow changing autovacuum_max_workers without restarting

On Fri, Apr 12, 2024 at 10:17:44PM +, Imseih (AWS), Sami wrote: >>> Hm. Maybe the autovacuum launcher could do that. > > Would it be better to use a GUC check_hook that compares the > new value with the max allowed values and emits a WARNING ? > > autovacuum_max_workers already has a check_a

Re: UUID v7

I think that for the sake of such an epoch-making thing as UUIDv7 it would be worth slightly unfreezing this feature freeze. Best regards,  Sergey prokhorenkosergeyprokhore...@yahoo.com.au On Saturday, 13 April 2024 at 09:58:29 am GMT+3, Andrey M. Borodin wrote: > On 12 Mar 2024,

Re: Why is parula failing?

On 4/13/24 15:02, Robins Tharakan wrote: > On Wed, 10 Apr 2024 at 10:24, David Rowley wrote: >> >> Master failed today for the first time since the compiler upgrade. >> Again reltuples == 48. > > Here's what I can add over the past few days: > - Almost all failures are either reltuples=48 or SIGA

Re: Why is parula failing?

On 4/9/24 05:48, David Rowley wrote: > On Mon, 8 Apr 2024 at 23:56, Robins Tharakan wrote: >> #3 0x0083ed84 in WaitLatch (latch=, >> wakeEvents=wakeEvents@entry=41, timeout=60, >> wait_event_info=wait_event_info@entry=150994946) at latch.c:538 >> #4 0x00907404 in pg_slee

Identify huge pages accessibility using madvise

Hi, I would like to propose a small patch to address an annoying issue with the way how PostgreSQL does fallback in case if "huge_pages = try" is set. Here is how the problem looks like: * PostgreSQL is starting on a machine with some huge pages available * It tries to identify that fact and doe

Re: In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)

Dmitry Koterov writes: > I almost lost my mind today trying to figure out why sending a SIGINT > precisely to a psql interactive process delivers this SIGINT not only to > that psql, but also to its parents. Let me guess ... you're using zsh not bash? I do not use zsh myself, but what I read in

Re: Why is parula failing?

Robins Tharakan writes: > HEAD is stuck again on pg_sleep(), no CPU for the past hour or so. > Stack trace seems to be similar to last time. > #3 0x008437c4 in WaitLatch (latch=, > wakeEvents=wakeEvents@entry=41, timeout=60, > wait_event_info=wait_event_info@entry=150994946) at latch

Re: sql/json remaining issue

On Fri, Apr 12, 2024 at 5:44 PM Amit Langote wrote: > > > elog(ERROR, "unrecognized json wrapper %d", wrapper); > > should be > > elog(ERROR, "unrecognized json wrapper %d", (int) wrapper); > > Fixed in 0003. > the fix seems not in 0003? other than that, everything looks fine. SELECT * FROM JSO

Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)

Em sáb., 13 de abr. de 2024 às 04:16, Heikki Linnakangas escreveu: > On 11/04/2024 16:37, Ranier Vilela wrote: > > Em qui., 11 de abr. de 2024 às 09:54, Heikki Linnakangas > > mailto:hlinn...@iki.fi>> escreveu: > > > > On 11/04/2024 15:03, Ranier Vilela wrote: > > > Em qua., 10 de abr. d

Re: Why is parula failing?

On Mon, 8 Apr 2024 at 21:25, Robins Tharakan wrote: > > > I'll keep an eye on this instance more often for the next few days. > (Let me know if I could capture more if a run gets stuck again) HEAD is stuck again on pg_sleep(), no CPU for the past hour or so. Stack trace seems to be similar to la

Re: altering a column's collation leaves an invalid foreign key

On Fri, Apr 12, 2024 at 5:06 PM jian he wrote: > > On Tue, Mar 26, 2024 at 1:00 PM jian he wrote: > > > > On Mon, Mar 25, 2024 at 2:47 PM Paul Jungwirth > > wrote: > > > > > > On 3/23/24 10:04, Paul Jungwirth wrote: > > > > Perhaps if the previous collation was nondeterministic we should force

Re: Why is parula failing?

On Wed, 10 Apr 2024 at 10:24, David Rowley wrote: > > Master failed today for the first time since the compiler upgrade. > Again reltuples == 48. Here's what I can add over the past few days: - Almost all failures are either reltuples=48 or SIGABRTs - Almost all SIGABRTs are DDLs - CREATE INDEX /

Re: Add missing ConditionVariableCancelSleep() in slot.c

On 2024-Apr-13, Bharath Rupireddy wrote: > It looks like there's missing ConditionVariableCancelSleep() in > InvalidatePossiblyObsoleteSlot() after waiting for the replication > slot to be released by another process. Although prepare to sleep > cancels the sleep if the previous one wasn't cancele

Re: post-freeze damage control

On 4/13/24 01:23, David Steele wrote: > On 4/12/24 22:27, Tomas Vondra wrote: >> >> >> On 4/12/24 08:42, David Steele wrote: >>> On 4/11/24 20:26, Tomas Vondra wrote: On 4/11/24 03:52, David Steele wrote: > On 4/11/24 10:23, Tom Kincaid wrote: >> >> The extensive Beta process we

Re: post-freeze damage control

On 4/13/24 01:03, David Steele wrote: > On 4/12/24 22:12, Tomas Vondra wrote: >> On 4/11/24 23:48, David Steele wrote: >>> On 4/11/24 20:26, Tomas Vondra wrote: >>> FWIW that discussion also mentions stuff that I think the feature should not do. In particular, I don't think the am

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi, Dmitry! On Fri, Apr 12, 2024 at 10:59 PM Dmitry Koval wrote: > > Thanks, Alexander! > > > Still now we're able to create a partition in the pg_temp schema > > explicitly. > > Attached patches with fix. Please, find a my version of this fix attached. I think we need to check relpersistence i

Re: Table AM Interface Enhancements

Hi, Melanie! On Fri, Apr 12, 2024 at 8:48 PM Melanie Plageman wrote: > > On Thu, Apr 11, 2024 at 6:04 PM Alexander Korotkov > wrote: > > > > On Fri, Apr 12, 2024 at 12:04 AM Andres Freund wrote: > > > On 2024-04-11 20:46:02 +0300, Alexander Korotkov wrote: > > > > I hope this work is targeting

Re: Parallel CREATE INDEX for BRIN indexes

On 4/13/24 10:36, Andres Freund wrote: > Hi, > > While preparing a differential code coverage report between 16 and HEAD, one > thing that stands out is the parallel brin build code. Neither on > coverage.postgresql.org nor locally is that code reached during our tests. > Thanks for pointing this

Remove unnecessary segment number calculation after wal_removed invalidation of replication slots

Hi, It looks like there's an unnecessary segment number calculation after InvalidateObsoleteReplicationSlots in CreateCheckPoint and CreateRestartPoint. Since none of RedoRecPtr, _logSegNo and wal_segment_size are changed by the slot invalidation code [1], the recalculation of _logSegNo with XLByt

Add missing ConditionVariableCancelSleep() in slot.c

Hi, It looks like there's missing ConditionVariableCancelSleep() in InvalidatePossiblyObsoleteSlot() after waiting for the replication slot to be released by another process. Although prepare to sleep cancels the sleep if the previous one wasn't canceled, the calling process still remains in the C

Re: Parallel CREATE INDEX for BRIN indexes

Hi, While preparing a differential code coverage report between 16 and HEAD, one thing that stands out is the parallel brin build code. Neither on coverage.postgresql.org nor locally is that code reached during our tests. https://coverage.postgresql.org/src/backend/access/brin/brin.c.gcov.html#23

Re: some LLVM function checks missing in meson

On 11/04/2024 18:26, Peter Eisentraut wrote: I have been checking the pg_config.h generated by configure and meson to see if there is anything materially different. I found that HAVE_DECL_LLVMCREATEGDBREGISTRATIONLISTENER and HAVE_DECL_LLVMCREATEPERFJITEVENTLISTENER are missing on the meson si

In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)

Hi. Preamble: this happens in MacOS only (in built-in Terminal and in iTerm2 at least). In Linux, everything is as expected. I almost lost my mind today trying to figure out why sending a SIGINT precisely to a psql interactive process delivers this SIGINT not only to that psql, but also to its pa

Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)

On 11/04/2024 16:37, Ranier Vilela wrote: Em qui., 11 de abr. de 2024 às 09:54, Heikki Linnakangas mailto:hlinn...@iki.fi>> escreveu: On 11/04/2024 15:03, Ranier Vilela wrote: > Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas > mailto:hlinn...@iki.fi>