Re: segmentation fault using currtid and partitioned tables

On Mon, 25 May 2020 at 22:01, Michael Paquier wrote: > > On Mon, May 25, 2020 at 06:29:10PM +0900, Michael Paquier wrote: > > Perhaps you are right though, and that we don't need to spend this > > much energy into improving the error messages so I am fine to discard > > this part. At the end, in

Re: Default gucs for EXPLAIN

On Tuesday, May 26, 2020, David Rowley wrote: > On Tue, 26 May 2020 at 23:59, Vik Fearing wrote: > > Are you saying we should have all new EXPLAIN options off forever into > > the future because apps won't know about the new data? I guess we > > should also not ever introduce new plan nodes

Re: Default gucs for EXPLAIN

On Tue, 26 May 2020 at 23:59, Vik Fearing wrote: > Are you saying we should have all new EXPLAIN options off forever into > the future because apps won't know about the new data? I guess we > should also not ever introduce new plan nodes because those won't be > known either. Another argument

Re: Why don't you to document pg_shmem_allocations view's name list?

On 2020-05-26 11:08, Michael Paquier wrote: On Tue, May 26, 2020 at 10:16:19AM +0900, Masahiro Ikeda wrote: I think it is more useful if the name list of the pg_shmem_allocations view is listed in one page. Why don't you document pg_shmem_allocations view's name list? Documenting that would

Re: max_slot_wal_keep_size comment in postgresql.conf

On Tue, 26 May 2020 at 21:46, Kyotaro Horiguchi wrote: > At Tue, 26 May 2020 09:10:40 -0400, Jeff Janes > wrote in > > In postgresql.conf, it says: > > > > #max_slot_wal_keep_size = -1 # measured in bytes; -1 disables > > > > I don't know if that is describing the dimension of this parameter

Re: some grammar refactoring

Robert Haas writes: > On Tue, May 26, 2020 at 4:28 AM Peter Eisentraut > wrote: >> Most utility commands don't have an intermediate parse analysis pass. >> They just go straight from the grammar to the execution. Maybe that >> could be rethought, but that's the way it is now. > I think it can

Re: hash join error improvement (old)

On Wed, May 27, 2020 at 1:30 PM Tom Lane wrote: > Alvaro Herrera writes: > > There are more uses of BufFileRead that don't bother to distinguish > > these two cases apart, though -- logtape.c, tuplestore.c, > > gistbuildbuffers.c all do the same. > > Yeah. I rather suspect that callers of

Re: max_slot_wal_keep_size comment in postgresql.conf

At Tue, 26 May 2020 09:10:40 -0400, Jeff Janes wrote in > In postgresql.conf, it says: > > #max_slot_wal_keep_size = -1 # measured in bytes; -1 disables > > I don't know if that is describing the dimension of this parameter or the > units of it, but the default units for it are megabytes, not

Re: Trouble with hashagg spill I/O pattern and costing

On Tue, May 26, 2020 at 5:40 PM Jeff Davis wrote: > On Tue, 2020-05-26 at 21:15 +0200, Tomas Vondra wrote: > > > > As for the tlist fix, I think that's mostly ready too - the one thing > > we > > should do is probably only doing it for AGG_HASHED. For AGG_SORTED > > it's > > not really

Re: hash join error improvement (old)

Alvaro Herrera writes: > There are more uses of BufFileRead that don't bother to distinguish > these two cases apart, though -- logtape.c, tuplestore.c, > gistbuildbuffers.c all do the same. Yeah. I rather suspect that callers of BufFileRead/Write are mostly expecting that those functions will

Re: Remove page-read callback from XLogReaderState.

Thank you for the comment. At Tue, 26 May 2020 20:17:47 +0800, Craig Ringer wrote in > On Tue, 26 May 2020, 15:40 Kyotaro Horiguchi, > wrote: > > > > > This patch removes all the three callbacks (open/close/page_read) in > > XL_ROUTINE from XLogReaderState. It only has "cleanup" callback >

Re: Trouble with hashagg spill I/O pattern and costing

