Re: [Sender Address Forgery]Re: error message when subscription target is a partitioned table

On Fri, Jan 11, 2019 at 04:04:41PM +0900, Michael Paquier wrote: > Thanks. I can commit this version if there are no objections then. And done. -- Michael signature.asc Description: PGP signature

Re: PostgreSQL vs SQL/XML Standards

ne 13. 1. 2019 v 0:39 odesílatel Chapman Flack napsal: > On 12/30/18 03:23, Pavel Stehule wrote: > > Unfortunately, there is a different releases of libxml2 with different > > error reporting and it is hard (impossible) to prepare for all variants. > :-/ > > > > I prepare xml.out for my FC29 (fre

Re: PATCH: Include all columns in default names for foreign key constraints.

On 13/01/2019 01:55, Paul Martinez wrote: > This is my first submission to Postgres, so I'm not entirely sure what the > protocol is here to get this merged; should I add this patch to the 2019-03 > Commitfest? I haven't looked at the patch yet, but I think it's a good idea and anyway yes, please

Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's

On Sun, 13 Jan 2019 at 14:49, David Rowley wrote: > I've not looked in detail, but perhaps the place to put the tests are > in src/test/modules/test_predtest. This module adds a function named > test_predtest() that you can likely use more easily than trying to > EXPLAIN plans and hoping the plan

Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's

On Sun, 11 Nov 2018 at 10:33, James Coleman wrote: > At first I was imagining having the parse keep track of whether an array const > expr contained any nulls and perhaps adding generated quals (in an equivalence > class?) to allow the planner to easily prove the index was correct. I'd been > goin

PATCH: Include all columns in default names for foreign key constraints.

Hello! I have written a small patch to modify the default names for foreign key constraints. Currently if the foreign key is composed of multiple columns we only use the first one in the constraint name. This can lead to similar constraint names when two foreign keys start with the same column. Th

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

On 1/10/19 6:09 PM, Dean Rasheed wrote: > On Wed, 26 Dec 2018 at 22:09, Tomas Vondra > wrote: >> >> Attached is an updated version of the patch - rebased and fixing the >> warnings reported by Thomas Munro. >> > > Here are a few random review comments based on what I've read so far: > > > On t

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

On 1/12/19 8:49 AM, Dean Rasheed wrote: > On Fri, 11 Jan 2019, 21:18 Tomas Vondra wrote: > > > On 1/10/19 4:20 PM, Dean Rasheed wrote: > > ... > > > > So perhaps what we should do for multivariate stats is simply use the > > relative s

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Thu, 3 Jan 2019 at 08:01, Tomas Vondra wrote: > AFAICS the patch essentially does two things: (a) identifies Append > paths with a single member and (b) ensures the Vars are properly mapped > when the Append node is skipped when creating the plan. Yes, but traditional Append and MergeAppend pa

Re: O_DIRECT for relations and SLRUs (Prototype)

On Sun, Jan 13, 2019 at 5:13 AM Andrey Borodin wrote: > > Hi! > > > 12 янв. 2019 г., в 9:46, Michael Paquier написал(а): > > > > Attached is a toy patch that I have begun using for tests in this > > area. That's nothing really serious at this stage, but you can use > > that if you would like to

Re: Alternative to \copy in psql modelled after \g

I took a quick look at this patch. Some thoughts: * I think the right way to proceed is to commit (and back-patch) this without any regression test case, and maybe later look into adding a TAP test that covers "\g file". We have no test cases for any variant of "\g file", and because of platform

Re: Three animals fail test-decoding-check on REL_10_STABLE

Andrew Dunstan writes: > On 1/11/19 6:33 PM, Tom Lane wrote: >> While I think I've fixed this bug, I'm still quite confused about why >> only some buildfarm animals showed the problem. > ... Is there something weird about naming of library files on HP-UX? Doh! I looked right at this code last n

Re: Three animals fail test-decoding-check on REL_10_STABLE

On 1/11/19 6:33 PM, Tom Lane wrote: > I wrote: >> So it appears that in v10, >> ./configure ... --enable-tap-tests ... >> make >> make install >> cd contrib/test_decoding >> make check >> fails due to failure to install test_decoding into the tmp_install >> tree, while it

Re: O_DIRECT for relations and SLRUs (Prototype)

Hi! > 12 янв. 2019 г., в 9:46, Michael Paquier написал(а): > > Attached is a toy patch that I have begun using for tests in this > area. That's nothing really serious at this stage, but you can use > that if you would like to see the impact of O_DIRECT. Of course, > things get significantly sl

Re: log bind parameter values on error

please see attached sorry, some unintended changes sneaked in, please see the corrected patch diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index f64402a..924a76c 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -6270,6 +6270,23 @@ log_line_prefix = '%m

Re: log bind parameter values on error

Hello Peter, Unlike SQL, parameters may spend much more memory, so I'd have them in portal memory context to make sure the memory is released earlier rather than later. Having them in the portal structure is different from having it in the portal memory context. Although there is perhaps value

Re: Pluggable Storage - Andres's take

> On Sat, Jan 12, 2019 at 1:44 AM Andres Freund wrote: > > > + appendPQExpBuffer(cmd, "SET default_table_access_method = %s;", > > tableam); > > This needs escaping, at the very least with "", but better with proper > routines for dealing with identifiers. Thanks for noticing, fixed. > > @@

Re: Logical decoding for operations on zheap tables

On Fri, Jan 4, 2019 at 9:01 AM Andres Freund wrote: > > On 2019-01-04 08:54:34 +0530, Amit Kapila wrote: > > The only point for exposing a different tuple format via plugin was a > > performance which I think can be addressed if we expose via slots. I > > don't want to take up exposing slots inst

Re: Delay locking partitions during query execution

On Tue, 4 Dec 2018 at 00:42, David Rowley wrote: > Over here and along similar lines to the above, but this time I'd like > to take this even further and change things so we don't lock *any* > partitions during AcquireExecutorLocks() and instead just lock them > when we first access them with Exec

Re: speeding up planning with partitions

On Sat, 12 Jan 2019 at 02:00, Amit Langote wrote: > That's an oversight. Fixed by making add_child_rel_equivalences do this: > > +cur_ec->ec_relids = bms_difference(cur_ec->ec_relids, > + parent_rel->relids); > +cur_ec->ec_reli