Re: Protect syscache from bloating with negative cache entries

At Mon, 12 Mar 2018 17:34:08 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20180312.173408.162882093.horiguchi.kyot...@lab.ntt.co.jp> > > > In short, it's not really apparent to me that negative syscache entries > > > are the major problem of this

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

At Thu, 15 Mar 2018 00:33:25 -0400, Tom Lane wrote in <22193.1521088...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > Doesn't it make sense if we provide a buildtime-script that > > collects the function names and builds a .h file containing

Re: Additional Statistics Hooks

On Tue, Mar 13, 2018 at 8:55 PM, Mat Arye wrote: >> >> Like cost associated with a function, we may associate mapping >> cardinality with a function. It tells how many distinct input values >> map to 1 output value. By input value, I mean input argument tuple. In >> Mat's case

Re: INOUT parameters in procedures

On Wed, Mar 14, 2018 at 10:46 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > committed > > I'm getting compiler warnings: pl_exec.c: In function 'exec_stmt_call': pl_exec.c:2089:8: warning: variable 'numargs' set but not used [-Wunused-but-set-variable] int numargs;

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Kyotaro HORIGUCHI writes: > Doesn't it make sense if we provide a buildtime-script that > collects the function names and builds a .h file containing a > function using the list? Surely this is a fundamentally misguided approach. How could it handle extension

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Hello, At Wed, 14 Mar 2018 17:46:21 +0900, Michael Paquier wrote in <20180314084621.ga...@paquier.xyz> > On Wed, Mar 14, 2018 at 05:30:59PM +0900, Kyotaro HORIGUCHI wrote: > > Doesn't it make sense if we provide a buildtime-script that > > collects the function names and

Re: Comment fixes in create_grouping_paths() add_paths_to_append_rel()

On Wed, Mar 14, 2018 at 10:11 PM, Stephen Frost wrote: > Greetings Ashutosh, > > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: >> Here are two patches fixing comments. > > Thanks! > >> 0001 >> A comment in add_paths_to_append_rel() mentions the number of paths >>

Re: Incorrect comment for ExecProcessReturning

Hi Stephen, (2018/03/14 22:28), Stephen Frost wrote: * Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote: Here is a small patch to fix $SUBJECT, which I think is my fault when working on direct foreign-table modification. Sorry about that. Fixed. Thanks! Best regards, Etsuro Fujita

Re: JIT compiling with LLVM v11

Hi, On 2018-03-14 22:36:52 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-03-13 15:29:33 -0700, Andres Freund wrote: > >> On 2018-03-14 10:32:40 +1300, Thomas Munro wrote: > >>> It looks > >>> like -fexcess-precision-standard is coming from a configure test that >

Re: Re: [GSOC 18] Performance Farm Project——Initialization Project

Dave Page writes: >> On 14 Mar 2018, at 19:14, Mark Wong wrote: >> Since the buildfarm is composed of animals, I thought plants would be a >> complimentary scheme? I'm also not sure if this was discussed >> previously... > For some reason I was thinking

Re: Instability in parallel regression tests

Thomas Munro writes: > On Thu, Mar 15, 2018 at 3:32 PM, Tom Lane wrote: >> ... I manually filtered >> out a bunch of non-problems, in particular discarding names that are in >> per-test schemas; I think it's all right to allow tests that are

Re: [GSOC 18] Performance Farm Project——Initialization Project

> On 14 Mar 2018, at 19:14, Mark Wong wrote: > > Hi, > > I have some additional comments to a couple areas... > >> On Wed, Mar 14, 2018 at 05:33:00PM -0400, Dave Page wrote: >>> On Tue, Mar 13, 2018 at 11:31 PM, Hongyuan Ma wrote: >>> At the same

Re: Instability in parallel regression tests

On Thu, Mar 15, 2018 at 3:32 PM, Tom Lane wrote: > ... I manually filtered > out a bunch of non-problems, in particular discarding names that are in > per-test schemas; I think it's all right to allow tests that are taking > that precaution to do what they like name-wise.

Re: Failed to request an autovacuum work-item in silence

On Thu, Mar 15, 2018 at 12:06 AM, Alvaro Herrera wrote: > Hello, > > Ildar Musin wrote: > >> autovac_get_workitem_name() declaration seems redundant and should be >> removed. The same thing with including "utils/lsyscache.h" in brin.c. >> >> The 'requested' variable in