On Tue, 2020-05-26 at 21:15 +0200, Tomas Vondra wrote: > Yeah. I agree prefetching is definitely out of v13 scope. It might be > interesting to try how useful would it be, if you're willing to spend > some time on a prototype. I think a POC would be pretty quick; I'll see if I can hack something

Re: Default gucs for EXPLAIN

On Tue, May 26, 2020 at 4:53 PM David Rowley wrote: > If we add > a new executor node then that's something that the server will send to > the client. The client does not need knowledge about which version of > PostreSQL it is connected to. If it receives details about some new > node type in

Re: Default gucs for EXPLAIN

On Tue, May 26, 2020 at 4:30 AM David Rowley wrote: > > I imagine the > authors of those applications might get upset if we create something > outside of the command that controls what the command does. Perhaps > the idea here is not quite as bad as that as applications could still > override

Re: New 'pg' consolidated metacommand patch

On Tue, May 26, 2020 at 4:19 PM Mark Dilger wrote: > I'd also appreciate +1 and -1 votes on the overall idea, in case this > entire feature, regardless of implementation, is simply something the > community does not want. > -1, at least as part of core. My question would be how much of this is

Re: Default gucs for EXPLAIN

On Tue, 26 May 2020 at 23:59, Vik Fearing wrote: > > On 5/26/20 1:30 PM, David Rowley wrote: > > On Tue, 26 May 2020 at 13:36, Bruce Momjian wrote: > >> > >> On Sat, May 23, 2020 at 06:16:25PM +, Nikolay Samokhvalov wrote: > >>> This is a very good improvement! Using information about

Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond.

You can use the attached sql to reproduce this issue, but I'm not sure you can get the above result at the first time that is because when optimizer think the 2 index scan have the same cost, it will choose the first one it found, the order depends on RelationGetIndexList. If so, you may try

Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond.

On Tue, May 26, 2020 at 9:59 PM Ashutosh Bapat wrote: > On Tue, May 26, 2020 at 1:52 PM Andy Fan wrote: > > > > > > Consider the below example: > > > > create table j1(i int, im5 int, im100 int, im1000 int); > > insert into j1 select i, i%5, i%100, i%1000 from generate_series(1, > 1000)i;

Re: hash join error improvement (old)

On 2020-May-26, Tom Lane wrote: > Are you sure you correctly identified the source of the bogus error > report? This version's better. It doesn't touch the write side at all. On the read side, only report a short read as such if errno's not set. This error isn't frequently seen. This page

Re: Default gucs for EXPLAIN

On 5/26/20 10:08 PM, Justin Pryzby wrote: > If you want to change the default, I think that should be a separate > patch/thread. Yes, it will be. -- Vik Fearing

Re: Default gucs for EXPLAIN

On Sat, May 23, 2020 at 06:33:48PM +0200, Vik Fearing wrote: > > Do we really want default_explain_analyze ? > > It sounds like bad news that EXPLAIN DELETE might or might not remove rows > > depending on the state of a variable. > > I have had sessions where not using ANALYZE was the exception,

Re: some grammar refactoring

On Tue, May 26, 2020 at 4:28 AM Peter Eisentraut wrote: > On 2020-05-25 21:09, Mark Dilger wrote: > > I don't think it moves the needle too much, either. But since your patch > > is entirely a refactoring patch and not a feature patch, I thought it would > > be fair to ask larger questions

Re: hash join error improvement (old)

On 2020-May-26, Tom Lane wrote: > Digging further down, it looks like BufFileWrite calls BufFileDumpBuffer > which calls FileWrite which takes pains to set errno correctly after a > short write --- so other than the lack of commentary about these > functions' error-reporting API, I don't think

Re: Trouble with hashagg spill I/O pattern and costing

On Tue, May 26, 2020 at 11:40:07AM -0700, Jeff Davis wrote: On Tue, 2020-05-26 at 16:15 +0200, Tomas Vondra wrote: I'm not familiar with logtape internals but IIRC the blocks are linked by each block having a pointer to the prev/next block, which means we can't prefetch more than one block

Re: Trouble with hashagg spill I/O pattern and costing

