RE: Disable WAL logging to speed up data loading

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 thread, there are a variety of alternatives that can > provide a similar effect. > > It doesn't

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

Hi On Saturday, March 13, 2021 5:01 PM osumi.takami...@fujitsu.com wrote: > On Friday, March 12, 2021 5:40 PM Peter Smith > > Please find attached the latest patch set v58* > Thank you for updating those. I'm testing the patchset and I think it's > preferable that you add simple two types of m

Re: libpq compression

On Thu, Mar 18, 2021 at 08:02:32PM -0500, Justin Pryzby wrote: > On Thu, Mar 18, 2021 at 07:30:09PM +, Daniil Zakhlystov wrote: > > The new status of this patch is: Ready for Committer > > The CF bot is failing , because the last patch sent to the list is from > January: > | Latest attachment

Re: a verbose option for autovacuum

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 integration of the index stats into LVRelStats to help with debugging issues

RE: Wrong statistics for size of XLOG_SWITCH during pg_waldump.

>>>But 0 value maybe looks strange, so in current version I show it like >below: >>>Type N (%) Record size (%) FPI size (%) Combined size (%) >>> - --- --- --- --- - --- ... >>>XLOG/SWITCH_JUNK - ( -) 11006248 ( 72.26) - ( -) 11006248 ( 65.78) >>>Transaction/COMMIT

Re: A new function to wait for the backend exit after termination

On Thu, Mar 18, 2021 at 1:11 PM Bharath Rupireddy wrote: > > On Thu, Mar 18, 2021 at 12:46 PM Fujii Masao > wrote: > > On 2021/03/17 11:58, Kyotaro Horiguchi wrote: > > > The first suggested signature for pg_terminate_backend() with timeout > > > was pg_terminate_backend(pid, timeout). The curre

Re: Logical Replication vs. 2PC

On Thu, Mar 18, 2021 at 8:46 PM Amit Kapila wrote: > > > However, if the user has setup synchronous_standby_names for all the > subscriptions then we won't be able to proceed because the prepare on > publisher will wait for all the subscriptions to ack and the > subscriptions are waiting for the

Re: Parallel Inserts in CREATE TABLE AS

On Wed, Jan 27, 2021 at 1:47 PM Bharath Rupireddy wrote: > > On Wed, Jan 27, 2021 at 1:25 PM Tang, Haiying > wrote: > > I choose 5 cases which pick parallel insert plan in CTAS to measure the > > patched performance. Each case run 30 times. > > > > Most of the tests execution become faster with

Re: fdatasync performance problem with large number of DB files

On Fri, Mar 19, 2021 at 3:23 PM Fujii Masao wrote: > Thanks for updating the patch! It looks good to me! > I have one minor comment for the patch. > > + elog(LOG, "could not open %s: %m", path); > + return; > + } > + if (syncfs(fd) < 0) > + elo

Re: Type of wait events WalReceiverWaitStart and WalSenderWaitForWAL

On 2021/03/18 18:48, Fujii Masao wrote: WAIT_EVENT_WAL_RECEIVER_WAIT_START is waiting for waiting for starup process to kick me.  So it may be either IPC or Activity.  Since walreceiver hasn't sent anything to startup, so it's activity, rather than IPC.  However, the behavior can be said that i

Re: Using COPY FREEZE in pgbench

> I have looked in the code of PQprotocolVersion. The only case in which > it returns 0 is there's no connection. Yes, you are right. Once the > connection has been successfuly established, there's no chance it > fails. So I agree with you. Attached v3 patch addresses this. >> The "g" item in the

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

On 2021/03/18 19:16, Masahiro Ikeda wrote: As you said, the temporary stats files don't removed if the stats collector is killed with SIGQUIT. So, if the user change the GUC parameter "stats_temp_directory" after immediate shutdown, temporary stats file can't be removed forever. But, I thin

Re: Logical Replication vs. 2PC

On Thu, Mar 18, 2021 at 5:31 PM vignesh C wrote: > > On Thu, Mar 18, 2021 at 3:16 PM Amit Kapila wrote: > > > > > > In short, on the subscriber, both the apply workers (corresponding to > > two subscriptions) are getting the same prepare transaction GID, > > leading to an error on the subscriber