Re: JIT compiling with LLVM v11

Andres Freund writes: > On 2018-03-13 15:29:33 -0700, Andres Freund wrote: >> On 2018-03-14 10:32:40 +1300, Thomas Munro wrote: >>> It looks >>> like -fexcess-precision-standard is coming from a configure test that >>> was run against ${CC}, not against ${CLANG}, so I hacked

Re: Instability in parallel regression tests

Thomas Munro writes: > On Thu, Mar 15, 2018 at 12:31 PM, Tom Lane wrote: >> Moral: choose names less generic than "test" for globally-visible >> objects. I wonder if there's some way we could check for such >> conflicts automatically? > Ugh.

Re: Faster inserts with mostly-monotonically increasing values

On Wed, Mar 14, 2018 at 12:05 PM, Claudio Freire wrote: > On Wed, Mar 14, 2018 at 1:36 AM, Pavan Deolasee > wrote: >> >> >> On Sun, Mar 11, 2018 at 9:18 PM, Claudio Freire >> wrote: >>> >>> On Sun, Mar 11, 2018 at 2:27

Re: Instability in parallel regression tests

On Thu, Mar 15, 2018 at 12:31 PM, Tom Lane wrote: > guaibasaurus just failed in a way I'd not seen before: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus=2018-03-14%2006%3A33%3A01 > > Inspection of the diffs makes it depressingly obvious what

Re: ExplainProperty* and units

On 15 March 2018 at 05:07, Andres Freund wrote: > On 2018-03-14 14:34:38 +1300, David Rowley wrote: >> It would be nice to see us completely get rid of all the >> appendStringInfo* calls, apart from in the functions which meant to >> handle the behaviour specific to the

Re: remove pg_class.relhaspkey

On Wed, Mar 14, 2018 at 03:36:28PM -0400, Peter Eisentraut wrote: > done Thanks Peter. One done, 150 remaining. -- Michael signature.asc Description: PGP signature

Re: User defined data types in Logical Replication

-- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From 2da536c0f6a081a50cb708de3ad6631345ec8dca Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Wed, 14 Mar 2018 16:47:44 -0300

Re: User defined data types in Logical Replication

Masahiko Sawada wrote: > Regarding to regression test, I added a new test module > test_subscription that creates a new user-defined data type. In a > subscription regression test, using test_subscription we make > subscriber call slot_store_error_callback and check if the subscriber > can

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

Hi, On 03/10/2018 06:19 PM, Alvaro Herrera wrote: > On 0002: > > In terms of docs, I think it's better not to have anything > user-facing in the README. Consider that users are going to be > reading the HTML docs only, and many of them may not have the README > available at all. So anything that

Re: JIT compiling with LLVM v11

Hi, On 2018-03-13 15:29:33 -0700, Andres Freund wrote: > On 2018-03-14 10:32:40 +1300, Thomas Munro wrote: > > I decided to try this on a CentOS 7.2 box. It has LLVM 3.9 in the > > 'epel' package repo, but unfortunately it only has clang 3.4. > > That's a bit odd, given llvm and clang really

Re: neqjoinsel versus "refresh materialized view concurrently"

On Wed, Mar 14, 2018 at 2:56 PM, Jeff Janes wrote: > On Tue, Mar 13, 2018 at 4:57 PM, Thomas Munro > wrote: >> Here's a patch to remove LIMIT 1, which fixes the plan for Jeff's test >> scenario and some smaller and larger examples I tried.

Instability in parallel regression tests

guaibasaurus just failed in a way I'd not seen before: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus=2018-03-14%2006%3A33%3A01 Inspection of the diffs makes it depressingly obvious what happened: the concurrently-executing "alter_table" and "with" scripts both create

Re: Re: Re: [GSOC 18] Performance Farm Project——Initialization Project

Hi, I have some additional comments to a couple areas... On Wed, Mar 14, 2018 at 05:33:00PM -0400, Dave Page wrote: > On Tue, Mar 13, 2018 at 11:31 PM, Hongyuan Ma wrote: > > At the same time I hope you can help me understand the functional > > requirements of this

