Re: cleaning perl code

On 4/9/20 2:26 PM, Peter Eisentraut wrote: > On 2020-04-09 19:47, Robert Haas wrote: >> On Thu, Apr 9, 2020 at 11:44 AM Andrew Dunstan >> wrote: >>> We currently only run perlcritic at severity level 5, which is fairly >>> permissive. I'd like to reduce that, ideally to, say, level 3, which is

Re: Default setting for enable_hashagg_disk

On Thu, Apr 9, 2020 at 7:49 AM Tomas Vondra wrote: > It it really any different from our enable_* GUCs? Even if you do e.g. > enable_sort=off, we may still do a sort. Same for enable_groupagg etc. I think it's actually pretty different. All of the other enable_* GUCs disable an entire type of

Re: where should I stick that backup?

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > I think we need to step back and look at the larger issue. The real > argument goes back to the Unix command-line API vs the VMS/Windows API. > The former has discrete parts that can be stitched together, while the > VMS/Windows API

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

On Thu, Apr 9, 2020 at 3:05 PM Peter Geoghegan wrote: > > On Wed, Apr 8, 2020 at 10:56 PM Masahiko Sawada > wrote: > > Here is the reproducer: > > What version of Postgres did you notice the actual customer issue on? > I ask because I wonder if the work on B-Tree indexes in Postgres 12 > affects

Re: Parallel copy

Hi, On April 9, 2020 4:01:43 AM PDT, Amit Kapila wrote: >On Thu, Apr 9, 2020 at 3:55 AM Ants Aasma wrote: >> >> On Wed, 8 Apr 2020 at 22:30, Robert Haas >wrote: >> >> > - The portion of the time that is used to split the lines is not >> > easily parallelizable. That seems to be a fairly small

Re: Parallel copy

On Thu, Apr 9, 2020 at 2:55 PM Andres Freund wrote: > I'm fairly certain that we do *not* want to distribute input data between > processes on a single tuple basis. Probably not even below a few hundred kb. > If there's any sort of natural clustering in the loaded data - extremely > common,

Re: Parallel copy

Hi, On April 9, 2020 12:29:09 PM PDT, Robert Haas wrote: >On Thu, Apr 9, 2020 at 2:55 PM Andres Freund >wrote: >> I'm fairly certain that we do *not* want to distribute input data >between processes on a single tuple basis. Probably not even below a >few hundred kb. If there's any sort of

Re: Default setting for enable_hashagg_disk

On Thu, 2020-04-09 at 15:26 -0400, Robert Haas wrote: > I think it's actually pretty different. All of the other enable_* > GUCs > disable an entire type of plan node, except for cases where that > would > otherwise result in planning failure. This just disables a portion of > the planning logic

Re: debian bugrept involving fast default crash in pg11.7

On Thu, Apr 09, 2020 at 02:36:26PM -0400, Tim Bishop wrote: > SELECT attrelid::regclass, * FROM pg_attribute WHERE atthasmissing; > -[ RECORD 1 ]-+- > attrelid | download > attrelid | 22749 > attname | filetype But that table isn't involved in the crashing query, right ?

Re: Catalog invalidations vs catalog scans vs ScanPgRelation()

[ belatedly responding ] On Sat, Feb 29, 2020 at 3:17 PM Andres Freund wrote: > My preliminary conclusion is that it's simply not safe to do > SnapshotResetXmin() from within InvalidateCatalogSnapshot(), > PopActiveSnapshot(), UnregisterSnapshotFromOwner() etc. Instead we need > to defer the

Re: Default setting for enable_hashagg_disk

On Thu, Apr 09, 2020 at 01:48:55PM +0200, Tomas Vondra wrote: > On Tue, Apr 07, 2020 at 05:39:01PM -0500, Justin Pryzby wrote: > > On Tue, Apr 07, 2020 at 11:20:46AM -0700, Jeff Davis wrote: > > > The enable_hashagg_disk GUC, if set to true, chooses HashAgg based on > > > costing. If false, it

Re: Default setting for enable_hashagg_disk

On Thu, 2020-04-09 at 12:24 -0500, Justin Pryzby wrote: > Also.. there's no such thing as enable_groupagg? Unless I've been > missing out > on something. I thought about adding that, and went so far as to make a patch. But it didn't seem right to me -- the grouping isn't what takes the time,

