Re: Asynchronous Append on postgres_fdw nodes.

On Fri, Mar 19, 2021 at 9:57 PM Justin Pryzby wrote: > is_async_capable_path() should probably have a "break" for case T_ForeignPath. Good catch! Will fix. > little typos: > aready > sigle > givne > a event Lots of typos. :-( Will fix. Thank you for the review! Best regards, Etsuro Fujita

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Mar 19, 2021 at 08:10:54PM -0400, Bruce Momjian wrote: > On Sat, Mar 20, 2021 at 01:03:16AM +0100, Hannu Krosing wrote: > > It would be really convenient if user-visible serialisations of the query id > > had something that identifies the computation method. > > > > maybe prefix 'N' for

Re: pglz compression performance, take two

On Fri, Mar 19, 2021 at 01:29:14PM -0700, Mark Dilger wrote: > Robert Haas just committed Dilip Kumar's LZ4 compression, > bbe0a81db69bd10bd166907c3701492a29aca294. > > Is this pglz compression patch still relevant? How does the LZ4 compression > compare on your hardware? I think it's still

Re: Replication slot stats misgivings

On Sat, Mar 20, 2021 at 9:25 AM Amit Kapila wrote: > > On Sat, Mar 20, 2021 at 12:22 AM Andres Freund wrote: > > > > And then more generally about the feature: > > - If a slot was used to stream out a large amount of changes (say an > > initial data load), but then replication is interrupted

Re: [HACKERS] logical decoding of two-phase transactions

On Sat, Mar 20, 2021 at 1:35 AM Amit Kapila wrote: > On Fri, Mar 19, 2021 at 5:03 AM Ajin Cherian wrote: > > > > Missed the patch - 0001, resending. > > > > I have made miscellaneous changes in the patch which includes > improving comments, error messages, and miscellaneous coding >

Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?

On Sat, Mar 6, 2021 at 12:10 PM Daniel Gustafsson wrote: > > On 3 Mar 2021, at 23:19, Thomas Munro wrote: > > That's why I release and reacquire that LWLock. But does that break some > > logic? > > One clear change to current behavior is naturally that a concurrent > TablespaceCreateDbspace can

Re: make the stats collector shutdown without writing the statsfiles if the immediate shutdown is requested.

When only the stats collector exits by SIGQUIT, with the patch FreeWaitEventSet() is also skipped. Is this ok? Thanks, I fixed it. I'm still not sure if FreeWaitEventSet() is actually necessary in that exit case. Could you tell me why you thought FreeWaitEventSet() is necessary in the case?

Re: pg_upgrade failing for 200+ million Large Objects

On 3/8/21 11:58 AM, Tom Lane wrote: The answer up to now has been "raise max_locks_per_transaction enough so you don't see the failure". Having now consumed a little more caffeine, I remember that that works in pg_upgrade scenarios too, since the user can fiddle with the target cluster's

Re: a verbose option for autovacuum

On Fri, Mar 19, 2021 at 3:14 PM Michael Paquier wrote: > > On Thu, Mar 18, 2021 at 11:30:46PM +0900, Masahiko Sawada wrote: > > Sorry, I attached the wrong version patch. So attached the right one. > > Thanks. I have been hacking aon that, and I think that we could do > more in terms of

Re: Replication slot stats misgivings

On Sat, Mar 20, 2021 at 12:22 AM Andres Freund wrote: > > And then more generally about the feature: > - If a slot was used to stream out a large amount of changes (say an > initial data load), but then replication is interrupted before the > transaction is committed/aborted, stream_bytes

Re: pspg pager is finished

On Sat, Mar 20, 2021 at 04:34:30AM +0100, Pavel Stehule wrote: > Hi > > I finished work on pspg. > > https://github.com/okbob/pspg > > Now it has special features like rows or block selection by mouse, and > export related data to file or to clipboard in csv or tsv or insert > formats. Some

pspg pager is finished

Hi I finished work on pspg. https://github.com/okbob/pspg Now it has special features like rows or block selection by mouse, and export related data to file or to clipboard in csv or tsv or insert formats. Some basic features like sorting data per selected columns are possible too. I hope this

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 6:38 PM Alvaro Herrera wrote: > I suggest to add comments to this effect, > perhaps as the attached (feel free to reword, I think mine is awkward.) It's not bad, although "the decompressed version of the full datum" might be a little better. I'd probably say instead:

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 8:25 PM Tom Lane wrote: > Extrapolating from the way we've dealt with similar issues > in the past, I think the structure of pg_dump's output ought to be: > > 1. SET default_toast_compression = 'source system's value' > in among the existing passel of SETs at the top.

recovery_init_sync_method=wal

Hello hackers, I'm starting a new thread and CF entry for the material for r15 from the earlier thread[1] that introduced the recovery_init_sync_method GUC for r14. I wrote a summary of this topic as I see it, while it's still fresh on my mind from working on commit 61752afb, starting from what

Re: Maintaining a list of pgindent commits for "git blame" to ignore

On Thu, Mar 18, 2021 at 5:07 PM Tom Lane wrote: > Doubt that it matters. The workflow would have to be "commit and push > the mechanical updates, then edit the tracking file, commit and push > that". You don't have the commit hash nailed down till you've pushed. Okay. I have made a personal

Re: [HACKERS] logical decoding of two-phase transactions

On Sat, Mar 20, 2021 at 7:07 AM Ajin Cherian wrote: > > On Sat, Mar 20, 2021 at 1:35 AM Amit Kapila wrote: >> >> On Fri, Mar 19, 2021 at 5:03 AM Ajin Cherian wrote: >> > >> > Missed the patch - 0001, resending. >> > >> >> >> @@ -538,10 +550,21 @@ CreateDecodingContext(XLogRecPtr start_lsn, >>

Re: Logical Replication vs. 2PC

On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner wrote: > > On 18.03.21 10:45, Amit Kapila wrote: > > While reviewing/testing subscriber-side work for $SUBJECT [1], I > > noticed a problem that seems to need a broader discussion, so started > > this thread. We can get prepare for the same GID more

RE: invalid data in file backup_label problem on windows

David Steele wrote: > It's not clear to me what text editors have to do with this? Are you > editing the file manually? When I execute SELECT * FROM pg_stop_backup(false, true) in psql. The results will be shown like: lsn| labelfile

Re: [HACKERS] Custom compression methods

On 3/19/21 8:25 PM, Tom Lane wrote: > Alvaro Herrera writes: >> On 2021-Mar-19, Robert Haas wrote: >>> Well, I really do hope that some day in the bright future, pglz will >>> no longer be the thing we're shipping as the postgresql.conf default. >>> So we'd just be postponing the noise until

Re: [HACKERS] logical decoding of two-phase transactions

On Sat, Mar 20, 2021 at 1:35 AM Amit Kapila wrote: > On Fri, Mar 19, 2021 at 5:03 AM Ajin Cherian wrote: > > > > Missed the patch - 0001, resending. > > > > > @@ -538,10 +550,21 @@ CreateDecodingContext(XLogRecPtr start_lsn, > .. > + /* Set two_phase_at LSN only if it hasn't already been set.

Re: [PATCH] Identify LWLocks in tracepoints

On Sat, 20 Mar 2021, 04:21 Peter Eisentraut, < peter.eisentr...@enterprisedb.com> wrote: > > On 18.03.21 07:34, Craig Ringer wrote: > > The main reason I didn't want to add more tracepoints than were strictly > > necessary is that Pg doesn't enable the systemtap semaphores feature, so > > right

Re: shared memory stats: high level design decisions: consistency, dropping

On Sat, Mar 20, 2021 at 1:21 AM Andres Freund wrote: > > Hi, > > On 2021-03-20 01:16:31 +0100, Hannu Krosing wrote: > > > But now we could instead schedule stats to be removed at commit > > time. That's not trivial of course, as we'd need to handle cases where > > the commit fails after the

Re: fdatasync performance problem with large number of DB files

On 3/19/21 7:16 PM, Thomas Munro wrote: Thanks Justin and David. Replies to two emails inline: Fair point. Here's what I went with: When set to fsync, which is the default, PostgreSQL will recursively open and synchronize all files in the data directory before

Re: [HACKERS] Custom compression methods

Alvaro Herrera writes: > On 2021-Mar-19, Robert Haas wrote: >> Well, I really do hope that some day in the bright future, pglz will >> no longer be the thing we're shipping as the postgresql.conf default. >> So we'd just be postponing the noise until then. I think we need a >> better idea than

Re: shared memory stats: high level design decisions: consistency, dropping

Hi, On 2021-03-20 01:16:31 +0100, Hannu Krosing wrote: > > But now we could instead schedule stats to be removed at commit > time. That's not trivial of course, as we'd need to handle cases where > the commit fails after the commit record, but before processing the > dropped stats. > > We likely

Re: [HACKERS] Custom compression methods

On 3/19/21 8:00 PM, Andres Freund wrote: On 2021-03-19 15:44:34 -0400, Robert Haas wrote: I committed the core patch (0003) with a bit more editing. Let's see what the buildfarm thinks. Congrats Dilip, Robert, All. The slow toast compression has been a significant issue for a long time.

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Sat, Mar 20, 2021 at 01:03:16AM +0100, Hannu Krosing wrote: > It would be really convenient if user-visible serialisations of the query id > had something that identifies the computation method. > > maybe prefix 'N' for internal, 'S' for pg_stat_statements etc. > > This would immediately show

Re: [HACKERS] Custom compression methods

On 2021-Mar-19, Robert Haas wrote: > On Fri, Mar 19, 2021 at 6:22 PM Alvaro Herrera > wrote: > > (At least, for binary upgrade surely you must make sure to apply the > > correct setting regardless of defaults on either system). > > It's not critical from a system integrity point of view; the

shared memory stats: high level design decisions: consistency, dropping

Hi, I am working on Kyotaro Horiguchi's shared memory stats patch [1] with the goal of getting it into a shape that I'd be happy to commit. That thread is quite long and most are probably skipping over new messages in it. There are two high-level design decisions / questions that I think

Re: fdatasync performance problem with large number of DB files

Thanks Justin and David. Replies to two emails inline: On Sat, Mar 20, 2021 at 12:01 AM Justin Pryzby wrote: > On Fri, Mar 19, 2021 at 06:28:46PM +1300, Thomas Munro wrote: > > +++ b/doc/src/sgml/config.sgml > > > +PostgreSQL will recursively open and > > fsync > > +all files

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 6:22 PM Alvaro Herrera wrote: > Do you mean the column storage strategy, attstorage? I don't think > that's really related, because the difference there is not a GUC setting > but a compiled-in default for the type. In the case of compression, I'm > not sure it makes

Re: [HACKERS] Custom compression methods

On 2021-Mar-19, Robert Haas wrote: > Here's one from me that tries to make the handling of the LZ4 stuff > more like what we already do for zlib, but I'm not sure if it's > correct, or if it's what everyone wants. This one seems to behave as expected (Debian 10, with and without liblz4-dev). --

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 10:19:49PM +0100, Tomas Vondra wrote: > On 3/19/21 9:40 PM, Andres Freund wrote: > > On 2021-03-19 17:35:58 -0300, Alvaro Herrera wrote: > >> I find this behavior confusing; I'd rather have configure error out if > >> it can't find the package support I requested, than

Re: [HACKERS] Custom compression methods

On 2021-Mar-19, Robert Haas wrote: > On Fri, Mar 19, 2021 at 10:11 AM Dilip Kumar wrote: > > Also added a test case for vacuum full to recompress the data. > > I committed the core patch (0003) with a bit more editing. Let's see > what the buildfarm thinks. I updated the coverage script to

Re: [HACKERS] Custom compression methods

On 2021-Mar-19, Robert Haas wrote: > > Regarding your point, that does look like clutter. We don't annotate > > the dump with a storage clause unless it's non-default, so probably we > > should do the same thing here. I think I gave Dilip bad advice here... > > Here's a patch for that. It's a

Re: Bringing some sanity to RestoreGUCState()

I wrote: > The argument for "sending too little" comes from the race condition > that's described in the function's comments: a variable that has > source PGC_S_DEFAULT (ie, has never moved off its compiled-in default) > in the leader could have just been updated in the postmaster, due to >

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 5:29 PM Andres Freund wrote: > On 2021-03-19 22:19:49 +0100, Tomas Vondra wrote: > > Yeah. And why does it even require pkg-config, unlike any other library > > that I'm aware of? > > IMO it's fine to require pkg-config to simplify the configure > code. Especially for new

Re: [PATCH] Hooks at XactCommand level

Le 12/03/2021 à 06:55, Julien Rouhaud a écrit : > Hi, > > On Tue, Dec 08, 2020 at 11:15:12AM +0100, Gilles Darold wrote: >> Based on a PoC reported in a previous thread [1] I'd like to propose new >> hooks around transaction commands. The objective of this patch is to >> allow PostgreSQL extension

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 4:38 PM Robert Haas wrote: > Yes, and prion's got this concerning diff: > > Column | Type | Collation | Nullable | Default | Storage | > Compression | Stats target | Description > >

Re: [HACKERS] Custom compression methods

On 2021-03-19 22:19:49 +0100, Tomas Vondra wrote: > Yeah. And why does it even require pkg-config, unlike any other library > that I'm aware of? IMO it's fine to require pkg-config to simplify the configure code. Especially for new optional features. Adding multiple alternative ways to discover

Re: shared-memory based stats collector

Hi, On 2021-03-10 20:26:56 -0800, Andres Freund wrote: > > + shhashent = dshash_find_extended(pgStatSharedHash, , > > + > > create, nowait, create, ); > > + if (shhashent) > > + { > > + if (create && !shfound) > >

Re: [HACKERS] Custom compression methods

On 3/19/21 9:40 PM, Andres Freund wrote: > On 2021-03-19 17:35:58 -0300, Alvaro Herrera wrote: >> I find this behavior confusing; I'd rather have configure error out if >> it can't find the package support I requested, than continuing with a >> set of configure options different from what I gave.

Re: Speeding up GIST index creation for tsvectors

On Fri, Mar 19, 2021 at 8:57 AM Amit Khandekar wrote: > > On Thu, 11 Mar 2021 at 04:25, John Naylor wrote: > > Okay, so it's hard-coded in various functions in contrib modules. In that > > case, let's just keep the existing coding for those. In fact, the comments > > that got removed by your

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On Fri, Sep 11, 2020 at 5:11 PM James Coleman wrote: > > On Tue, Sep 8, 2020 at 4:37 PM Heikki Linnakangas wrote: > > > > On 08/09/2020 22:25, James Coleman wrote: > > > On Wed, Aug 19, 2020 at 3:16 AM Heikki Linnakangas > > > wrote: > > >> > > >> You could also apply the optimization for

Re: [HACKERS] Custom compression methods

On 2021-03-19 17:35:58 -0300, Alvaro Herrera wrote: > I find this behavior confusing; I'd rather have configure error out if > it can't find the package support I requested, than continuing with a > set of configure options different from what I gave. +1

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 4:20 PM Tom Lane wrote: > Nope ... crake's displeased with your assumption that it's OK to > clutter dumps with COMPRESSION clauses. As am I: that is going to > be utterly fatal for cross-version transportation of dumps. Yes, and prion's got this concerning diff:

Re: [HACKERS] Custom compression methods

Hmm, if I use configure --with-lz4, I get this: checking whether to build with LZ4 support... yes checking for liblz4... no configure: error: Package requirements (liblz4) were not met: No package 'liblz4' found Consider adjusting the PKG_CONFIG_PATH

Re: pglz compression performance, take two

> On Jan 28, 2021, at 2:56 AM, Andrey Borodin wrote: > > > >> 22 янв. 2021 г., в 07:48, Justin Pryzby написал(а): >> >> @cfbot: rebased >> <0001-Reorganize-pglz-compression-code.patch> > > Thanks! > > I'm experimenting with TPC-C over PostgreSQL 13 on production-like cluster in > the

Re: [PATCH] Identify LWLocks in tracepoints

On 18.03.21 07:34, Craig Ringer wrote: The main reason I didn't want to add more tracepoints than were strictly necessary is that Pg doesn't enable the systemtap semaphores feature, so right now we do a T_NAME(lock) evaluation each time we pass a tracepoint if --enable-dtrace is compiled in,

Re: [HACKERS] Custom compression methods

I wrote: > Since no animals will be using --with-lz4, I'd expect vast silence. Nope ... crake's displeased with your assumption that it's OK to clutter dumps with COMPRESSION clauses. As am I: that is going to be utterly fatal for cross-version transportation of dumps.

Re: [HACKERS] Custom compression methods

Robert Haas writes: > I committed the core patch (0003) with a bit more editing. Let's see > what the buildfarm thinks. Since no animals will be using --with-lz4, I'd expect vast silence. regards, tom lane

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

Peter Eisentraut writes: > Well, I had an idea that I put to work. In most of these cases where we > need division, we divide an integer by a power of 10. That can be done > with numeric very quickly by just shifting the weight and scale around. > So I wrote a function that does that

Re: [PATCH] Identify LWLocks in tracepoints

On 18.03.21 07:34, Craig Ringer wrote: In patch 0001, why was the TRACE_POSTGRESQL_LWLOCK_RELEASE() call moved?   Is there some correctness issue?  If so, we should explain that (at least in the commit message, or as a separate patch). If you want I can split it out, or drop

Re: [PATCH] ProcessInterrupts_hook

Robert Haas writes: > On Fri, Mar 19, 2021 at 3:25 PM Tom Lane wrote: >> I'm not very comfortable about the idea of having the postmaster set >> child processes' latches ... that doesn't sound terribly safe from the >> standpoint of not allowing the postmaster to mess with shared memory >> state

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 10:11 AM Dilip Kumar wrote: > Also added a test case for vacuum full to recompress the data. I committed the core patch (0003) with a bit more editing. Let's see what the buildfarm thinks. -- Robert Haas EDB: http://www.enterprisedb.com

Re: [PATCH] ProcessInterrupts_hook

On Fri, Mar 19, 2021 at 3:25 PM Tom Lane wrote: > David Steele writes: > > On 1/19/21 1:42 AM, Craig Ringer wrote: > >> My suggestion, which I'm happy to post in patch form if you think it's > >> reasonable > > > Tom, Robert, and thoughts on the proposals in [1]? > >

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

On 18.03.21 09:28, Peter Eisentraut wrote: Which leads me to:  After retesting this now, with a new machine, the performance of the numeric implementation is brutal compared to the float implementation, for cases where we need numeric division, which is milliseconds, seconds, and epoch.  In

Re: pglz compression performance, take two

> On Jan 21, 2021, at 6:48 PM, Justin Pryzby wrote: > > @cfbot: rebased > <0001-Reorganize-pglz-compression-code.patch> Review comments. First, I installed a build from master without this patch, created a test installation with lots of compressed text and array columns, upgraded the

Re: [PATCH] ProcessInterrupts_hook

David Steele writes: > On 1/19/21 1:42 AM, Craig Ringer wrote: >> My suggestion, which I'm happy to post in patch form if you think it's >> reasonable > Tom, Robert, and thoughts on the proposals in [1]? >

Re: Do we work with LLVM 12 on s390x?

Andres Freund writes: > I think the error above comes from a "mismatch" between the clang used > to compile bitcode, and the LLVM version linked to. Normally we're > somewhat tolerant of differences between the two, but there was an ABI > change at some point, leading to that error. IIRC I hit

Re: Do we work with LLVM 12 on s390x?

Hi, On 2021-03-19 14:03:21 -0400, Tom Lane wrote: > The Red Hat folk are seeing a problem with that combination: > > https://bugzilla.redhat.com/show_bug.cgi?id=1940964 > > which boils down to > > > Build fails with this error: > > ERROR: failed to JIT module: Added modules have incompatible

Replication slot stats misgivings

Hi, I started to write this as a reply to https://postgr.es/m/20210318015105.dcfa4ceybdjubf2i%40alap3.anarazel.de but I think it doesn't really fit under that header anymore. On 2021-03-17 18:51:05 -0700, Andres Freund wrote: > It does make it easier for the shared memory stats patch, because if

Re: non-HOT update not looking at FSM for large tuple update

On Fri, 19 Mar 2021 at 19:16, John Naylor wrote: > > On Thu, Mar 18, 2021 at 5:30 PM Matthias van de Meent > wrote: > > > > This is slightly more verbose, but I think this clarifies the > > reasoning why we need this a bit better. Feel free to reject or adapt > > as needed. > > I like this in

Re: Proposal: Save user's original authenticated identity for logging

On Fri, 2021-03-19 at 16:54 +, Jacob Champion wrote: > One additional improvement I would suggest, now that the rotation logic > is simpler than it was in my original patch, is to rotate the logfile > regardless of whether the test is checking the logs or not. (Similarly, > we can manually

Re: non-HOT update not looking at FSM for large tuple update

On Thu, Mar 18, 2021 at 5:30 PM Matthias van de Meent < boekewurm+postg...@gmail.com> wrote: > > > + * The minimum space on a page for it to be considered "empty" regardless > > + * of fillfactor. We base this on MaxHeapTupleSize, minus a small amount > > + * of slack. We allow slack

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 1:44 PM Justin Pryzby wrote: > Working with one of Andrey's patches on another thread, he reported offlist > getting this message, resolved by this patch. Do you see this warning during > ./configure ? The latest CI is of a single patch without the LZ4 stuff, so I >

Do we work with LLVM 12 on s390x?

The Red Hat folk are seeing a problem with that combination: https://bugzilla.redhat.com/show_bug.cgi?id=1940964 which boils down to > Build fails with this error: > ERROR: failed to JIT module: Added modules have incompatible data layouts: > E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-a:8:16-n32:64

Re: cleanup temporary files after crash

On Fri, Mar 19, 2021, at 2:27 PM, Tomas Vondra wrote: > I've pushed this version, with the plpgsql block. I've tested it on all > the machines I have here, hopefully it'll make buildfarm happy too. Thanks for taking care of this issue. > AFAICS I was mistaken about what the pump() functions do -

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 01:24:39PM -0400, Robert Haas wrote: > On Fri, Mar 19, 2021 at 12:35 PM Justin Pryzby wrote: > > I sent offlist a couple of times but notice that the latest patch is missing > > this bit around AC_CHECK_HEADERS, which apparently can sometimes cause > > warnings on mac. > >

Re: Columns correlation and adaptive query optimization

Hi, In AddMultiColumnStatisticsForQual(), + /* Loop until we considered all vars */ + while (vars != NULL) ... + /* Contruct list of unique vars */ + foreach (cell, vars) What if some cell / node, gets into the else block: + else + { +

Bringing some sanity to RestoreGUCState()

In the thread about valgrind leak detection [1], we noticed that RestoreGUCState(), which is intended to load the leader process's GUC settings into a parallel worker, was causing visible memory leaks by invoking InitializeOneGUCOption() on already-set-up GUCs. I noted that simply removing that

Re: cleanup temporary files after crash

On 3/19/21 5:26 PM, Tomas Vondra wrote: > On 3/19/21 5:23 PM, Tomas Vondra wrote: >> ... >> >> If I replace this with a wait loop in a plpgsql block, that works >> perfectly fine (no infinite loops). Tested both on x86_64 and rpi. >> > > For the record, here's the version with plpgsql block,

Failed assertion on standby while shutdown

Hi, haсkers! Recently, I was doing some experiments with primary/standby instances interaction. In certain conditions I’ve got and was able to reproduce crash on failed assertion. The scenario is the following: 1. start primary server 2. start standby server by pg_basebackup -P -R -X stream

Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 12:35 PM Justin Pryzby wrote: > I sent offlist a couple of times but notice that the latest patch is missing > this bit around AC_CHECK_HEADERS, which apparently can sometimes cause > warnings on mac. > > ac_save_CPPFLAGS=$CPPFLAGS > CPPFLAGS="$LZ4_CFLAGS $CPPFLAGS" >

Re: support for MERGE

On Fri, Mar 19, 2021 at 10:53:53AM -0400, David Steele wrote: > On 3/19/21 10:44 AM, Alvaro Herrera wrote: > > On 2021-Mar-19, David Steele wrote: > > > > > Since it does not appear this is being worked on for PG14 perhaps we > > > should > > > close it in this CF and then reopen it when a patch

Re: Columns correlation and adaptive query optimization

On 19.03.2021 12:17, Yugo NAGATA wrote: On Wed, 10 Mar 2021 03:00:25 +0100 Tomas Vondra wrote: What is being proposed here - an extension suggesting which statistics to create (and possibly creating them automatically) is certainly useful, but I'm not sure I'd call it "adaptive query

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Mar 19, 2021 at 10:27:51PM +0800, Julien Rouhaud wrote: > On Fri, Mar 19, 2021 at 09:29:06AM -0400, Bruce Momjian wrote: > > OK, that makes perfect sense. I think the best solution is to document > > that compute_query_id just controls the built-in computation of the > > query id, and

Re: Proposal: Save user's original authenticated identity for logging

On Fri, 2021-03-19 at 17:21 +0900, Michael Paquier wrote: > On Thu, Mar 18, 2021 at 05:14:24PM +0900, Michael Paquier wrote: > > Looking at 0001, I am not much a fan of relying on the position of the > > matching pattern in the log file. Instead of relying on the logging > > collector and one

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Mar 19, 2021 at 10:35:21PM +0800, Julien Rouhaud wrote: > On Fri, Mar 19, 2021 at 02:54:16PM +0100, Hannu Krosing wrote: > > On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian wrote: > > The log-spam could be mitigated by logging it just once per connection > > the first time it is overridden

Re: [HACKERS] Custom compression methods

I sent offlist a couple of times but notice that the latest patch is missing this bit around AC_CHECK_HEADERS, which apparently can sometimes cause warnings on mac. ac_save_CPPFLAGS=$CPPFLAGS CPPFLAGS="$LZ4_CFLAGS $CPPFLAGS" AC_CHECK_HEADERS(lz4/lz4.h, [], [AC_CHECK_HEADERS(lz4.h, [],

Re: cleanup temporary files after crash

On 3/19/21 5:23 PM, Tomas Vondra wrote: > ... > > If I replace this with a wait loop in a plpgsql block, that works > perfectly fine (no infinite loops). Tested both on x86_64 and rpi. > For the record, here's the version with plpgsql block, which seems to be working just fine. regards --

Re: cleanup temporary files after crash

On 3/19/21 5:23 PM, Tomas Vondra wrote: > ... > > If I replace this with a wait loop in a plpgsql block, that works > perfectly fine (no infinite loops). Tested both on x86_64 and rpi. > For the record, here's the version with plpgsql block, which seems to be working just fine. regards --

Re: cleanup temporary files after crash

On 3/19/21 3:17 PM, Euler Taveira wrote: > On Fri, Mar 19, 2021, at 12:23 AM, Tom Lane wrote: >> [ reads code... ] >> ... no, I think the problem is the test is still full of race conditions. >> >> In the first place, waiting till you see the output of a SELECT that's >> before the useful query

Re: Change default of checkpoint_completion_target

On 1/19/21 2:47 PM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost writes: Any further comments or thoughts on this one? This: +total time between checkpoints. The default is 0.9, which spreads the +checkpoint across the entire checkpoint timeout

Re: create table like: ACCESS METHOD

On 1/19/21 4:03 PM, Justin Pryzby wrote: On Wed, Dec 30, 2020 at 12:33:56PM +, Simon Riggs wrote: There are no tests for the new functionality, please could you add some? Did you look at the most recent patch? +CREATE ACCESS METHOD heapdup TYPE TABLE HANDLER heap_tableam_handler; +CREATE

Re: Logical Replication vs. 2PC

On 18.03.21 10:45, Amit Kapila wrote: While reviewing/testing subscriber-side work for $SUBJECT [1], I noticed a problem that seems to need a broader discussion, so started this thread. We can get prepare for the same GID more than once for the cases where we have defined multiple subscriptions

Re: psql \df choose functions by their arguments

On 1/19/21 11:58 AM, Greg Sabino Mullane wrote: Ha ha ha, my bad, I am not sure why I left those out. Here is a new patch with int2, int4, and int8. Thanks for the email. Ian, does the new patch look good to you? Also, not sure why the target version for this patch is stable so I have

Re: [PATCH] ProcessInterrupts_hook

On 1/19/21 1:42 AM, Craig Ringer wrote: On Tue, 19 Jan 2021 at 12:44, Craig Ringer mailto:craig.rin...@enterprisedb.com>> wrote: > We're about halfway there already, see 7e784d1dc.  I didn't do the > other half because it wasn't necessary to the problem, but

Re: Disable WAL logging to speed up data loading

Greetings, * tsunakawa.ta...@fujitsu.com (tsunakawa.ta...@fujitsu.com) wrote: > From: David Steele > > After reading through the thread (but not reading the patch) I am -1 on > > this proposal. > > > > The feature seems ripe for abuse and misunderstanding, and as has been > > noted in the

Re: default result formats setting

I applied the patch, tried running the test and got the following: rm -rf '/Users/hasegeli/Developer/postgres/src/test/modules/libpq_extended'/tmp_check /bin/sh ../../../../config/install-sh -c -d '/Users/hasegeli/Developer/postgres/src/test/modules/libpq_extended'/tmp_check cd . &&

Re: truncating timestamps on arbitrary intervals

On 1/18/21 3:54 PM, John Naylor wrote: On Mon, Nov 23, 2020 at 1:44 PM John Naylor mailto:john.nay...@enterprisedb.com>> wrote: > > On Thu, Nov 12, 2020 at 9:56 AM Peter Eisentraut > wrote: > > - After reading the discussion a few times, I'm not so

Re: support for MERGE

On 3/19/21 10:44 AM, Alvaro Herrera wrote: On 2021-Mar-19, David Steele wrote: Since it does not appear this is being worked on for PG14 perhaps we should close it in this CF and then reopen it when a patch is available? No, please move it to the next CF. Thanks Ugh. I clicked wrong and

Re: support for MERGE

On 2021-Mar-19, David Steele wrote: > Since it does not appear this is being worked on for PG14 perhaps we should > close it in this CF and then reopen it when a patch is available? No, please move it to the next CF. Thanks -- Álvaro Herrera Valdivia, Chile

Re: Nicer error when connecting to standby with hot_standby=off

On Tue, Mar 9, 2021 at 9:27 AM Fujii Masao wrote: > > > > On 2021/03/09 23:19, James Coleman wrote: > > On Tue, Mar 9, 2021 at 9:17 AM Alvaro Herrera > > wrote: > >> > >> On 2021-Mar-09, James Coleman wrote: > >> > >>> Yes, I think they both agreed on the "DETAIL: Hot standby mode is > >>>

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Mar 19, 2021 at 02:54:16PM +0100, Hannu Krosing wrote: > On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian wrote: > > > > OK, that makes perfect sense. I think the best solution is to document > > that compute_query_id just controls the built-in computation of the > > query id, and that

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Fri, Mar 19, 2021 at 09:29:06AM -0400, Bruce Momjian wrote: > On Fri, Mar 19, 2021 at 11:16:50AM +0800, Julien Rouhaud wrote: > > Now that I'm back on the code I remember why I did it this way. It's > > unfortunately not really possible to make things work this way. > > > >

Re: cleanup temporary files after crash

On Fri, Mar 19, 2021, at 12:23 AM, Tom Lane wrote: > [ reads code... ] > ... no, I think the problem is the test is still full of race conditions. > > In the first place, waiting till you see the output of a SELECT that's > before the useful query is not enough to guarantee that the useful query

Re: [PATCH] pg_stat_statements dealloc field ignores manual deallocation

On Fri, Mar 19, 2021 at 05:08:45PM +0300, Андрей Зубков wrote: > > Since 2e0fedf there is a view pg_stat_statements_info is available in > pg_stat_statements extension. It has a dealloc field, that should be a > counter of deallocation events happened. > Right now it accounts only automatic

Re: support for MERGE

On 1/18/21 11:48 AM, Alvaro Herrera wrote: On 2021-Jan-18, Robert Haas wrote: On Thu, Dec 31, 2020 at 8:48 AM Alvaro Herrera wrote: Here's a rebase of Simon/Pavan's MERGE patch to current sources. I cleaned up some minor things in it, but aside from rebasing, it's pretty much their work

  1   2   >