Re: Confusing comment for function ExecParallelEstimate

On Thu, Jun 6, 2019 at 8:12 AM Amit Kapila wrote: > > On Thu, Jun 6, 2019 at 7:37 AM Wu, Fei wrote: > > > > Sorry, Last mail forget to CC the mailing list. > > > > Now the comment is confusing, Maybe someone should correct it. > > > > Sure, for the sake of clarity, when this code was initially

Re: pg_checksums has an untranslatable string.

Hello > Confirmed and committed. Thanks for the report. Thanks for committing. -- Kyotaro Horiguchi NTT Open Source Software Center

Re: Fix inconsistencies for v12

On Tue, Jun 4, 2019 at 7:36 AM Amit Kapila wrote: > > Hi Andres, > > I have added you here as some of these are related to commits done by > you. So need your opinion on the same. I have mentioned where your > feedback will be helpful. > > > 10. HeapTupleSatisfiesSnapshot ->

Re: Should we warn against using too many partitions?

On Fri, 7 Jun 2019 at 03:12, Alvaro Herrera wrote: > I think it'd be worthwhile to mention sub-partitioning. In the attached I did briefly mention about sub-partitioning, however, I didn't feel I had any very wise words to write about it other than it can be useful to split up larger partitions.

Re: Custom table AMs need to include heapam.h because of BulkInsertState

On Tue, Jun 04, 2019 at 10:18:03AM -0400, Robert Haas wrote: > On Sat, Jun 1, 2019 at 3:09 PM Michael Paquier wrote: >> I am fine to live with the dependency with vacuum.h as it is not that >> strange. However for BulkInsertState we get a hard dependency with a >> heap-related area and it seems

Re: Confusing comment for function ExecParallelEstimate