On Tue, 2020-05-26 at 16:15 +0200, Tomas Vondra wrote: > I'm not familiar with logtape internals but IIRC the blocks are > linked > by each block having a pointer to the prev/next block, which means we > can't prefetch more than one block ahead I think. But maybe I'm > wrong, > or maybe fetching

PG_CRON logging

Hi, Is there way to insert the cron job execution status to a table? Or any other method to identify the job status without checking the log file? *Regards,* *Rajin *

Re: race condition when writing pg_control

On 5/21/20, 9:52 PM, "Thomas Munro" wrote: > Here's a version with a commit message added. I'll push this to all > releases in a day or two if there are no objections. Looks good to me. Thanks! Nathan

Re: Default gucs for EXPLAIN

Le mar. 26 mai 2020 à 16:25, Stephen Frost a écrit : > Greetings, > > * Guillaume Lelarge (guilla...@lelarge.info) wrote: > > Le mar. 26 mai 2020 à 04:27, Stephen Frost a écrit > : > > > To that end- what if this was done client-side with '\explain' or > > > similar? Basically, it'd work like

Re: hash join error improvement (old)

Alvaro Herrera writes: > Hmm, right -- I was extending the partial read case to apply to a > partial write, and we deal with those very differently. I changed the > write case to use our standard approach. Actually ... looking more closely, this proposed change in ExecHashJoinSaveTuple flat out

Re: Default gucs for EXPLAIN

Greetings, * Pavel Stehule (pavel.steh...@gmail.com) wrote: > the partial solution can be custom psql statements. Now, it can be just > workaround > > \set explain 'explain (analyze, buffers)' > :explain select * from pg_class ; > > and anybody can prepare customized statements how he likes

Re: Default gucs for EXPLAIN

Greetings, * David G. Johnston (david.g.johns...@gmail.com) wrote: > On Monday, May 25, 2020, Stephen Frost wrote: > > * Michael Paquier (mich...@paquier.xyz) wrote: > > > On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote: > > > > I am not excited about this new feature. Why do it

Re: Default gucs for EXPLAIN

Greetings, * Guillaume Lelarge (guilla...@lelarge.info) wrote: > Le mar. 26 mai 2020 à 04:27, Stephen Frost a écrit : > > To that end- what if this was done client-side with '\explain' or > > similar? Basically, it'd work like \watch or \g but we'd have options > > under pset like

Re: what can go in root.crt ?

On 05/26/20 09:35, Andrew Dunstan wrote: > The trouble is I think you have it the wrong way round. It makes sense > to give less trust to a non-root CA than to one of its up-chain > authorities, e.g. only trust it for certain domains, or for a lesser > period of time. But it doesn't seem to make

Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond.

On Tue, May 26, 2020 at 1:52 PM Andy Fan wrote: > > > Consider the below example: > > create table j1(i int, im5 int, im100 int, im1000 int); > insert into j1 select i, i%5, i%100, i%1000 from generate_series(1, > 1000)i; > create index j1_i_im5 on j1(i, im5); > create index j1_i_im100 on

Re: hash join error improvement (old)

Hi Tom, thanks for looking. On 2020-May-25, Tom Lane wrote: > I don't mind if you want to extend that paradigm to also use "wrote only > %d bytes" wording, but the important point is to get the SQLSTATE set on > the basis of ENOSPC rather than whatever random value errno will have > otherwise.

Re: what can go in root.crt ?

On 5/25/20 3:32 PM, Chapman Flack wrote: > On 05/25/20 15:15, Chapman Flack wrote: >> Does that mean it also would fail if I directly put the server's >> end-entity cert there? >> >> Would I have to put all three of WE ISSUE TO ORGS LIKE YOURS, >> WE ISSUE TO LOTS, and WE ISSUE TO EVERYBODY in

Re: what can go in root.crt ?

On 05/26/20 02:05, Craig Ringer wrote: > The main reason to put intermediate certificates in the root.crt is that it > allows PostgreSQL to supply the whole certificate chain to a client during Hold on a sec; you're not talking about what I'm talking about, yet. Yes, you have make the chain

Re: Default gucs for EXPLAIN