Re: cleanup temporary files after crash

[ 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 is done, or even started. That's broken on both sessions. In

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

On Thu, Mar 18, 2021 at 03:23:49PM -0400, Bruce Momjian wrote: > On Fri, Mar 19, 2021 at 02:06:56AM +0800, Julien Rouhaud wrote: > > The above text is the part that made me think an extension could display > a query id even if disabled by the GUC. With the last version of the patch I sent it was

Re: fdatasync performance problem with large number of DB files

On 2021/03/19 11:22, Fujii Masao wrote: On 2021/03/19 10:37, Thomas Munro wrote: On Fri, Mar 19, 2021 at 2:16 PM Thomas Munro wrote: PS: For illustration/discussion, I've also attached a "none" patch.  I also couldn't resist rebasing my "wal" mode patch, which I plan to propose for PG15 b

Re: cleanup temporary files after crash

On 3/19/21 3:57 AM, Tom Lane wrote: > Tomas Vondra writes: >> So crake and florican seem to be happy now. Not sure about lapwing yet. >> But interestingly enough, prion and curculio got unhappy. They worked >> fine with the older test, but now it fails with the "no such file or >> directory" messa

Re: cleanup temporary files after crash

Tomas Vondra writes: > So crake and florican seem to be happy now. Not sure about lapwing yet. > But interestingly enough, prion and curculio got unhappy. They worked > fine with the older test, but now it fails with the "no such file or > directory" message. I wonder what makes them different fro

Re: cleanup temporary files after crash

On 3/19/21 2:21 AM, Tomas Vondra wrote: > On 3/19/21 1:54 AM, Euler Taveira wrote: >> On Thu, Mar 18, 2021, at 8:34 PM, Tomas Vondra wrote: >>> Well, that's better, bit it still does not do the trick on the 32-bit >>> machine - in that case a 1000 rows with int4 still fit into work_mem, so >>> the

RE: libpq debug log

Hello Iwata-san, Thanks to removing the static arrays, the code got much smaller. I'm happy with this result. (1) + (> for messages from client to server, + and < for messages from server to client), I think this was meant to say "> or <". So, maybe you should remove "," at the e

Re: comment fix in postmaster.c

On 2021/03/16 18:27, Fujii Masao wrote: Thanks for the path! LGTM. Barring any objection, I will push the patch. Pushed. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION

Re: fdatasync performance problem with large number of DB files

On 2021/03/19 10:37, Thomas Munro wrote: On Fri, Mar 19, 2021 at 2:16 PM Thomas Munro wrote: PS: For illustration/discussion, I've also attached a "none" patch. I also couldn't resist rebasing my "wal" mode patch, which I plan to propose for PG15 because there is not enough time left for th

Re: [PATCH] pgbench: improve \sleep meta command

On 2021/03/19 10:02, kuroda.hay...@fujitsu.com wrote: Dear Fujii-san, I confirmed your patch and some parse functions, and I agree the check condition in evaluateSleep() is correct. No problem is found. Thanks for reviewing the patch! Barring any objection, I will commit this patch. Regard

Re: New IndexAM API controlling index vacuum strategies

On Thu, Mar 18, 2021 at 2:05 PM Robert Haas wrote: > On Wed, Mar 17, 2021 at 11:23 PM Peter Geoghegan wrote: > > Most anti-wraparound VACUUMs are really not emergencies, though. > > That's true, but it's equally true that most of the time it's not > necessary to wear a seatbelt to avoid personal

Re: fdatasync performance problem with large number of DB files

On Fri, Mar 19, 2021 at 2:16 PM Thomas Munro wrote: > PS: For illustration/discussion, I've also attached a "none" patch. I > also couldn't resist rebasing my "wal" mode patch, which I plan to > propose for PG15 because there is not enough time left for this > release. Erm... I attached the wron

Re: WIP: WAL prefetch (another approach)

On 3/18/21 1:54 AM, Thomas Munro wrote: > On Thu, Mar 18, 2021 at 12:00 PM Tomas Vondra > wrote: >> On 3/17/21 10:43 PM, Stephen Frost wrote: >>> Guess I'm just not a fan of pushing out a change that will impact >>> everyone by default, in a possibly negative way (or positive, though >>> that does

Re: cleanup temporary files after crash

On 3/19/21 1:54 AM, Euler Taveira wrote: > On Thu, Mar 18, 2021, at 8:34 PM, Tomas Vondra wrote: >> Well, that's better, bit it still does not do the trick on the 32-bit >> machine - in that case a 1000 rows with int4 still fit into work_mem, so >> the temp file is not created. Per my experiments a

Re: fdatasync performance problem with large number of DB files

On Fri, Mar 19, 2021 at 5:50 AM Fujii Masao wrote: > On 2021/03/18 23:03, Bruce Momjian wrote: > >> Are we sure we want to use the word "crash" here? I don't remember > >> seeing it used anywhere else in our user interface. > > We have GUC restart_after_crash. > > > I guess it is > >> "crash rec

Re: libpq compression

On Thu, Mar 18, 2021 at 07:30:09PM +, Daniil Zakhlystov wrote: > The new status of this patch is: Ready for Committer The CF bot is failing , because the last patch sent to the list is from January: | Latest attachment (libpq-compression-31.patch) at 2021-01-12 14:05:22 from Konstantin Knizhn

RE: [PATCH] pgbench: improve \sleep meta command

Dear Fujii-san, I confirmed your patch and some parse functions, and I agree the check condition in evaluateSleep() is correct. No problem is found. Best Regards, Hayato Kuroda FUJITSU LIMITED

Re: cleanup temporary files after crash

On Thu, Mar 18, 2021, at 8:34 PM, Tomas Vondra wrote: > Well, that's better, bit it still does not do the trick on the 32-bit > machine - in that case a 1000 rows with int4 still fit into work_mem, so > the temp file is not created. Per my experiments about 1040 rows are > needed - s close ;-)

Re: psql tab completion for \h with IMPORT FOREIGN SCHEMA

On Thu, Mar 18, 2021 at 07:45:36AM +, gkokola...@pm.me wrote: > It seems helpful. Thank you. Thanks, applied then. -- Michael signature.asc Description: PGP signature

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

Peter Geoghegan writes: > On Thu, Mar 18, 2021 at 4:40 PM Tom Lane wrote: >> Good question. We don't have a standard about that (whether to >> do those in separate or the same commits), but we could establish one >> if it seems helpful. > I don't think that it matters too much, but it will nece

Re: GROUP BY DISTINCT

On 3/19/21 12:52 AM, Tomas Vondra wrote: > > On 3/19/21 12:26 AM, Tom Lane wrote: >> I wrote: >>> This is gcc 4.5, but hopefully whatever shuts it up will also work on 4.7. >>> I'll work on figuring that out. >> >> Actually, the problem is pretty obvious after comparing this use >> of foreach_dele

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

On Thu, Mar 18, 2021 at 4:40 PM Tom Lane wrote: > Good question. We don't have a standard about that (whether to > do those in separate or the same commits), but we could establish one > if it seems helpful. I don't think that it matters too much, but it will necessitate updating the file multip

Re: GROUP BY DISTINCT

On 3/19/21 12:26 AM, Tom Lane wrote: > I wrote: >> This is gcc 4.5, but hopefully whatever shuts it up will also work on 4.7. >> I'll work on figuring that out. > > Actually, the problem is pretty obvious after comparing this use > of foreach_delete_current() to every other one. I'm not sure wh

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

Peter Geoghegan writes: > What about reformat-dat-files and perltidy runs? It seems that you > have sometimes used all three reformatting tools to produce one commit > -- but not always. ISTM that I should get any of those that I missed. > And that the pgindent README (which already mentions these

Re: cleanup temporary files after crash

On 3/18/21 10:44 PM, Euler Taveira wrote: > On Thu, Mar 18, 2021, at 6:00 PM, Euler Taveira wrote: >> On Thu, Mar 18, 2021, at 5:51 PM, Tomas Vondra wrote: >>> OK. Can you prepare a patch with the proposed test approach? >> I'm on it. > What do you think about this patch? > Well, that's better, b

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

On Thu, Mar 18, 2021 at 4:05 PM Tom Lane wrote: > b5d69b7c22ee4c44b8bb99cfa0466ffaf3b5fab9 # Sun Jun 7 16:57:08 2020 -0400 > # pgindent run prior to branching v13. > > which is easy to make from "git log" or "git show" output. (Because > of the precedent of those tools, I'd rather write the comm

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

On Thu, Mar 18, 2021 at 07:05:03PM -0400, Tom Lane wrote: > Other points: the file should be kept in src/tools/pgindent/, and > it should definitely NOT have a name beginning with ".". Well, if we want github and others to eventually honor a file, it seems .git-blame-ignore-revs at the top of the

Re: GROUP BY DISTINCT

I wrote: > This is gcc 4.5, but hopefully whatever shuts it up will also work on 4.7. > I'll work on figuring that out. Actually, the problem is pretty obvious after comparing this use of foreach_delete_current() to every other one. I'm not sure why the compiler warnings are phrased just as they

Re: GROUP BY DISTINCT

I wrote: > Hmm ... prairiedog isn't showing the warning, but maybe gaur will. Bingo: parse_agg.c: In function 'expand_grouping_sets': parse_agg.c:1851:5: warning: value computed is not used This is gcc 4.5, but hopefully whatever shuts it up will also work on 4.7. I'll work on figuring that out.

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

Peter Geoghegan writes: > On Thu, Mar 18, 2021 at 3:39 PM Tom Lane wrote: >> I don't object to maintaining such a file; if it makes "git blame" >> work better, that's a huge win. However, the file as you have it >> seems rather unreadable. I'd much rather have something that includes >> the com

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

On Thu, Mar 18, 2021 at 4:00 PM Bruce Momjian wrote: > Probably because later commits might collide with shorter hashes. When > you are reporting a hash that only looks _backward_, this is not an > issue. Right, but it's extremely unlikely to happen by accident. I was suggesting that there might

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

On Thu, Mar 18, 2021 at 03:46:10PM -0700, Peter Geoghegan wrote: > It's worth noting that git insists that you provide the full hash of > commits here. This is not something I remember it insisting upon in > any other area. There is probably a very good practical reason for > that. Probably becaus

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

On Thu, Mar 18, 2021 at 3:39 PM Tom Lane wrote: > I don't object to maintaining such a file; if it makes "git blame" > work better, that's a huge win. However, the file as you have it > seems rather unreadable. I'd much rather have something that includes > the commit date and/or first line of c

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

Peter Geoghegan writes: > Attached is my .git-blame-ignore-revs file, which has pgindent commits > that I'd like to exclude from git blame. The file is helpful on its > own. But what we really ought to do is commit the file (perhaps with > some revisions) and require that it be maintained by the o

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

On Thu, Mar 18, 2021 at 03:20:37PM -0700, Peter Geoghegan wrote: > On Thu, Mar 18, 2021 at 3:12 PM Bruce Momjian wrote: > > It would be kind of nice if the file can be generated automatically. I > > have you checked if 'pgindent' being on the first line of the commit is > > sufficient? > > I gen

Re: GROUP BY DISTINCT

Thomas Munro writes: > On Fri, Mar 19, 2021 at 10:14 AM Tomas Vondra > wrote: >> Thanks for the info. So it's likely related to older gcc releases. The >> question is how to tweak the code to get rid of this ... > It's frustrating to have to do press-ups to fix a problem because a > zombie Debia

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

On Thu, Mar 18, 2021 at 3:12 PM Bruce Momjian wrote: > It would be kind of nice if the file can be generated automatically. I > have you checked if 'pgindent' being on the first line of the commit is > sufficient? I generated the file by looking for commits that: 1) Mentioned "pgindent" or "PGI

PG13 fails to startup even though the current transaction is equal to the target transaction

We've noticed what may be a regression / bug in PG13. I work at Heroku on the Data team, where we manage a fleet of Postgres services. This change has resulted in breaking the UX we offer to customers to manage their PG services. In particular, ‘forks’ and ‘point in time restores’ seem broken for

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

On Thu, Mar 18, 2021 at 03:03:41PM -0700, Peter Geoghegan wrote: > Attached is my .git-blame-ignore-revs file, which has pgindent commits > that I'd like to exclude from git blame. The file is helpful on its > own. But what we really ought to do is commit the file (perhaps with > some revisions) an

Re: a verbose option for autovacuum

On Thu, Mar 18, 2021 at 2:08 PM Michael Paquier wrote: > Yes, I was waiting for Sawada-san to send an updated version, which he > just did. Great. This really seems worth having. I was hoping that somebody else could pick this one up. -- Peter Geoghegan

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

On Thu, Mar 18, 2021 at 2:10 PM Bruce Momjian wrote: > Actually, Tom Lane runs pgindent usually now. I do the copyright > change, but I don't think we would ignore those since the single-line > change is probably something we would want to blame. The copyright change commits don't need to be con

Re: GROUP BY DISTINCT

On Fri, Mar 19, 2021 at 10:14 AM Tomas Vondra wrote: > >> The only possibility I can think of is some sort of issue in the old-ish > >> gcc release (4.7.2). > > > > No sure what's going on there, but data points: I tried a 32 bit build > > here (that's the other special thing about lapwing) and di