Re: Re: Re: [GSOC 18] Performance Farm Project——Initialization Project

Hi On Tue, Mar 13, 2018 at 11:31 PM, Hongyuan Ma wrote: > Hi Dave, > I am willing to use React to re-create the front-end application. Since I > plan to use separate front-end and back-end development methods, this means > that there will be no html files in Django

Re: remove pg_class.relhaspkey

On 3/14/18 01:47, Michael Paquier wrote: >> For the other flags we would probably need to test what impact would it >> have (e.g. table with no indexes, many indexes on other tables, and >> something calling get_relation_info a lot). But this patch proposes to >> remove only relhaspkey. > > Yes,

Re: SQL/JSON: functions

2018-03-14 15:11 GMT+01:00 Alexander Korotkov : > On Wed, Mar 14, 2018 at 2:10 AM, Andres Freund wrote: > >> On 2018-03-14 07:54:35 +0900, Michael Paquier wrote: >> > On Tue, Mar 13, 2018 at 04:08:01PM +0300, Oleg Bartunov wrote: >> > > The docs are

Re: User defined data types in Logical Replication

Alvaro Herrera wrote: > Yeah, seems a reasonable idea to me. Here's a tidied-up version of your > patch, minus the regression test changes (I may end up committing that > one separately). ... and patch. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: Ambigous Plan - Larger Table on Hash Side

On Tue, Mar 13, 2018 at 4:02 AM, Narendra Pradeep U U < narendra.prad...@zohocorp.com> wrote: > Hi, > Thanks everyone for your suggestions. I would like to add explain > analyze of both the plans so that we can have broader picture. > > I have a work_mem of 1000 MB. > Is it possible to

Re: PATCH: Configurable file mode mask

Hi Michael, On 3/13/18 9:31 PM, Michael Paquier wrote: > On Tue, Mar 13, 2018 at 12:19:07PM -0400, David Steele wrote: >> I'll attach new patches in a reply to [1] once I have made the changes >> Tom requested. > > Cool, thanks for your patience. Looking forward to seeing those. I'll > spend

Re: Parallel index creation does not properly cleanup after error

On Wed, Mar 14, 2018 at 5:16 AM, David Rowley wrote: > Thanks for putting the patch together. Although in regards to your > proposed commit message in the patch, I'd disagree with me having just > reported it. I also investigated it and suggested a fix, which happens

Re: WIP: a way forward on bootstrap data

John Naylor writes: > It didn't take that long to rebase the remaining parts of the > patchset, so despite what I said above I went ahead and put them in > version 10 (attached), this time via scripted bulk editing rather than > as large patches. Starting to look into this

Re: PATCH: Configurable file mode mask

Hi, On 3/13/18 12:13 PM, Stephen Frost wrote: > * David Steele (da...@pgmasters.net) wrote: >> On 3/13/18 11:00 AM, Tom Lane wrote: >>> >>> FWIW, I took a quick look through this patch and don't have any problem >>> with the approach, which appears to be "use the data directory's >>> startup-time

Re: ExplainProperty* and units

Hi, On 2018-03-13 17:27:40 -0700, Andres Freund wrote: > while adding EXPLAIN support for JITing (displaying time spent etc), I > got annoyed by the amount of duplication required. There's a fair amount > of > if (es->format == EXPLAIN_FORMAT_TEXT) > appendStringInfo(es->str,

Re: User defined data types in Logical Replication

Masahiko Sawada wrote: > After more thought, I think since the errors in > logicalrep_typmap_gettypname are not relevant with the actual error > (i.g. type conversion error) it would not be good idea to show the > error message of "could not found data type entry" in errcontext. > It might be

Re: INOUT parameters in procedures

committed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: ExplainProperty* and units

Andres Freund writes: > On 2018-03-14 13:32:10 -0400, Tom Lane wrote: >> Andres Freund writes: >>> Only thing I wonder is if we shouldn't just *remove* >>> ExplainPropertyLong and make ExplainPropertyInteger accept 64bits of >>> input - the effort of

Re: ExplainProperty* and units

Hi, On 2018-03-14 13:32:10 -0400, Tom Lane wrote: > Andres Freund writes: > > If we do this, and I think we should, I'm inclined to also commit a > > patch that renames ExplainPropertyLong > > and changes its argument type. Because passing long is just plain > > unhelpful for