Re: more ALTER .. DEPENDS ON EXTENSION fixes

On 2020-Mar-11, Tom Lane wrote: > > thanks for it) to backbranches or just to master. It seems legitimate > > to see it as a feature addition, but OTOH the overall feature is not > > complete without it ... > > 0003 is the command addition to allow removing such a dependency, > right? Given

Re: where should I stick that backup?

On Mon, Apr 6, 2020 at 07:32:45PM +0200, Magnus Hagander wrote: > On Mon, Apr 6, 2020 at 4:45 PM Stephen Frost wrote: > > For my 2c, at least, introducing more shell commands into critical parts > > of the system is absolutely the wrong direction to go in. > > archive_command continues to be a

Re: debian bugrept involving fast default crash in pg11.7

I've attached a file containing the \d+ for all the tables involved and the EXPLAIN ANALYZE for the query. Yes, the crash happened under v11.6. I had tried downgrading when I first encountered the problem. While trying to put together this information the crash started happening less

Re: debian bugrept involving fast default crash in pg11.7

SELECT attrelid::regclass, * FROM pg_attribute WHERE atthasmissing; -[ RECORD 1 ]-+- attrelid | download attrelid | 22749 attname | filetype atttypid | 1043 attstattarget | -1 attlen| -1 attnum| 5 attndims | 0 attcacheoff | -1 atttypmod | 36

Re: Parallel copy

On Thu, Apr 9, 2020 at 7:49 AM Dilip Kumar wrote: > I agree that if the leader switches the role, then it is possible that > sometimes the leader might not produce the work before the queue is > empty. OTOH, the problem with the approach you are suggesting is that > the work will be generated

Re: [HACKERS] make async slave to wait for lsn to be replayed

On 2020-04-09 16:33, Tom Lane wrote: Fujii Masao writes: On 2020/04/09 16:11, Kyotaro Horiguchi wrote: At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane wrote in Why is this getting grafted onto BEGIN/START TRANSACTION in the first place? The rationale for not being a fmgr function is stated

Re: cleaning perl code

On Thu, Apr 9, 2020 at 11:44 AM Andrew Dunstan wrote: > We currently only run perlcritic at severity level 5, which is fairly > permissive. I'd like to reduce that, ideally to, say, level 3, which is > what I use for the buildfarm code. > > But let's start by going to severity level 4. I

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

On 2020-Apr-09, Masahiko Sawada wrote: > The inner test in the comment "found the item" never tests the item > for being dead. So maybe we can add !ItemIdIsDead(iid) to that > condition. But there still is a race condition of recording multiple > FPIs can happen. Maybe a better solution is to

Re: debian bugrept involving fast default crash in pg11.7

On Thu, Apr 09, 2020 at 02:05:22PM -0400, Tim Bishop wrote: > I've attached a file containing the \d+ for all the tables involved and the > EXPLAIN ANALYZE for the query. Thanks for your response. Do you know if you used the "fast default feature" ? That would happen if you did "ALTER TABLE tbl

Re: BUG #16345: ts_headline does not find phrase matches correctly

redirected to hackers. On Wed, Apr 8, 2020 at 11:02 PM Tom Lane wrote: > > In short then, I propose applying 0001-0006. I'm not quite sure > if we should back-patch, or just be content to fix this in HEAD. > But there's definitely an argument that this has been broken since > we added phrase

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

On Wed, Apr 8, 2020 at 10:56 PM Masahiko Sawada wrote: > Here is the reproducer: What version of Postgres did you notice the actual customer issue on? I ask because I wonder if the work on B-Tree indexes in Postgres 12 affects the precise behavior you get here with real world workloads. It

Re: BUG #16345: ts_headline does not find phrase matches correctly