Re: Getting better results from valgrind leak tracking

I wrote: > Andres Freund writes: >> There's plenty other hits, but I think I should get back to working on >> making the shared memory stats patch committable. I really wouldn't want >> it to slip yet another year. > +1, so far there's little indication that we're finding any serious leaks > here

Re: cleanup temporary files after crash

On Thu, Mar 18, 2021, at 6:00 PM, Euler Taveira wrote: > On Thu, Mar 18, 2021, at 5:51 PM, Tomas Vondra wrote: >> OK. Can you prepare a patch with the proposed test approach? > I'm on it. What do you think about this patch? -- Euler Taveira EDB https://www.enterprisedb.com/ diff --git a/src/tes

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

On Wed, 17 Mar 2021 at 21:52, John Naylor wrote: > > On Fri, Mar 12, 2021 at 8:45 AM Matthias van de Meent > wrote: > > > > If this case isn't added, the lower else branch will fail to find > > fitting pages for len > maxPaddedFsmRequest tuples; potentially > > extending the relation when there

Re: GROUP BY DISTINCT

On 3/18/21 10:02 PM, Thomas Munro wrote: > On Fri, Mar 19, 2021 at 8:27 AM Tomas Vondra > wrote: >> Hmmm, this seems to fail on lapwing with this error: >> >> parse_agg.c: In function 'expand_grouping_sets': >> parse_agg.c:1851:23: error: value computed is not used >> [-Werror=unused-value] >>

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