On 2019-Jun-07, Amit Kapila wrote: > Pushed. Note, I was not able to apply your patch using patch -p1 command. Yeah, it's a "normal" diff (old school), not a unified or context diff. patch doesn't like normal diff, for good reasons, but you can force it to apply with "patch --normal" (not

Re: hyrax vs. RelationBuildPartitionDesc

On Thu, Jun 6, 2019 at 3:47 PM Amit Langote wrote: > While it's > problematic that the session in which a new partition is attached to > the parent relation broadcasts 2 SI messages to invalidate the parent > relation [1], it's obviously better to fix how RelationClearRelation > manipulates

Re: behaviour change - default_tablesapce + partition table

Hi Amit, Rushabh, On 2019-Jun-07, Amit Langote wrote: > Thanks for adding the tests. Looks good. Thanks Amit, pushed now. Marking open item as done. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: LLVM compile failing in seawasp

didier writes: > c.h defines a C Min macro conflicting with llvm new class > llvm:ElementCount Min member Really? Well, we will hardly be the only code they broke with that. I think we can just wait for them to reconsider. regards, tom lane

Re: Avoiding hash join batch explosions with extreme skew and weird stats

On Thu, May 16, 2019 at 3:22 PM Thomas Munro wrote: > Admittedly I don't have a patch, just a bunch of handwaving. One > reason I haven't attempted to write it is because although I know how > to do the non-parallel version using a BufFile full of match bits in > sync with the tuples for outer

Re: behaviour change - default_tablesapce + partition table

Hi Alvaro, On Fri, Jun 7, 2019 at 8:02 AM Alvaro Herrera wrote: > On 2019-Jun-06, Alvaro Herrera wrote: > > > Here's my proposed patch. I changed/expanded the tests a little bit to > > ensure more complete coverage. > > Well, revise the comments a little bit. Thanks for adding the tests.

Re: tableam: abstracting relation sizing code

On Thu, Jun 06, 2019 at 04:40:53PM -0400, Robert Haas wrote: > It looks to me as though any table AM that uses the relation forks > supported by PostgreSQL in a more or less normal manner is likely to > require an implementation of the relation_size callback that is > identical to the one for

Re: coverage additions

On Thu, Jun 06, 2019 at 06:14:45PM +0900, Michael Paquier wrote: > Not sure I still follow.. In src/backend/libpq we have > be-gssapi-common.c and be-gssapi-common.c, both getting added only if > with_gssapi is enabled. I am going to spawn a new thread with a patch for the header file. I think

be-gssapi-common.h should be located in src/include/libpq/

Hi all, As mentioned on another thread about test coverage, I have noticed that be-gssapi-common.h is not placed at the correct location, even its its identication path at the top points to where the file should be: https://www.postgresql.org/message-id/20190604014630.gh1...@paquier.xyz The file

Re: behaviour change - default_tablesapce + partition table

On 2019-May-20, Alvaro Herrera wrote: > On 2019-May-20, Amit Langote wrote: > > > Should we add this to open items? > > Yeah. I'm AFK this week, but can handle it afterwards. The fix already > missed beta1, so I don't think there's a problem with taking a little > bit longer. Here's my

Re: behaviour change - default_tablesapce + partition table

On 2019-Jun-06, Alvaro Herrera wrote: > Here's my proposed patch. I changed/expanded the tests a little bit to > ensure more complete coverage. Well, revise the comments a little bit. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote

Re: Avoiding hash join batch explosions with extreme skew and weird stats

On Tue, Jun 4, 2019 at 12:08 PM Robert Haas wrote: > On Tue, Jun 4, 2019 at 2:47 PM Melanie Plageman > wrote: > > Oops! You are totally right. > > I will amend the idea: > > For each chunk on the inner side, loop through both the original batch > > file and the unmatched outer tuples file

Re: Avoiding hash join batch explosions with extreme skew and weird stats

On Tue, Jun 4, 2019 at 12:15 PM Robert Haas wrote: > On Tue, Jun 4, 2019 at 3:09 PM Melanie Plageman > wrote: > > One question I have is, how would the OR'd together bitmap be > > propagated to workers after the first chunk? That is, when there are > > no tuples left in the outer bunch, for a

Re: pg_basebackup failure after setting default_table_access_method option

Thanks Hari for helping in verifying. Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com On Thu, Jun 6, 2019 at 6:50 AM Haribabu Kommi wrote: > > On Thu, Jun 6, 2019 at 1:46 AM vignesh C wrote: > >> >> Hi, >> >> *I noticed pg_basebackup failure when default_table_access_method option

Re: idea: log_statement_sample_rate - bottom limit for sampling

Le 06/06/2019 à 10:38, Pavel Stehule a écrit : > Hi > > I like the idea of sampling slow statements via  > log_statement_sample_rate. But I miss some parameter that can ensure > so every query executed over this limit is logged. > > Can we introduce new option > > log_statement_sampling_limit > >

Re: Fix runtime errors from -fsanitize=undefined

On 2019-06-05 21:30, Robert Haas wrote: > On Mon, Jun 3, 2019 at 3:22 PM Peter Eisentraut > wrote: >> After many years of trying, it seems the -fsanitize=undefined checking >> in gcc is now working somewhat reliably. Attached is a patch that fixes >> all errors of the kind > > Is this as of

Re: crash testing suggestions for 12 beta 1

On Wed, Jun 05, 2019 at 02:32:49PM -0700, Peter Geoghegan wrote: > Forgive me for droning on about amcheck once more, but maybe it'll > help: amcheck has the capability to detect at least two historic bugs > in CREATE INDEX CONCURRENTLY that made it into stable releases. The > "heapallindexed"

RE: Why does not subquery pruning conditions inherit to parent query?

On Friday, May 31, 2019 9:33 PM, David Rowley wrote: > On Fri, 31 May 2019 at 03:18, Kato, Sho wrote: > > Is it possible to improve a subquery quals to pull up into outer query? > > Sure, it's possible, but it would require writing code. When it can and > cannot/should not be done would need to

Re: PGCOLOR? (Re: pgsql: Unified logging system for command-line programs)

On Tue, Apr 9, 2019 at 9:01 PM Christoph Berg wrote: > > Re: Peter Eisentraut 2019-04-09 > > > I'm okay with changing it. As you indicate, I chose the name so that it > > doesn't look like a libpq variable. There are some other PG_ variables > > throughout the code, but those appear to be

Re: Add CREATE DATABASE LOCALE option

On 2019-06-05 22:31, Fabrízio de Royes Mello wrote: > On Wed, Jun 5, 2019 at 5:17 PM Peter Eisentraut > > wrote: >> >> I propose this patch to add a LOCALE option to CREATE DATABASE.  This >> sets both LC_COLLATE and LC_CTYPE with one option.  Similar

pg_checksums has an untranslatable string.

Hello. # My email address has changed. I found a string that ought to be translatable but actually not, in pg_checksums.c. > fprintf(stderr, "%*s/%s MB (%d%%) computed", It seems to be the only instance in the file. regards. -- Kyotaro Horiguchi NTT Open Source Software Center

Re: Why does pg_checksums -r not have a long option?

On Wed, Jun 05, 2019 at 10:31:54PM +0200, Peter Eisentraut wrote: > I think -r/--relfilenode was actually a good suggestion. Because it > doesn't actually check a *file* but potentially several files (forks, > segments). The -f naming makes it sound like it operates on a specific > file. Hmm.

Re: coverage additions

On Tue, Jun 04, 2019 at 04:07:17PM -0400, Alvaro Herrera wrote: > On 2019-Jun-04, Michael Paquier wrote: >> On Sat, Jun 01, 2019 at 12:55:47AM -0400, Alvaro Herrera wrote: >>> Ah, now I remember that I tried this before, but it requires some extra >>> packages installed in the machine I think, and

Small review comment on pg_checksums

Hi, While reading the pg_checksums code I found the following comment "Check if cluster is running" is not placed at right place. /* Check if cluster is running */ ControlFile = get_controlfile(DataDir, _ok); if (!crc_ok) { pg_log_error("pg_control CRC value is

idea: log_statement_sample_rate - bottom limit for sampling

Hi I like the idea of sampling slow statements via log_statement_sample_rate. But I miss some parameter that can ensure so every query executed over this limit is logged. Can we introduce new option log_statement_sampling_limit The query with execution time over this limit is logged every

Re: postgres_fdw: oddity in costing presorted foreign scans with local stats

On Fri, May 17, 2019 at 8:31 PM Etsuro Fujita wrote: > I noticed that there is (another) oddity in commit aa09cd242f: in the > !fpinfo->use_remote_estimate mode, when first called for costing an > unsorted foreign scan, estimate_path_cost_size() computes > retrieved_rows, which is the estimated

Re: pg_checksums has an untranslatable string.

On Thu, Jun 06, 2019 at 08:06:12PM +0900, Kyotaro Horiguchi wrote: > It seems to be the only instance in the file. Confirmed and committed. Thanks for the report. -- Michael signature.asc Description: PGP signature

Re: "long" type is not appropriate for counting tuples

On 2019-05-23 16:34, Tom Lane wrote: > On the whole I think I could live with a policy that says "tuple counts > shall be 'long long' when being passed around in code, but for persistent > storage or wire-protocol transmission, use 'int64'". > > An alternative and much narrower policy is to say

Re: Small review comment on pg_checksums

On Thu, Jun 06, 2019 at 05:16:30PM +0900, Masahiko Sawada wrote: > So I'd like to propose a small fix for that; move the comment to the > right place and add another comment. Please find an attached small > patch. No objections to that. Perhaps we should also mention that this does not protect

pg_checksums has an untranslatable string.

Hello. # My email address has changed. Apologize in advance for possible # duplicate of this mail because this is the seconf try after # mail server seems to have failed the first try... I found a string that ought to be translatable but actually not, in pg_checksums.c. > fprintf(stderr,

doc: pg_trgm missing description for GUC "pg_trgm.strict_word_similarity_threshold"

Hi Commit be8a7a68662 added custom GUC "pg_trgm.strict_word_similarity_threshold", but omitted to document this in the section "GUC Parameters"; proposed patch attached. I suggest backpatching to Pg11, where it was introduced. Regards Ian Barwick -- Ian Barwick

Re: "long" type is not appropriate for counting tuples

On Thu, May 23, 2019 at 10:21 AM Peter Eisentraut wrote: > Hmm, by that argument, we shouldn't ever use any integer type other than > int16, int32, and int64. I think we basically shouldn't. I mean it's fine to use 'int' as a flags argument as part of an internal API, or as a loop counter

Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3

Greetings, Antonin. You wrote 2019-06-05, 15:32: > Robert Haas wrote: >> On Fri, May 31, 2019 at 2:59 AM Antonin Houska wrote: >> > > Sounds good. I'm not quite sure how this is going to work. Ideally >> > > you'd like the encryption key command to fetch the key from something >> > > like

Re: Pluggable Storage - Andres's take

On 18/05/2019 01:19, Ashwin Agrawal wrote: On Tue, Apr 9, 2019 at 6:17 AM Heikki Linnakangas > wrote: On 08/04/2019 20:37, Andres Freund wrote: > On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote: >> There's a little bug in index-only scan executor

Re: pg_basebackup failure after setting default_table_access_method option

On Thu, Jun 06, 2019 at 11:19:48AM +1000, Haribabu Kommi wrote: > Thanks for the details steps to reproduce the bug, I am also able to > reproduce the problem. This way is even more simple, no need for zheap to be around: =# create access method heap2 TYPE table HANDLER heap_tableam_handler;

Re: hyrax vs. RelationBuildPartitionDesc

On Wed, Jun 5, 2019 at 8:03 PM Amit Langote wrote: > I noticed a crash with one of the scenarios that I think the patch is > meant to address. Let me describe the steps: > > Attach gdb (or whatever) to session 1 in which we'll run a query that > will scan at least two partitions and set a

Use of reloptions by EXTENSIONs

Hi folks, I’ve been paying my query-rewrite for MVs EXTENSION a bit of attention recently, and I was looking at how to enable people to turn it on and off without requiring a user of it to get too much into it’s guts. However, the add_X_reloption() APIs seems to need to be paired with a

Bug: ECPG: Cannot use CREATE AS EXECUTE statemnt

Meskes-san This thread is branched from the following. https://www.postgresql.org/message-id/03040DFF97E6E54E88D3BFEE5F5480F74ABEADE7@G01JPEXMBYT04 > > Type1. Bugs or intentional unsupported features. > > - EXPLAIN EXECUTE > > - **CREATE TABLE AS with using clause** I noticed that CREATE AS

Re: Should we warn against using too many partitions?

On 2019-Jun-06, David Rowley wrote: > The attached patch is aimed at master. PG11 will need the planner > memory and performance part tweaked and for PG10 I'll do that plus > remove the mention of PRIMARY KEY and UNIQUE constraints on the > partitioned table. I think in PG10 something should be

Re: Pluggable Storage - Andres's take

On 2019-Jun-06, Heikki Linnakangas wrote: > Pushed the first patch now. Andres already fixed the second issue in commit > b8b94ea129. Please don't omit the "Discussion:" tag in commit messages. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

Re: Removing a few more lseek() calls

On Sat, Mar 30, 2019 at 2:14 AM Thomas Munro wrote: > Hello, > > Patch 0001 gets rid of the unconditional lseek() calls for SLRU I/O, > as a small follow-up to commit c24dcd0c. Patch 0002 gets rid of a few > places that usually do a good job of avoiding lseek() calls while > reading and writing

Re: LLVM compile failing in seawasp

Hi, On 2019-06-06 13:32:16 -0400, Alvaro Herrera wrote: > Seawasp (using experimental clang 9.0) has been complaining of late: > > /home/fabien/clgtk/bin/clang -Wno-ignored-attributes -fno-strict-aliasing > -fwrapv -O2 -D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS > -D__STDC_CONSTANT_MACROS

Re: LLVM compile failing in seawasp

c.h defines a C Min macro conflicting with llvm new class llvm:ElementCount Min member On Thu, Jun 6, 2019 at 7:32 PM Alvaro Herrera wrote: > > Seawasp (using experimental clang 9.0) has been complaining of late: > > /home/fabien/clgtk/bin/clang -Wno-ignored-attributes -fno-strict-aliasing >

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

[ sorry for slow response, I'm on vacation ] Andres Freund writes: > That makes sense. As far as I can tell the reason that 12 sometimes ends > up with the proper timezone is that we shortcut the search by: > /* >* Try to avoid the brute-force search by seeing if we can recognize

Re: Sort support for macaddr8

Andres Freund writes: > On June 5, 2019 12:14:42 PM PDT, Alvaro Herrera > wrote: >> Does this mean that datatypes that are >4 and <=8 bytes need to handle >> both cases? Is it possible for them to detect the current environment? > Well, the conversion macros need to know. You can look at

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Hi, On 2019-06-06 12:51:30 -0400, Tom Lane wrote: > [ sorry for slow response, I'm on vacation ] Good. > Andres Freund writes: > > That makes sense. As far as I can tell the reason that 12 sometimes ends > > up with the proper timezone is that we shortcut the search by: > > > /* > >

LLVM compile failing in seawasp

Seawasp (using experimental clang 9.0) has been complaining of late: /home/fabien/clgtk/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv -O2 -D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS -D_DEBUG -D_GNU_SOURCE -I/home/fabien/clgtk/include

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Andres Freund writes: > On 2019-06-06 12:51:30 -0400, Tom Lane wrote: >> Sure, that is intentionally a behavior change in this situation. >> The theory is that if "Etc/UCT" is what the user put in /etc/localtime, >> then that's the spelling she wants. See 23bd3cec6. > Right, I'm not complaining

Re: [HACKERS] [PATCH] Generic type subscripting

> On Thu, Jun 6, 2019 at 3:17 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Thu, May 30, 2019 at 4:17 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > > > On Wed, May 29, 2019 at 6:17 PM Pavel Stehule > > > wrote: > > > > > > st 29. 5. 2019 v 17:49 odesílatel Dmitry Dolgov

Re: Multivariate MCV stats can leak data to unprivileged users

Hi, Attached are three patches tweaking the stats - two were already posted in this thread, the third one is just updating docs. 1) 0001 - split pg_statistic_ext into definition + data This is pretty much the patch Dean posted some time ago, rebased to current master (fixing just minor

tableam: abstracting relation sizing code

Hi, It looks to me as though any table AM that uses the relation forks supported by PostgreSQL in a more or less normal manner is likely to require an implementation of the relation_size callback that is identical to the one for heap, and an implementation of the estimate_rel_size method that is

Re: LLVM compile failing in seawasp

failure). Apparently clang got upgraded from "trunk 361691" to "trunk 362290" ... is the new clang broken? I think that machine might also update llvm to a trunk checkout. Is that right Fabien? Yes, the version is recompiled from sources on every Saturday. -- Fabien.

Re: Should we warn against using too many partitions?

On Fri, Jun 07, 2019 at 06:46:59AM +1200, David Rowley wrote: > On Thu, 6 Jun 2019 at 17:29, Justin Pryzby wrote: > > >+ > > >+ > > >+ Declarative Partitioning Best Practices > > >+ > > >+ > > >+The choice of how to partition a table should be considered carefully > > >as > > > >

Re: Should we warn against using too many partitions?

On Fri, 7 Jun 2019 at 03:12, Alvaro Herrera wrote: > I think in PG10 something should be mentioned about PK and UNIQUE, so > that people doing their partitioning on that release can think ahead. That seems reasonable, but I feel caution would be required as we don't want to provide any details

Re: Add CREATE DATABASE LOCALE option

On Thu, Jun 6, 2019 at 6:38 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > On 2019-06-05 22:31, Fabrízio de Royes Mello wrote: > > On Wed, Jun 5, 2019 at 5:17 PM Peter Eisentraut > > > > wrote: > >> > >> I propose this patch to add a

Re: Sort support for macaddr8

Hi, On 2019-06-06 13:39:50 -0400, Tom Lane wrote: > Lastly, I don't think adding additional allowed widths of pass-by-value > types would be cost-free, because it would add cycles to the inner loops > of the tuple forming and deforming functions. I'm not sure I quite buy that. I think that we

Re: Why does not subquery pruning conditions inherit to parent query?

On Thu, 6 Jun 2019 at 19:47, Kato, Sho wrote: > > On Friday, May 31, 2019 9:33 PM, David Rowley wrote: > > Sure, it's possible, but it would require writing code. When it can and > > cannot/should not be done would need to be determined. > > Is there any harmful effect by pulling up a subquery

Re: Should we warn against using too many partitions?

On Thu, 6 Jun 2019 at 17:29, Justin Pryzby wrote: > >+ > >+ > >+ Declarative Partitioning Best Practices > >+ > >+ > >+The choice of how to partition a table should be considered carefully as > > Either say "How to partition consider should be .." or "The choice should > MADE

Re: Should we warn against using too many partitions?

On Fri, 7 Jun 2019 at 06:54, Justin Pryzby wrote: > > > >+critical decision to make. Not having enough partitions may mean > > > >that > > > >+indexes remain too large and that data locality remains poor which > > > >could > > > >+result in poor cache hit ratios. However, dividing

Re: Add CREATE DATABASE LOCALE option

On 2019-Jun-06, Fabrízio de Royes Mello wrote: > > > Cool... would be nice also add some test cases. > > > > Right. Any suggestions where to put them? > > Hmm... good question... I thought we already have some regression tests for > {CREATE|DROP} DATABASE but actually we don't... should we add