út 26. 5. 2020 v 4:27 odesílatel Stephen Frost napsal: > Greetings, > > * Michael Paquier (mich...@paquier.xyz) wrote: > > On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote: > > > I am not excited about this new feature. Why do it only for EXPLAIN? > > Would probably help to

max_slot_wal_keep_size comment in postgresql.conf

In postgresql.conf, it says: #max_slot_wal_keep_size = -1 # measured in bytes; -1 disables I don't know if that is describing the dimension of this parameter or the units of it, but the default units for it are megabytes, not individual bytes, so I think it is pretty confusing. Cheers, Jeff

Re: Two fsync related performance issues?

On Tue, 12 May 2020, 08:42 Paul Guo, wrote: > Hello hackers, > > 1. StartupXLOG() does fsync on the whole data directory early in the crash > recovery. I'm wondering if we could skip some directories (at least the > pg_log/, table directories) since wal, etc could ensure consistency. Here > is

Re: Remove page-read callback from XLogReaderState.

On Tue, 26 May 2020, 15:40 Kyotaro Horiguchi, wrote: > > This patch removes all the three callbacks (open/close/page_read) in > XL_ROUTINE from XLogReaderState. It only has "cleanup" callback > instead. > I actually have a use in mind for these callbacks - to support reading WAL for logical

Re: Add A Glossary

On 2020-04-29 21:55, Corey Huinker wrote: On Wed, Apr 29, 2020 at 3:15 PM Peter Eisentraut > wrote: Why are all the glossary terms capitalized?  Seems kind of strange. They weren't intended to be, and they don't appear to be in the page I'm

Re: Default gucs for EXPLAIN

On 5/26/20 1:30 PM, David Rowley wrote: > On Tue, 26 May 2020 at 13:36, Bruce Momjian wrote: >> >> On Sat, May 23, 2020 at 06:16:25PM +, Nikolay Samokhvalov wrote: >>> This is a very good improvement! Using information about buffers is my >>> favorite >>> way to optimize queries. >>> >>> Not

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, May 22, 2020 at 9:51 PM Fujii Masao wrote: > > > On 2020/05/22 15:10, Andy Fan wrote: > > > > > > On Thu, May 21, 2020 at 3:49 PM Julien Rouhaud > wrote: > > > > Le jeu. 21 mai 2020 à 09:17, Michael Paquier > a écrit : > > > >

Re: Default gucs for EXPLAIN

On Tue, 26 May 2020 at 13:36, Bruce Momjian wrote: > > On Sat, May 23, 2020 at 06:16:25PM +, Nikolay Samokhvalov wrote: > > This is a very good improvement! Using information about buffers is my > > favorite > > way to optimize queries. > > > > Not having BUFFERS enabled by default means

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, May 26, 2020 at 2:44 PM Dilip Kumar wrote: > > On Tue, May 26, 2020 at 10:27 AM Amit Kapila wrote: > > > > > > > > 2. There is a bug fix in handling the stream abort in 0008 (earlier it > > > was 0006). > > > > > > > The code changes look fine but it is not clear what was the exact > >

Re: New Feature Request

On 2020-05-26 12:10, Bert Scalzo wrote: So far QIKR shows about a 2.5X improvement over the PostgreSQL optimizer when fed bad SQL. I am not saying the PotsgrSQL optimizer does a poor job, but rather that QIKR was designed for "garbage in, not garbage out" - so QIKR fixes all the stupid

Re: New Feature Request