On Thu, Mar 18, 2021 at 01:46:49PM -0700, Peter Geoghegan wrote: > Recent versions of git are capable of maintaining a list of commits > for "git blame" to ignore: > > https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame > > I tried this out myself, using my own list of pgind

Re: a verbose option for autovacuum

On Thu, Mar 18, 2021 at 09:38:05AM -0700, Peter Geoghegan wrote: > Were you going to take care of this, Michael? Yes, I was waiting for Sawada-san to send an updated version, which he just did. -- Michael signature.asc Description: PGP signature

Re: New IndexAM API controlling index vacuum strategies

On Wed, Mar 17, 2021 at 11:23 PM Peter Geoghegan wrote: > Most anti-wraparound VACUUMs are really not emergencies, though. That's true, but it's equally true that most of the time it's not necessary to wear a seatbelt to avoid personal injury. The difficulty is that it's hard to predict on which

Re: GROUP BY DISTINCT

On Fri, Mar 19, 2021 at 8:27 AM Tomas Vondra wrote: > Hmmm, this seems to fail on lapwing with this error: > > parse_agg.c: In function 'expand_grouping_sets': > parse_agg.c:1851:23: error: value computed is not used > [-Werror=unused-value] > cc1: all warnings being treated as errors > > That lin

Re: cleanup temporary files after crash

