Re: NOTIFY and pg_notify performance when deduplicating notifications

On Wed, Oct 10, 2018 at 5:42 PM Catalin Iacob wrote: > One way could be to take inspiration from > src/test/isolation/specs/async-notify.spec and check that > pg_notification_queue_usage() does grow when repeating the same > payload with collapse_mode='never' (while for always i

Re: NOTIFY and pg_notify performance when deduplicating notifications

On Tue, Oct 9, 2018 at 2:17 PM wrote: > I just caught an error in my patch, it's fixed in the attachment. The 'never' > and 'maybe' collapse modes were mixed up in one location. Here's a partial review of this version, did not read the doc part very carefully. First of all, I agree that this

Re: NOTIFY and pg_notify performance when deduplicating notifications

On Tue, Oct 2, 2018 at 7:20 PM wrote: > I have a feature built around LISTEN / NOTIFY that works perfectly well, > except for the enormous performance impact to transactions that emit large > numbers of notifications. Indeed, I have the same and am very interested in this. > I hope this patch

Re: Is a modern build system acceptable for older platforms

On Wed, May 2, 2018 at 5:44 PM, Robert Haas wrote: > I don't think that unsubstantiated hyperbole is the right way to > approach the task of convincing the community to adopt the approach > you prefer. I don't see that any compelling evidence has been > presented that a

Re: Postgres, fsync, and OSs (specifically linux)

On Sat, Apr 28, 2018 at 12:28 AM, Andres Freund wrote: > Before linux v4.13 errors in kernel writeback would be reported at most > once, without a guarantee that that'd happen (IIUC memory pressure could > lead to the relevant information being evicted) - but it was pretty >

Is a modern build system acceptable for older platforms

There have been several discussions of replacing PG's autoconf + src/tools/msvc system. The last example is happening now at the bottom of the Setting rpath on llvmjit.so thread. I see potentially big advantages to moving but also to PG's conservative approach that keeps it running on edge and

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On Thu, Mar 29, 2018 at 2:07 PM, Thomas Munro wrote: > I found your discussion with kernel hacker Jeff Layton at > https://lwn.net/Articles/718734/ in which he said: "The stackoverflow > writeup seems to want a scheme where pages stay dirty after a > writeback

Re: JIT compiling with LLVM v12.2

On Wed, Mar 21, 2018 at 4:07 AM, Andres Freund wrote: > Indeed. I've pushed a rebased version now, that basically just fixes the > issue Thomas observed. Testing 2d6f2fba from your repository configured --with-llvm I noticed some weird things in the configure output. Without

Re: JIT compiling with LLVM v11

On Thu, Mar 15, 2018 at 6:19 PM, Andres Freund wrote: > What we were talking about in this subthread was about a depency on > clang, not LLVM. And that's just needed at buildtime, to generate the > bitcode files (including synchronizing types / function signatures). I was

Re: JIT compiling with LLVM v11

On Thu, Mar 15, 2018 at 1:20 AM, Andres Freund wrote: > I don't really live in the RHEL world, but I wonder if > https://developers.redhat.com/blog/2017/10/04/red-hat-adds-go-clangllvm-rust-compiler-toolsets-updates-gcc/ > is relevant? Indeed. It might be a bit awkward for

Re: prokind column (was Re: [HACKERS] SQL procedures)

On Tue, Feb 27, 2018 at 4:03 AM, Michael Paquier wrote: > I would just recommend users to use a version of psql matching > the one of the server instead of putting an extra load of maintenance > into psql for years to come Breaking tab completion in new psql against old

Re: Doc tweak for huge_pages?

On Tue, Jan 23, 2018 at 7:13 PM, Catalin Iacob <iacobcata...@gmail.com> wrote: > By the way, Fedora 27 does disable THP by default, they deviate from > upstream in this regard: > When I have some time I'll try to do some digging into history of the > Fedora kernel package to s

Re: Doc tweak for huge_pages?

On Mon, Jan 22, 2018 at 7:23 AM, Justin Pryzby wrote: > Consider this shorter, less-severe sounding alternative: > "... (but note that this feature can degrade performance of some > PostgreSQL workloads)." I think the patch looks good now. As Justin mentions, as far as I

Re: Doc tweak for huge_pages?

On Fri, Dec 1, 2017 at 10:09 PM, Thomas Munro wrote: >> On 11/30/17 23:35, Thomas Munro wrote: >>> Hmm. Yeah, it does, but apparently it's not so transparent. So if we >>> mention that we'd better indicate in the same paragraph that you >>> probably don't actually