Re: ExplainProperty* and units

Andres Freund writes: > If we do this, and I think we should, I'm inclined to also commit a > patch that renames ExplainPropertyLong > and changes its argument type. Because passing long is just plain > unhelpful for 32bit platforms and windows. We should just always use >

Re: ExplainProperty* and units

Hi, On 2018-03-13 17:27:40 -0700, Andres Freund wrote: > Hi, > > while adding EXPLAIN support for JITing (displaying time spent etc), I > got annoyed by the amount of duplication required. There's a fair amount > of > if (es->format == EXPLAIN_FORMAT_TEXT) > appendStringInfo(es->str,

Re: Comment fixes in create_grouping_paths() add_paths_to_append_rel()

Greetings Ashutosh, * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > Here are two patches fixing comments. Thanks! > 0001 > A comment in add_paths_to_append_rel() mentions the number of paths > instead of number of workers by mistake. Fixed it. This looks alright. > 0002 > Commit

Re: ExplainProperty* and units

Hi, On 2018-03-14 14:34:38 +1300, David Rowley wrote: > On 14 March 2018 at 13:27, Andres Freund wrote: > > In the attached *POC* patch I've added a 'unit' parameter to the numeric > > ExplainProperty* functions, which EXPLAIN_FORMAT_TEXT adds to the > > output. This can

EXPLAIN of Parallel Append

Hi, Given -- test.sql -- CREATE TABLE t1 ( a integer NOT NULL, b integer NOT NULL ) PARTITION BY HASH (b); CREATE TABLE t1_p00 PARTITION OF t1 FOR VALUES WITH (MODULUS 4, REMAINDER 0); CREATE TABLE t1_p01 PARTITION OF t1 FOR VALUES WITH (MODULUS 4, REMAINDER 1); CREATE TABLE t1_p02

Re: Failed to request an autovacuum work-item in silence

Hello, Ildar Musin wrote: > autovac_get_workitem_name() declaration seems redundant and should be > removed. The same thing with including "utils/lsyscache.h" in brin.c. > > The 'requested' variable in brininsert() I would again rename to something > like 'success' because a work item is

Re: Faster inserts with mostly-monotonically increasing values

On Wed, Mar 14, 2018 at 1:36 AM, Pavan Deolasee wrote: > > > On Sun, Mar 11, 2018 at 9:18 PM, Claudio Freire > wrote: >> >> On Sun, Mar 11, 2018 at 2:27 AM, Pavan Deolasee >> >> > >> > Yes, I will try that next - it seems like a good idea. So the

Re: [HACKERS] Partition-wise aggregation/grouping

On Tue, Mar 13, 2018 at 7:43 PM, Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > Hi, > > The patch-set is complete now. But still, there is a scope of some comment > improvements due to all these refactorings. I will work on it. Also, need > to update few documentations and indentations

Re: PATCH: Unlogged tables re-initialization tests

On 3/13/18 12:46, Alvaro Herrera wrote: > Dagfinn Ilmari Mannsåker wrote: > >> $SIG{__DIE__} gets called even for exceptions that would be caught by a >> surrunding eval block, so this should at the very least be: >> >> $SIG{__DIE__} = sub { BAIL_OUT(@_) unless $^S }; >> >> However, that is

Re: Faster inserts with mostly-monotonically increasing values

On Wed, Mar 14, 2018 at 7:21 PM, Simon Riggs wrote: > On 14 March 2018 at 13:33, Pavan Deolasee > wrote: > > > > > > On Wed, Mar 14, 2018 at 4:53 PM, Simon Riggs < > simon.ri...@2ndquadrant.com> > > wrote: > >> > >> On 14 March 2018 at

Re: SQL/JSON: functions

On Wed, Mar 14, 2018 at 2:10 AM, Andres Freund wrote: > On 2018-03-14 07:54:35 +0900, Michael Paquier wrote: > > On Tue, Mar 13, 2018 at 04:08:01PM +0300, Oleg Bartunov wrote: > > > The docs are here > > > https://github.com/obartunov/sqljsondoc/blob/master/README.jsonpath.md

Re: Faster inserts with mostly-monotonically increasing values