On Thu, Mar 18, 2021, at 5:51 PM, Tomas Vondra wrote: > OK. Can you prepare a patch with the proposed test approach? I'm on it. > FWIW I can reproduce this on a 32-bit ARM system (rpi4), where 500 rows > simply does not use a temp file, and with 1000 rows it works fine. On > the x86_64 the temp fi

Re: cleanup temporary files after crash

On 3/18/21 9:06 PM, Euler Taveira wrote: > On Thu, Mar 18, 2021, at 4:20 PM, Tomas Vondra wrote: >> I think a better way to test this would be to use a tuple lock: > I predicated such issues with this test. Your suggestion works for me. Maybe > you should use less rows in the session 2 query. >

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

Recent versions of git are capable of maintaining a list of commits for "git blame" to ignore: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame I tried this out myself, using my own list of pgindent commits. It works very well -- much better than what you get when you ask

Re: default result formats setting

On 09.03.21 19:04, Tom Lane wrote: The implementation feels weird though, mainly in that I don't like Peter's choices for where to put the code. pquery.c is not where I would have expected to find the support for this, and I do not have any confidence that applying the format conversion while fi

Re: cleanup temporary files after crash

On Thu, Mar 18, 2021, at 4:20 PM, Tomas Vondra wrote: > I think a better way to test this would be to use a tuple lock: I predicated such issues with this test. Your suggestion works for me. Maybe you should use less rows in the session 2 query. > setup: > > create table t (a int unique); > >