I greatly appreciate all the replies. Thanks. I also fully understand and appreciate all the points made - especially that this idea may not have general value or acceptance as worthwhile. No argument from me. Let me explain why I am looking to do this to see if that changes any opinions. I have

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, May 25, 2020 at 8:07 PM Dilip Kumar wrote: > > On Fri, May 22, 2020 at 11:54 AM Amit Kapila wrote: > > > > 4. > > + * XXX Do we need to allocate it in TopMemoryContext? > > + */ > > +static void > > +subxact_info_add(TransactionId xid) > > { > > .. > > > > For this and other places in a

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, May 26, 2020 at 10:27 AM Amit Kapila wrote: > > On Fri, May 22, 2020 at 6:21 PM Dilip Kumar wrote: > > > > On Mon, May 18, 2020 at 5:57 PM Amit Kapila wrote: > > > > > > > > > Few comments on v20-0010-Bugfix-handling-of-incomplete-toast-tuple > > > 1. > > > + /* > > > + * If this is a

Re: some grammar refactoring

On 2020-05-25 21:09, Mark Dilger wrote: I don't think it moves the needle too much, either. But since your patch is entirely a refactoring patch and not a feature patch, I thought it would be fair to ask larger questions about how the code should be structured. I like using enums and switch

Re: password_encryption default

On 2020-05-25 17:57, Jonathan S. Katz wrote: I took a look over, it looks good. One question on the initdb.c diff: - if (strcmp(authmethodlocal, "scram-sha-256") == 0 || - strcmp(authmethodhost, "scram-sha-256") == 0) - { - conflines =

Make the qual cost on index Filter slightly higher than qual cost on index Cond.

Consider the below example: create table j1(i int, im5 int, im100 int, im1000 int); insert into j1 select i, i%5, i%100, i%1000 from generate_series(1, 1000)i; create index j1_i_im5 on j1(i, im5); create index j1_i_im100 on j1(i, im100); analyze j1; explain select * from j1 where i = 100 and

Re: SyncRepGetSyncStandbysPriority() vs. SIGHUP

On Wed, Feb 05, 2020 at 11:45:52PM -0800, Noah Misch wrote: > Would anyone like to fix this? I could add it to my queue, but it would wait > a year or more. Commit f332241 fixed this.

Re: Remove page-read callback from XLogReaderState.

At Wed, 22 Apr 2020 10:12:46 +0900 (JST), Kyotaro Horiguchi wrote in > cd12323440 conflicts with this. Rebased. b060dbe000 is conflicting. I gave up isolating XLogOpenSegment from xlogreader.c, since the two are tightly coupled than I thought. This patch removes all the three callbacks

Re: New Feature Request

On 26.05.2020 04:47, Tomas Vondra wrote: On Mon, May 25, 2020 at 09:21:26PM -0400, Bruce Momjian wrote: On Mon, May 25, 2020 at 07:53:40PM -0500, Bert Scalzo wrote: I am reposting this from a few months back (see below). I am not trying to be a pest, just very motivated. I really think this

Re: Default gucs for EXPLAIN

On Monday, May 25, 2020, Stephen Frost wrote: > Greetings, > > * Michael Paquier (mich...@paquier.xyz) wrote: > > On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote: > > > I am not excited about this new feature. Why do it only for EXPLAIN? > > Would probably help to understand what

Re: Default gucs for EXPLAIN

On Saturday, May 23, 2020, Vik Fearing wrote: > > > > Do we really want default_explain_analyze ? > > It sounds like bad news that EXPLAIN DELETE might or might not remove > rows > > depending on the state of a variable. > > I have had sessions where not using ANALYZE was the exception, not the >

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Fri, May 22, 2020 at 6:22 PM Dilip Kumar wrote: > > On Mon, May 18, 2020 at 4:10 PM Amit Kapila wrote: > > > > On Sun, May 17, 2020 at 12:41 PM Dilip Kumar wrote: > > > > > > On Fri, May 15, 2020 at 4:04 PM Amit Kapila > > > wrote: > > > > > > > > > > > > Review comments: > > > >

Re: Default gucs for EXPLAIN

Le mar. 26 mai 2020 à 04:27, Stephen Frost a écrit : > Greetings, > > * Michael Paquier (mich...@paquier.xyz) wrote: > > On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote: > > > I am not excited about this new feature. Why do it only for EXPLAIN? > > Would probably help to

Re: what can go in root.crt ?

On Tue, 26 May 2020 at 11:43, Chapman Flack wrote: > On 05/25/20 23:22, Laurenz Albe wrote: > > I don't know if there is a way to get this to work, but the > > fundamental problem seems that you have got the system wrong. > > > > If you don't trust WE ISSUE TO EVERYBODY, then you shouldn't use >