On Wed, Mar 14, 2018 at 10:51 AM, Simon Riggs wrote: > If there is enough delay in step 1 then any benefit is lost anyway, so > there is no point taking the cached path even when successful, so its > better to ignore in that case. I find myself agreeing with that.

Re: Faster inserts with mostly-monotonically increasing values

On 14 March 2018 at 13:33, Pavan Deolasee wrote: > > > On Wed, Mar 14, 2018 at 4:53 PM, Simon Riggs > wrote: >> >> On 14 March 2018 at 04:36, Pavan Deolasee >> wrote: >> > I wonder if the shortened code path

Re: PATCH: Unlogged tables re-initialization tests

On 3/14/18 9:07 AM, Peter Eisentraut wrote: > On 3/13/18 10:12, David Steele wrote: >> A new patch is attached. > > Committed. Thanks, Peter! -- -David da...@pgmasters.net

Re: Faster inserts with mostly-monotonically increasing values

On Wed, Mar 14, 2018 at 4:53 PM, Simon Riggs wrote: > On 14 March 2018 at 04:36, Pavan Deolasee > wrote: > > I wonder if the shortened code path actually leads to > > heavier contention for EXCLUSIVE lock on the rightmost page, which in >

Re: Incorrect comment for ExecProcessReturning

Greetings Etsuro, * Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote: > Here is a small patch to fix $SUBJECT, which I think is my fault when > working on direct foreign-table modification. Sorry about that. Fixed. Thanks! Stephen signature.asc Description: PGP signature

Re: PATCH: Unlogged tables re-initialization tests

On 3/13/18 10:12, David Steele wrote: > A new patch is attached. Committed. I removed the cleanup code at the end of the test file, since that is done automatically. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

Re: General purpose hashing func in pgbench

Hello Teodor, On 07.03.2018 16:21, Ildar Musin wrote: Turned out that the only big-endian machine I could run test on is out of order. I finally managed to perform this test on sparc v9 machine which is 64 bit big-endian architecture. I run pgbench script (see previous message) with

Re: [HACKERS] GUC for cleanup indexes threshold.

On Wed, Mar 14, 2018 at 7:40 AM, Masahiko Sawada wrote: > On Sat, Mar 10, 2018 at 3:40 AM, Alexander Korotkov > wrote: > > On Fri, Mar 9, 2018 at 3:12 PM, Masahiko Sawada > > wrote: > >> > >> On Fri, Mar 9, 2018 at 8:43

Re: Parallel index creation does not properly cleanup after error

On 12 March 2018 at 08:41, Peter Geoghegan wrote: > On Sun, Mar 11, 2018 at 3:22 AM, David Rowley >> A perhaps simple fix would be just to have ResetReindexPending() only >> reset the list to NIL again and not try to raise any error. > > I noticed a very similar bug in

Re: committing inside cursor loop

On Tue, 13 Mar 2018 11:08:36 -0400 Peter Eisentraut wrote: > On 3/6/18 07:48, Ildus Kurbangaliev wrote: > > Although as was discussed before it seems inconsistent without > > ROLLBACK support. There was a little discussion about it, but no > > replies. Maybe the

Re: [HACKERS] path toward faster partition pruning

On 14 March 2018 at 00:37, Amit Langote wrote: > Attached is a significantly revised version of the patch, although I admit > it could still use some work with regard to comments and other cleanup. Thanks for making all those changes. There's been quite a bit of

Re: Faster inserts with mostly-monotonically increasing values

On 14 March 2018 at 04:36, Pavan Deolasee wrote: > I wonder if the shortened code path actually leads to > heavier contention for EXCLUSIVE lock on the rightmost page, which in turn > causes the slowdown. But that's just a theory. Any ideas how to prove or > disprove

Comment fixes in create_grouping_paths() add_paths_to_append_rel()

Hi Here are two patches fixing comments. 0001 A comment in add_paths_to_append_rel() mentions the number of paths instead of number of workers by mistake. Fixed it. 0002 Commit b5635948ab165b6070e7d05d111f966e07570d81 added a single grouping_sets_data argument instead of two lists related to

Re: inserts into partitioned table may cause crash