Re: [HACKERS] Custom compression methods

On Thu, Mar 18, 2021 at 10:22 AM Dilip Kumar wrote: > I just realized that in the last patch (0003) I forgot to remove 2 > unused functions, CompressionMethodToId and CompressionIdToMethod. > Removed in the latest patch. I spent a little time polishing 0001 and here's what I came up with. I adjus

Re: libpq compression

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hi, I've compared the different libpq compression approaches

Re: GROUP BY DISTINCT

On 3/18/21 6:25 PM, Tomas Vondra wrote: > On 3/16/21 3:52 PM, Tomas Vondra wrote: >> >> >> On 3/16/21 9:21 AM, Vik Fearing wrote: >>> On 3/13/21 12:33 AM, Tomas Vondra wrote: Hi Vik, The patch seems quite ready, I have just two comments. >>> >>> Thanks for taking a look. >>>

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

On Fri, Mar 19, 2021 at 02:06:56AM +0800, Julien Rouhaud wrote: > On Thu, Mar 18, 2021 at 09:47:29AM -0400, Bruce Momjian wrote: > > On Thu, Mar 18, 2021 at 07:29:56AM +0800, Julien Rouhaud wrote: > > > Note exactly. Right now a custom queryid can be computed even if > > > compute_queryid is off,

Re: cleanup temporary files after crash

On 3/18/21 6:51 PM, Tomas Vondra wrote: > Hmm, > > crake and florican seem to have failed because of this commit, with this > error in the new TAP test: > > error running SQL: 'psql::1: ERROR: could not open directory > "base/pgsql_tmp": No such file or directory' > while running 'psql -XAtq -d

Re: Key management with tests

On Thu, Mar 18, 2021 at 01:46:28PM -0400, Stephen Frost wrote: > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > > This caught my attention because a comment says "encryption does not > > support WAL-skipped relations", but there's no direct change to the > > definition of RelFileNodeSkippingWA

Re: Key management with tests

On Thu, Mar 18, 2021 at 02:37:43PM -0300, Álvaro Herrera wrote: > On 2021-Mar-18, Stephen Frost wrote: > > This is discussed in src/backend/access/transam/README, specifically the > > section that talks about Skipping WAL for New RelFileNode. Basically, > > it's the 'wal_level=minimal' optimizatio

Re: New IndexAM API controlling index vacuum strategies

On Thu, Mar 18, 2021 at 3:32 AM Masahiko Sawada wrote: > If we have the constant threshold of 1 billion transactions, a vacuum > operation might not be an anti-wraparound vacuum and even not be an > aggressive vacuum, depending on autovacuum_freeze_max_age value. Given > the purpose of skipping in