Jeff Janes writes: > I am getting a compiler warning, both with and without --enable-cassert. > wparser_def.c: In function 'prsd_headline': > wparser_def.c:2530:2: warning: 'pose' may be used uninitialized in this > function [-Wmaybe-uninitialized] > mark_fragment(prs, highlightall, bestb,

Re: cleaning perl code

On 2020-04-09 19:47, Robert Haas wrote: On Thu, Apr 9, 2020 at 11:44 AM Andrew Dunstan wrote: We currently only run perlcritic at severity level 5, which is fairly permissive. I'd like to reduce that, ideally to, say, level 3, which is what I use for the buildfarm code. But let's start by

Re: pgsql: Rationalize GetWalRcv{Write,Flush}RecPtr().

On 2020-Apr-08, Thomas Munro wrote: > Rationalize GetWalRcv{Write,Flush}RecPtr(). > > GetWalRcvWriteRecPtr() previously reported the latest *flushed* > location. Adopt the conventional terminology used elsewhere in the tree > by renaming it to GetWalRcvFlushRecPtr(), and likewise for some

Re: more ALTER .. DEPENDS ON EXTENSION fixes

On 2020-Mar-11, Tom Lane wrote: > BTW, I did not like the syntax too much. "NO DEPENDS ON EXTENSION" > doesn't seem like good English. "NOT DEPENDS ON EXTENSION" is hardly > any better. The real problem with both is that an ALTER action should > be, well, an action. A grammar stickler would

Re: more ALTER .. DEPENDS ON EXTENSION fixes

As promised, here's a rebased version of this patch -- edits pending per discussion to decide the grammar to use. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From 5df1613901906cff4d0b0b7e480691b65d9d2e5c Mon

Re: doc review for v13

On Wed, Apr 08, 2020 at 11:56:53AM -0500, Justin Pryzby wrote: > I previously mailed separately about a few individual patches, some of which > have separate, ongoing discussion and aren't included here (incr sort, > parallel > vacuum). I have gone through your changes, and committed what looked

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

On Thu, Apr 9, 2020 at 1:37 PM James Coleman wrote: > We saw the issue on our PG11 clusters. The specific index we noticed > in the wal dump (I don't think we confirmed if there were others) as > one on a `created_at` column, to give you an idea of cardinality. You tend to get a lot of problems

Re: Catalog invalidations vs catalog scans vs ScanPgRelation()

Hi, On 2020-04-09 18:52:32 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2020-04-09 16:56:03 -0400, Robert Haas wrote: > >> That seems like a fairly magical coding rule that will happen to work > >> in most practical cases but isn't really a principled approach to the > >> problem. > >

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

On Thu, Apr 9, 2020 at 6:47 PM James Coleman wrote: > I believe the write pattern to this table likely looks like: > - INSERT > - UPDATE > - DELETE > for every row. But tomorrow I can do some more digging if needed. The pg_stats.null_frac for the column/index might be interesting here. I believe

Re: [HACKERS] Restricting maximum keep segments by repslots

At Wed, 08 Apr 2020 14:19:56 +0900 (JST), Kyotaro Horiguchi wrote in me> Just avoiding starting replication when restart_lsn is invalid is me> sufficient (the attached, which is equivalent to a part of what the me> invalidated flag did). I thing that the error message needs a Hint but me> it

Re: Thoughts on "killed tuples" index hint bits support on standby

Hello, Peter. > Let me make sure I understand your position: > You're particularly concerned about cases where there are relatively > few page splits, and the standby has to wait for VACUUM to run on the > primary before dead index tuples get cleaned up. The primary itself > probably has no

Properly mark NULL returns in numeric aggregates

Hi hackers, We found that several functions -- namely numeric_combine, numeric_avg_combine, numeric_poly_combine, and int8_avg_combine -- are returning NULL without signaling the nullity of datum in fcinfo.isnull. This is obscured by the fact that the only functions in core (finalfunc for various

Re: [HACKERS] make async slave to wait for lsn to be replayed

On 2020/04/10 3:16, Alexey Kondratov wrote: On 2020-04-09 16:33, Tom Lane wrote: Fujii Masao writes: On 2020/04/09 16:11, Kyotaro Horiguchi wrote: At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane wrote in Why is this getting grafted onto BEGIN/START TRANSACTION in the first place? The

Re: [Patch] Use internal pthreads reimplementation only when building with MSVC

Hello, On 2020-Apr-08, Sandro Mani wrote: > The following patch, which we added to build mingw-postgresql on Fedora, > makes the internal minimal pthreads reimplementation only used when building > with MSVC, as on MINGW it causes symbol collisions with the symbols provided > my winpthreads.

Re: Catalog invalidations vs catalog scans vs ScanPgRelation()

Hi, On 2020-04-09 16:56:03 -0400, Robert Haas wrote: > [ belatedly responding ] > > On Sat, Feb 29, 2020 at 3:17 PM Andres Freund wrote: > > My preliminary conclusion is that it's simply not safe to do > > SnapshotResetXmin() from within InvalidateCatalogSnapshot(), > > PopActiveSnapshot(),

Re: where should I stick that backup?

On Thu, Apr 9, 2020 at 04:15:07PM -0400, Stephen Frost wrote: > Greetings, > > * Bruce Momjian (br...@momjian.us) wrote: > > I think we need to step back and look at the larger issue. The real > > argument goes back to the Unix command-line API vs the VMS/Windows API. > > The former has

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

On Thu, Apr 9, 2020 at 8:32 PM Peter Geoghegan wrote: > > On Thu, Apr 9, 2020 at 5:25 PM Peter Geoghegan wrote: > > Was this a low cardinality index in the way I describe? If it was, > > then we can hope (and maybe even verify) that the Postgres 12 work > > noticeably ameliorates the problem. >

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

On Fri, 10 Apr 2020 at 04:05, Peter Geoghegan wrote: > > On Wed, Apr 8, 2020 at 10:56 PM Masahiko Sawada > wrote: > > Here is the reproducer: > > What version of Postgres did you notice the actual customer issue on? > I ask because I wonder if the work on B-Tree indexes in Postgres 12 > affects

Re: Catalog invalidations vs catalog scans vs ScanPgRelation()

Andres Freund writes: > On 2020-04-09 16:56:03 -0400, Robert Haas wrote: >> That seems like a fairly magical coding rule that will happen to work >> in most practical cases but isn't really a principled approach to the >> problem. > I'm not sure it'd be that magical to only release resources at

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

On Thu, Apr 9, 2020 at 5:25 PM Peter Geoghegan wrote: > Was this a low cardinality index in the way I describe? If it was, > then we can hope (and maybe even verify) that the Postgres 12 work > noticeably ameliorates the problem. What I really meant was an index where hundreds or even thousands

Re: [BUG] non archived WAL removed during production crash recovery

By the way, I haven't noticed that Cc: didn't contain -hackers. Added it. At Thu, 9 Apr 2020 11:35:12 +0200, Jehan-Guillaume de Rorthais wrote in > On Thu, 09 Apr 2020 11:26:57 +0900 (JST) > Kyotaro Horiguchi wrote: > [...] > > > > At Thu, 2 Apr 2020 15:49:15 +0200, Jehan-Guillaume de

Re: doc review for v13

On Fri, Apr 10, 2020 at 11:27:46AM +0900, Michael Paquier wrote: > On Wed, Apr 08, 2020 at 11:56:53AM -0500, Justin Pryzby wrote: > > I previously mailed separately about a few individual patches, some of which > > have separate, ongoing discussion and aren't included here (incr sort, > >

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 9, 2020 at 2:03 PM Justin Pryzby wrote: > > On Thu, Apr 09, 2020 at 05:07:48PM +0900, Masahiko Sawada wrote: > > Yes but the difference is that we cannot disable PARSER or COPY by > > specifying options whereas we can do something like "VACUUM (FULL > > false) tbl" to disable FULL

Re: SyncRepLock acquired exclusively in default configuration

On 2020/04/08 3:01, Ashwin Agrawal wrote: On Mon, Apr 6, 2020 at 2:14 PM Andres Freund mailto:and...@anarazel.de>> wrote: > How about we change it to this ? Hm. Better. But I think it might need at least a compiler barrier / volatile memory load?  Unlikely here, but otherwise

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 9, 2020 at 7:31 PM Robert Haas wrote: > > On Thu, Apr 9, 2020 at 1:36 AM Amit Kapila wrote: > > On Thu, Apr 9, 2020 at 7:07 AM Michael Paquier wrote: > > > On Wed, Apr 08, 2020 at 01:38:54PM -0500, Justin Pryzby wrote: > > > > I think the behavior is correct, but the error message

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

At Fri, 10 Apr 2020 12:32:31 +0900, Masahiko Sawada wrote in > On Fri, 10 Apr 2020 at 04:05, Peter Geoghegan wrote: > > > > On Wed, Apr 8, 2020 at 10:56 PM Masahiko Sawada > > wrote: > > > Here is the reproducer: > > > > What version of Postgres did you notice the actual customer issue on? >

Re: SyncRepLock acquired exclusively in default configuration

On Fri, 10 Apr 2020 at 13:20, Fujii Masao wrote: > > > > On 2020/04/08 3:01, Ashwin Agrawal wrote: > > > > On Mon, Apr 6, 2020 at 2:14 PM Andres Freund > > wrote: > > > > > How about we change it to this ? > > > > Hm. Better. But I think it might need at least

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Fri, 10 Apr 2020 at 14:04, Amit Kapila wrote: > > On Thu, Apr 9, 2020 at 2:03 PM Justin Pryzby wrote: > > > > On Thu, Apr 09, 2020 at 05:07:48PM +0900, Masahiko Sawada wrote: > > > Yes but the difference is that we cannot disable PARSER or COPY by > > > specifying options whereas we can do

Re: segmentation fault using currtid and partitioned tables

On Wed, Apr 08, 2020 at 04:13:31PM +0900, Michael Paquier wrote: > I have been looking at the tree and the use of the table AM APIs, and > those TID lookups are really a particular case compared to the other > callers of the table AM callbacks. Anyway, I have not spotted similar > problems, so I

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, 9 Apr 2020 at 14:52, Amit Kapila wrote: > > On Thu, Apr 9, 2020 at 12:09 AM Justin Pryzby wrote: > > > > On Thu, Apr 09, 2020 at 12:06:04AM +0530, Mahendra Singh Thalor wrote: > > > On Wed, 8 Apr 2020 at 22:11, Justin Pryzby wrote: > > > > > > > > > > Thanks Justin for the patch. > > >

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 9, 2020 at 12:14 PM Michael Paquier wrote: > > On Thu, Apr 09, 2020 at 11:05:50AM +0530, Amit Kapila wrote: > > On Thu, Apr 9, 2020 at 7:07 AM Michael Paquier wrote: > >> I think that > >> this patch needs tests in sql/vacuum.sql. > > > > We already have one test that is testing an

Re: [HACKERS] make async slave to wait for lsn to be replayed

At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane wrote in > Anna Akenteva writes: > > I'd like to hear others' opinions on the syntax as well. > > Pardon me for coming very late to the party, but it seems like there are > other questions that ought to be answered before we worry about any of >

Re: Commitfest 2020-03 Now in Progress

Le jeu. 9 avr. 2020 à 04:12, Alvaro Herrera a écrit : > On 2020-Apr-08, David Steele wrote: > > > The 2020-03 Commitfest is officially closed. > > > > Final stats are (for entire CF, not just from March 1 this time): > > Thanks for managing! > Thanks a lot for the hard work! >

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On Thu, Apr 9, 2020 at 2:36 PM Tom Lane wrote: > Etsuro Fujita writes: > > Yeah, partition_bounds_merge() is currently called only from > > try_partitionwise_join(), which guarantees that the strategies are the > > same. > If there's only one caller and there's not likely to ever be more, >

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 09, 2020 at 11:05:50AM +0530, Amit Kapila wrote: > On Thu, Apr 9, 2020 at 7:07 AM Michael Paquier wrote: >> I think that >> this patch needs tests in sql/vacuum.sql. > > We already have one test that is testing an invalid combination of > PARALLEL and FULL option, not sure of adding

Re: adding partitioned tables to publications

On Thu, Apr 9, 2020 at 4:14 PM Peter Eisentraut wrote: > On 2020-04-09 05:39, Amit Langote wrote: > > sub_viaroot ERROR: number of columns (2601) exceeds limit (1664) > > sub_viaroot CONTEXT: slot "sub_viaroot", output plugin "pgoutput", in > > the change callback, associated LSN 0/1621010 > >

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 9, 2020 at 11:54 AM Masahiko Sawada wrote: > > On Thu, 9 Apr 2020 at 14:52, Amit Kapila wrote: > > > > > We can do what Mahendra > > is saying but that will unnecessarily block some syntax and we might > > need to introduce an extra variable to detect that in code. > > ISTM we have

Re: adding partitioned tables to publications

On 2020-04-09 05:39, Amit Langote wrote: sub_viaroot ERROR: number of columns (2601) exceeds limit (1664) sub_viaroot CONTEXT: slot "sub_viaroot", output plugin "pgoutput", in the change callback, associated LSN 0/1621010 I think the problem is that in maybe_send_schema(),

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 09, 2020 at 12:33:57PM +0530, Amit Kapila wrote: > We can add more tests to validate the syntax, but my worry was to not > increase test timing by doing (parallel) vacuum. So maybe we can do > such syntax validation on empty tables or you have any better idea? Using empty tables for

Re: PG compilation error with Visual Studio 2015/2017/2019

On Wed, Apr 8, 2020 at 7:39 PM Juan José Santamaría Flecha > Let me explain further, in pg_config_os.h you can check that the value of > _WIN32_WINNT is solely based on checking _MSC_VER. This patch should also > be meaningful for WIN32 builds using MinGW, or we might see this issue > reappear in

Re: [HACKERS] make async slave to wait for lsn to be replayed

On 2020/04/09 16:11, Kyotaro Horiguchi wrote: At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane wrote in Anna Akenteva writes: I'd like to hear others' opinions on the syntax as well. Pardon me for coming very late to the party, but it seems like there are other questions that ought to be

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 09, 2020 at 05:07:48PM +0900, Masahiko Sawada wrote: > Yes but the difference is that we cannot disable PARSER or COPY by > specifying options whereas we can do something like "VACUUM (FULL > false) tbl" to disable FULL option. I might be misunderstanding the > meaning of "specify"

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 09, 2020 at 12:31:55PM +0530, Amit Kapila wrote: > Sure, we can change that, but isn't the existing example of similar > message "cannot specify both PARSER and COPY options" occurs when > both the options have valid values? If so, we can use a similar > principle here, no? A better

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, 9 Apr 2020 at 16:02, Amit Kapila wrote: > > On Thu, Apr 9, 2020 at 11:54 AM Masahiko Sawada > wrote: > > > > On Thu, 9 Apr 2020 at 14:52, Amit Kapila wrote: > > > > > > > > We can do what Mahendra > > > is saying but that will unnecessarily block some syntax and we might > > > need to

Re: PG compilation error with Visual Studio 2015/2017/2019

On Thu, Apr 9, 2020 at 1:56 PM Ranier Vilela wrote: > Attached, your patch with those considerations. > I see no attachment. Regards

Re: Parallel copy

On Thu, Apr 9, 2020 at 1:00 AM Robert Haas wrote: > > On Tue, Apr 7, 2020 at 9:38 AM Ants Aasma wrote: > > > > With option 1 it's not possible to read input data into shared memory > > and there needs to be an extra memcpy in the time critical sequential > > flow of the leader. With option 2

Re: Parallel copy

On Thu, Apr 9, 2020 at 4:20 PM Amit Kapila wrote: > > On Thu, Apr 9, 2020 at 1:00 AM Robert Haas wrote: > > > > On Tue, Apr 7, 2020 at 9:38 AM Ants Aasma wrote: > > > > > > With option 1 it's not possible to read input data into shared memory > > > and there needs to be an extra memcpy in the

Re: Parallel copy

On Thu, Apr 9, 2020 at 1:00 AM Robert Haas wrote: > > On Tue, Apr 7, 2020 at 9:38 AM Ants Aasma wrote: > > I think the element based approach and requirement that all tuples fit > > into the queue makes things unnecessarily complex. The approach I > > detailed earlier allows for tuples to be

Re: Default setting for enable_hashagg_disk

On Tue, Apr 07, 2020 at 05:39:01PM -0500, Justin Pryzby wrote: On Tue, Apr 07, 2020 at 11:20:46AM -0700, Jeff Davis wrote: The enable_hashagg_disk GUC, if set to true, chooses HashAgg based on costing. If false, it only generates a HashAgg path if it thinks it will fit in work_mem, similar to

Re: [Proposal] Global temporary tables

On 4/7/20 2:27 PM, 曾文旌 wrote: Vacuum full GTT, cluster GTT is already supported in global_temporary_table_v24-pg13.patch. Hi Wenjing, Please refer this scenario , where reindex   message is not coming next time ( after reconnecting to database) for GTT A) --normal table postgres=# create

Re: [Proposal] Global temporary tables

> 2020年4月9日 下午7:46，tushar 写道： > > On 4/7/20 2:27 PM, 曾文旌 wrote: >> Vacuum full GTT, cluster GTT is already supported in >> global_temporary_table_v24-pg13.patch. > > Hi Wenjing, > > Please refer this scenario , where reindex message is not coming next time > ( after reconnecting to

Re: PG compilation error with Visual Studio 2015/2017/2019

>On Wed, Apr 8, 2020 at 7:39 PM Juan José Santamaría Flecha >> Let me explain further, in pg_config_os.h you can check that the value of >> _WIN32_WINNT is solely based on checking _MSC_VER. This patch should also >> be meaningful for WIN32 builds using MinGW, or we might see this issue >>

Re: Parallel copy

On Thu, Apr 9, 2020 at 3:55 AM Ants Aasma wrote: > > On Wed, 8 Apr 2020 at 22:30, Robert Haas wrote: > > > - The portion of the time that is used to split the lines is not > > easily parallelizable. That seems to be a fairly small percentage for > > a reasonably wide table, but it looks

Re: pgbench - add pseudo-random permutation function

On 4/2/20 3:01 AM, Alvaro Herrera wrote: On 2020-Apr-02, Fabien COELHO wrote: I'm planning to mark this patch RwF on April 8 and I suggest you resubmit if you are able to get some consensus. People interested in non-uniform benchmarks would see the point. Why many people would be happy with

Re: [HACKERS] make async slave to wait for lsn to be replayed

Fujii Masao writes: > On 2020/04/09 16:11, Kyotaro Horiguchi wrote: >> At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane wrote in >>> Why is this getting grafted onto BEGIN/START TRANSACTION in the >>> first place? >> The rationale for not being a fmgr function is stated in the following >>

Re: [Proposal] Global temporary tables

On 2020-04-09 15:28, 曾文旌 wrote: [global_temporary_table_v25-pg13.patch] Part of the problem is that some variables are only used by assert statements, and I fixed those alarms. Please provide your configue parameter, and I will verify it again. Hi, Just now I compiled the newer version

Re: Vacuum o/p with (full 1, parallel 0) option throwing an error

On Thu, Apr 9, 2020 at 1:36 AM Amit Kapila wrote: > On Thu, Apr 9, 2020 at 7:07 AM Michael Paquier wrote: > > On Wed, Apr 08, 2020 at 01:38:54PM -0500, Justin Pryzby wrote: > > > I think the behavior is correct, but the error message could be improved, > > > like: > > > |ERROR: cannot specify

Re: A problem about partitionwise join

> > I think it would not work for outer joins if we only check > exprs_known_equal() for equivalences. If the equi-join conditions > involving pairs of matching partition keys are outer join quals > mentioning nonnullable side rels, they would not exist in any EC > according to the current EC

Re: backup manifests

On 2020/04/09 2:35, Robert Haas wrote: On Wed, Apr 8, 2020 at 1:15 AM Fujii Masao wrote: When there is a backup_manifest in the database cluster, it's included in the backup even when --no-manifest is specified. ISTM that this is problematic because the backup_manifest is obviously not

Re: backup manifests

On 2020/04/09 23:10, Stephen Frost wrote: Greetings, * Fujii Masao (masao.fu...@oss.nttdata.com) wrote: On 2020/04/09 2:35, Robert Haas wrote: On Wed, Apr 8, 2020 at 1:15 AM Fujii Masao wrote: When there is a backup_manifest in the database cluster, it's included in the backup even when

Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables

On Thu, Apr 9, 2020 at 3:09 AM Tom Lane wrote: > Alvaro Herrera writes: > > On 2020-Apr-08, Tom Lane wrote: > >> I think that #1 would soon lead to needing all the same infrastructure > >> as we have for inherited columns and constraints, ie triggers would need > >> equivalents of attislocal and

Re: PG compilation error with Visual Studio 2015/2017/2019

Em qui., 9 de abr. de 2020 às 09:14, Juan José Santamaría Flecha < juanjo.santama...@gmail.com> escreveu: > > On Thu, Apr 9, 2020 at 1:56 PM Ranier Vilela wrote: > >> Attached, your patch with those considerations. >> > I see no attachment. > Sorry, my mystake. regards, Ranier Vilela

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, Apr 9, 2020 at 5:59 AM Fujii Masao wrote: > > > > On 2020/04/08 18:31, Julien Rouhaud wrote: > > On Wed, Apr 08, 2020 at 05:37:27PM +0900, Fujii Masao wrote: > >> > >> > >> On 2020/04/03 16:26, Julien Rouhaud wrote: > >>> On Thu, Apr 02, 2020 at 01:04:28PM -0700, legrand legrand wrote: >

Re: Report error position in partition bound check

While I'm quite on board with providing useful error cursors, the example cases in this patch don't seem all that useful: -- trying to create range partition with empty range CREATE TABLE fail_part PARTITION OF range_parted2 FOR VALUES FROM (1) TO (0); ERROR: empty range bound specified for

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/04/09 22:31, Julien Rouhaud wrote: On Thu, Apr 9, 2020 at 5:59 AM Fujii Masao wrote: On 2020/04/08 18:31, Julien Rouhaud wrote: On Wed, Apr 08, 2020 at 05:37:27PM +0900, Fujii Masao wrote: On 2020/04/03 16:26, Julien Rouhaud wrote: On Thu, Apr 02, 2020 at 01:04:28PM -0700,

Re: backup manifests

Greetings, * Fujii Masao (masao.fu...@oss.nttdata.com) wrote: > On 2020/04/09 2:35, Robert Haas wrote: > >On Wed, Apr 8, 2020 at 1:15 AM Fujii Masao > >wrote: > >>When there is a backup_manifest in the database cluster, it's included in > >>the backup even when --no-manifest is specified. ISTM

Re: ALTER TABLE ... SET STORAGE does not propagate to indexes

On 2020-03-30 18:17, Alvaro Herrera wrote: On 2020-Feb-25, Peter Eisentraut wrote: An alternative would be that we make this situation fully supported. Then we'd probably need at least ALTER INDEX ... ALTER COLUMN ... SET STORAGE, and some pg_dump support. I think this is a more promising

Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables

Amit Langote writes: > On Thu, Apr 9, 2020 at 3:09 AM Tom Lane wrote: >> My point is that so long as you only allow the case of exactly one parent, >> you can just delete the child trigger, because it must belong to that >> parent. As soon as there's any flexibility, you are going to end up >>

Re: Report error position in partition bound check

Hi Alexandra, As Michael said it will be considered for the next commitfest. But from a quick glance, a suggestion. Instead of passing NULL parsestate from ATExecAttachPartition, pass make_parsestate(NULL). parse_errorposition() takes care of NULL parse state input, but it might be safer this way.

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On Thu, Apr 9, 2020 at 12:03 PM Etsuro Fujita wrote: > > On Thu, Apr 9, 2020 at 2:36 PM Tom Lane wrote: > > Etsuro Fujita writes: > > > Yeah, partition_bounds_merge() is currently called only from > > > try_partitionwise_join(), which guarantees that the strategies are the > > > same. > > > If

Re: Report error position in partition bound check

On Thu, Apr 9, 2020 at 10:51 PM Ashutosh Bapat wrote: > > Hi Alexandra, > As Michael said it will be considered for the next commitfest. But > from a quick glance, a suggestion. > Instead of passing NULL parsestate from ATExecAttachPartition, pass > make_parsestate(NULL). parse_errorposition()

cleaning perl code

We currently only run perlcritic at severity level 5, which is fairly permissive. I'd like to reduce that, ideally to, say, level 3, which is what I use for the buildfarm code. But let's start by going to severity level 4. Give this perlcriticrc, derived from the buildfarm's: # for policy

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On Thu, Apr 09, 2020 at 07:34:01PM +0530, Ashutosh Bapat wrote: On Thu, Apr 9, 2020 at 12:03 PM Etsuro Fujita wrote: On Thu, Apr 9, 2020 at 2:36 PM Tom Lane wrote: > Etsuro Fujita writes: > > Yeah, partition_bounds_merge() is currently called only from > > try_partitionwise_join(), which