On Wed, Mar 14, 2018 at 9:25 PM, Etsuro Fujita wrote: > (2018/03/14 14:54), Amit Langote wrote: >> On 2018/03/06 21:26, Etsuro Fujita wrote: >>> if (mtstate->mt_transition_capture != NULL) >>> { >>> if (resultRelInfo->ri_TrigDesc&& >>>

Re: [HACKERS] path toward faster partition pruning

On 2018/03/14 8:26, Alvaro Herrera wrote: > By the way, I checked whether patch 0002 (additional tests) had an > effect on coverage, and couldn't detect any changes in terms of > lines/functions. Were you able to find any bugs in your code thanks to > the new tests that would not have been

Re: Fixes for missing schema qualifications

On Wed, Mar 14, 2018 at 09:26:15AM +0900, Tatsuo Ishii wrote: > > select [...] where nspname operator(pg_catalog.=) '%s'​ > Next question is, should we update the manual? There are bunch of > places where example queries are shown without schema qualifications. I gave

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Wed, Mar 14, 2018 at 05:30:59PM +0900, Kyotaro HORIGUCHI wrote: > Doesn't it make sense if we provide a buildtime-script that > collects the function names and builds a .h file containing a > function using the list? > > The attached perl script is a rush work of such script, which > works at

Incorrect comment for ExecProcessReturning

Here is a small patch to fix $SUBJECT, which I think is my fault when working on direct foreign-table modification. Sorry about that. Best regards, Etsuro Fujita diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c index c32928d..3332ae4 100644 ---

Re: inserts into partitioned table may cause crash

On 2018/03/14 17:35, Etsuro Fujita wrote: > (2018/03/14 17:25), Etsuro Fujita wrote: >> (2018/03/14 14:54), Amit Langote wrote: >>> Sorry that this may be nitpicking that I should've brought up before, but >>> doesn't ExecPrepareTupleRouting do all the work that's needed for routing >>> a tuple

Re: inserts into partitioned table may cause crash

(2018/03/14 17:25), Etsuro Fujita wrote: (2018/03/14 14:54), Amit Langote wrote: Sorry that this may be nitpicking that I should've brought up before, but doesn't ExecPrepareTupleRouting do all the work that's needed for routing a tuple and hence isn't the name a bit misleading? Maybe,

Re: [submit code] I develop a tool for pgsql, how can I submit it

Hello leap, > hello! > I develop a tool for pgsql, I want to submit it on pgsql. > how can I submit it? > address: https://github.com/leapking/pgcheck It's always nice to see another great tool! Thanks a lot for sharing it. I believe you should write a blog post about it for PostgreSQL Planet or

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Hello, At Tue, 6 Mar 2018 07:14:00 +0100, Pavel Stehule wrote in

Re: inserts into partitioned table may cause crash

(2018/03/14 14:54), Amit Langote wrote: On 2018/03/06 21:26, Etsuro Fujita wrote: One thing I notice while working on this is this in ExecInsert/CopyFrom, /* * If we're capturing transition tuples, we might need to convert from the * partition rowtype to parent rowtype.

Re: constraint exclusion and nulls in IN (..) clause

On 2018/03/14 17:16, Amit Langote wrote: > On 2018/03/10 13:40, Tom Lane wrote: >> I wrote: >>> I think it'd make more sense to see about incorporating that idea in >>> predicate_implied_by_simple_clause/predicate_refuted_by_simple_clause. >> >> After further thought, it seems like the place to

Re: constraint exclusion and nulls in IN (..) clause

On 2018/03/10 13:40, Tom Lane wrote: > I wrote: >> I think it'd make more sense to see about incorporating that idea in >> predicate_implied_by_simple_clause/predicate_refuted_by_simple_clause. > > After further thought, it seems like the place to deal with this is > really

Re: Google Summer of Code: Potential Applicant

Hello Stephen, > > Protobuf is fine too, but unfortunately we don't have any > > Protobuf-related projects this time. > > Just to be clear, the list on the wiki is just a set of suggestions- > students are welcome to propose their own projects as well. Oh, I didn't know that. In this case I

Re: fixing more format truncation issues

On Wed, Feb 28, 2018 at 11:14:23PM -0500, Peter Eisentraut wrote: > AFAICT, the issues addressed here either can't really happen without > trying very hard, or would cause harmless output truncation. Still, it > seems good to clean this up properly and not rely on made-up buffer size > guesses