Re: Perform COPY FROM encoding conversions in larger chunks

On Thu, Mar 18, 2021 at 2:05 PM John Naylor wrote: > > I wrote: > > > I went ahead and rebased these. > > It looks like FreeBSD doesn't like this for some reason. On closer examination, make check was "terminated", not that the tests failed... -- John Naylor EDB: http://www.enterprisedb.com

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

On Thu, Mar 18, 2021 at 09:47:29AM -0400, Bruce Momjian wrote: > On Thu, Mar 18, 2021 at 07:29:56AM +0800, Julien Rouhaud wrote: > > On Wed, Mar 17, 2021 at 06:32:16PM -0400, Bruce Momjian wrote: > > > OK, is that what everyone wants? I think that is what the patch already > > > does. > > > > Not

Re: Perform COPY FROM encoding conversions in larger chunks

I wrote: > I went ahead and rebased these. It looks like FreeBSD doesn't like this for some reason. I also wanted to see if this patch set had any performance effect, with and without changing how UTF-8 is validated, using the blackhole am from https://github.com/michaelpq/pg_plugins/tree/master

Re: cleanup temporary files after crash

Hmm, crake and florican seem to have failed because of this commit, with this error in the new TAP test: error running SQL: 'psql::1: ERROR: could not open directory "base/pgsql_tmp": No such file or directory' while running 'psql -XAtq -d port=64336 host=/tmp/sv1WjSvj3P dbname='postgres' -f - -

Re: Key management with tests

Greetings, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > On 2021-Mar-18, Stephen Frost wrote: > > > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > > > Patch 10 uses the term "WAL-skip relations". What does that mean? Is > > > it "relations that are not WAL-logged"? I suppose we alre

Re: Key management with tests

On 2021-Mar-18, Stephen Frost wrote: > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > > Patch 10 uses the term "WAL-skip relations". What does that mean? Is > > it "relations that are not WAL-logged"? I suppose we already have a > > term for this; I'm not sure it's a good idea to invent a

Re: GROUP BY DISTINCT

On 3/16/21 3:52 PM, Tomas Vondra wrote: > > > On 3/16/21 9:21 AM, Vik Fearing wrote: >> On 3/13/21 12:33 AM, Tomas Vondra wrote: >>> Hi Vik, >>> >>> The patch seems quite ready, I have just two comments. >> >> Thanks for taking a look. >> >>> 1) Shouldn't this add another for DISTINCT, somewhere

Re: Key management with tests

Greetings, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > Patch 10 uses the term "WAL-skip relations". What does that mean? Is > it "relations that are not WAL-logged"? I suppose we already have a > term for this; I'm not sure it's a good idea to invent a different term > that is only used

Re: Key management with tests

Patch 10 uses the term "WAL-skip relations". What does that mean? Is it "relations that are not WAL-logged"? I suppose we already have a term for this; I'm not sure it's a good idea to invent a different term that is only used in this new place. -- Álvaro Herrera39°

Re: Key management with tests

On Thu, Mar 18, 2021 at 11:31:34AM -0400, Stephen Frost wrote: > Greetings, > > * Bruce Momjian (br...@momjian.us) wrote: > > On Thu, Mar 11, 2021 at 10:31:28PM -0500, Bruce Momjian wrote: > > > I have made significant progress on the cluster file encryption feature so > > > it is time for me to p

Re: fdatasync performance problem with large number of DB files

On 2021/03/18 23:03, Bruce Momjian wrote: Are we sure we want to use the word "crash" here? I don't remember seeing it used anywhere else in our user interface. We have GUC restart_after_crash. I guess it is "crash recovery". Maybe call it "recovery_sync_method" +1. This name sounds

Re: Disable WAL logging to speed up data loading

On 1/17/21 12:16 AM, tsunakawa.ta...@fujitsu.com wrote: From: Osumi, Takamichi/大墨 昂道 I updated my patch to take in those feedbacks ! Have a look at the latest patch. Looks good to me (the status remains ready for committer.) After reading through the thread (but not reading the patch) I am

Re: cleanup temporary files after crash

On 3/17/21 2:34 AM, Euler Taveira wrote: > On Sun, Mar 14, 2021, at 11:01 PM, Thomas Munro wrote: >> On Wed, Mar 10, 2021 at 1:31 AM Michael Paquier > > wrote: >> > On Tue, Mar 09, 2021 at 02:28:43AM +0100, Tomas Vondra wrote: >> > > Let's move this patch forward. Bas

Re: invalid data in file backup_label problem on windows

On 1/14/21 10:50 PM, Wang, Shenhao wrote: Please feel free to, under the section "Bug fixes". This way, it won't get lost in the traffic of this list. -- Michael Thank you for your advise, added it I'm not sure how I feel about this patch (not really a Windows person) but I do think that

Re: a verbose option for autovacuum

On Thu, Mar 18, 2021 at 5:14 AM Masahiko Sawada wrote: > Okay, I've updated the patch accordingly. If we add > IndexBulkDeleteResult to LVRelStats I think we can remove > IndexBulkDeleteResult function argument also from some other functions > such as lazy_parallel_vacuum_indexes() and vacuum_inde

Re: Implement for window functions

On 3/18/21 12:03 PM, Vik Fearing wrote: On 3/18/21 4:12 PM, David Steele wrote: Hi Vik, On 1/11/21 5:00 PM, Tom Lane wrote: I started to look through this patch... I see you moved this patch to PG15. If you won't be working on the patch in this CF Correct. I won't be working on this again

Re: Implement for window functions

On 3/18/21 4:12 PM, David Steele wrote: > Hi Vik, > > On 1/11/21 5:00 PM, Tom Lane wrote: >> I started to look through this patch... > > I see you moved this patch to PG15. If you won't be working on the patch > in this CF Correct. I won't be working on this again until I finish my review of th

Re: Rename of triggers for partitioned tables

On 1/15/21 5:26 PM, Alvaro Herrera wrote: On 2020-Nov-27, Arne Roland wrote: I got too annoyed at building queries for gexec all the time. So wrote a patch to fix the issue that the rename of partitioned trigger doesn't affect children. As you say, triggers on children don't necessarily have

Re: pg_stat_statements and "IN" conditions

> On Thu, Mar 18, 2021 at 09:38:09AM -0400, David Steele wrote: > On 1/5/21 10:51 AM, Zhihong Yu wrote: > > > > +   int         lastExprLenght = 0; > > > > Did you mean to name the variable lastExprLenghth ? > > > > w.r.t. extracting to helper method, the second and third > > if (currentExprIdx ==

Re: Reduce the time required for a database recovery from archive.

On 3/18/21 11:37 AM, Andrey Borodin wrote: 18 марта 2021 г., в 20:04, David Steele написал(а): it would be nice to support an interface that simply says to the restore_command, "go get 1gb of WAL and write the files here." +1 to redesigning restore_command and archive_command. Indeed, ar

Re: Reduce the time required for a database recovery from archive.

> 18 марта 2021 г., в 20:04, David Steele написал(а): > it would be nice to support an interface that simply says to the > restore_command, "go get 1gb of WAL and write the files here." +1 to redesigning restore_command and archive_command. Best regards, Andrey Borodin.

Re: [patch] [doc] Further note required activity aspect of automatic checkpoint and archving

Hi David, On 1/15/21 2:50 PM, David G. Johnston wrote: If the above wants to be made more explicit in this change maybe: "This is mitigated by the fact that archiving, and thus filling, the active WAL segment will not happen if that segment is empty; it will continue as the active segment."

Re: Key management with tests

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Mar 11, 2021 at 10:31:28PM -0500, Bruce Momjian wrote: > > I have made significant progress on the cluster file encryption feature so > > it is time for me to post a new set of patches. > > Here is a rebase, to keep the cfbot green.

Re: should INSERT SELECT use a BulkInsertState?

Hi, + mtstate->ntuples > bulk_insert_ntuples && + bulk_insert_ntuples >= 0) I wonder why bulk_insert_ntuples == 0 is included in the above. It seems bulk_insert_ntuples having value of 0 should mean not enabling bulk insertions. + } + else + { nit: the else should be on

  1   2   >