Re: [HACKERS] Multi-tenancy with RLS

2017-01-30 Thread Haribabu Kommi
On Mon, Dec 5, 2016 at 4:31 PM, Haribabu Kommi wrote: > > > On Mon, Oct 3, 2016 at 3:11 PM, Michael Paquier > wrote: > >> On Tue, Jul 19, 2016 at 3:42 PM, Haribabu Kommi >> wrote: >> > The above changes are based

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

2017-01-30 Thread Vladimir Borodin
> 31 янв. 2017 г., в 9:50, Michael Paquier > написал(а): > > On Mon, Jan 30, 2017 at 4:28 PM, Andrew Borodin wrote: >> I'll summarize here my state of studying concurrent methods of page >> unlinking. >> >> GIN B-tree does not have "high

Re: [HACKERS] Superowners

2017-01-30 Thread David Fetter
On Fri, Jan 27, 2017 at 05:48:46PM -0500, Peter Eisentraut wrote: > On 1/26/17 1:25 PM, Simon Riggs wrote: > > That should include the ability to dump all objects, yet without > > any security details. And it should allow someone to setup logical > > replication easily, including both trigger

[HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

2017-01-30 Thread Pavan Deolasee
Hello All, While stress testing WARM, I encountered a data consistency problem. It happens when index is built concurrently. What I thought to be a WARM induced bug and it took me significant amount of investigation to finally conclude that it's a bug in the master. In fact, we tested all the way

Re: [HACKERS] Potential data loss of 2PC files

2017-01-30 Thread Heikki Linnakangas
On 12/27/2016 01:31 PM, Andres Freund wrote: On 2016-12-27 14:09:05 +0900, Michael Paquier wrote: On Fri, Dec 23, 2016 at 3:02 AM, Andres Freund wrote: Not quite IIRC: that doesn't deal with file size increase. All this would be easier if hardlinks wouldn't exist IIUC.

Re: [HACKERS] Deadlock in XLogInsert at AIX

2017-01-30 Thread Bernd Helmle
Hi Konstantin, We had observed exactly the same issues on a customer system with the same environment and PostgreSQL 9.5.5. Additionally, we've tested on Linux with XL/C 12 and 13 with exactly the same deadlock behavior. So we assumed that this is somehow a compiler issue. Am Dienstag, den

Re: [HACKERS] Superowners

2017-01-30 Thread Stephen Frost
Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > On 27 January 2017 at 22:48, Peter Eisentraut > wrote: > > On 1/26/17 1:25 PM, Simon Riggs wrote: > >> That should include the ability to dump all objects, yet without any > >> security details. And it should

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread Pavel Stehule
2017-01-30 14:46 GMT+01:00 Stephen Frost : > * Christoph Berg (christoph.b...@credativ.de) wrote: > > Re: Daniel Verite 2017-01-28 <74e7fd23-f5a9-488d-a8c4- > 1e0da674b...@manitou-mail.org> > > > > Mysql's CLI client is using \G for this purpose, and adding the very > > > >

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread Daniel Verite
Christoph Berg wrote: > But do we really want to choose > something different just because MySQL is using it? That's not what I meant. If mysql wasn't using \G I'd still suggest the name \gx because: - it means the functionality of \g combined with \x so semantically it makes sense. -

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread Tom Lane
"Daniel Verite" writes: >> \G will be much easier to explain to existing users (both people >> coming from MySQL to PostgreSQL, and PostgreSQL users doing a detour >> into foreign territory), and it would be one difference less to have >> to care about when typing on the

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread Tom Lane
Stephen Frost writes: > This particular bike-shedding really doesn't seem to be terribly useful > or sensible, to me. \gx isn't "consistent" or "descriptive", frankly. Why not? To me it reads as "\g with an x option". The "x" refers to the implied "\x", so it's not an

Re: [HACKERS] Superowners

2017-01-30 Thread Simon Riggs
On 27 January 2017 at 22:48, Peter Eisentraut wrote: > On 1/26/17 1:25 PM, Simon Riggs wrote: >> That should include the ability to dump all objects, yet without any >> security details. And it should allow someone to setup logical >> replication easily,

Re: [HACKERS] Parallel Index-only scan

2017-01-30 Thread tushar
On 01/19/2017 05:37 PM, Rafia Sabih wrote: Please find the attached file rebased patch of parallel index-only scan on the latest Parallel index-scan patch [1]. We did some testing of this feature and written few testcases. PFA the sql script(along with the expected .out files) In addition

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread Stephen Frost
* Christoph Berg (christoph.b...@credativ.de) wrote: > Re: Daniel Verite 2017-01-28 > <74e7fd23-f5a9-488d-a8c4-1e0da674b...@manitou-mail.org> > > > Mysql's CLI client is using \G for this purpose, and adding the very > > > same functionality to psql fits nicely into the set of existing > > >

Re: [HACKERS] Superowners

2017-01-30 Thread Simon Riggs
On 30 January 2017 at 14:43, Stephen Frost wrote: > We need to make sure that we're actually talking about the same things > here, because we've now shifted from ownership-like privileges to those > privielges which can be GRANT'd, and the two are far from the same. Agreed.

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread Stephen Frost
* Pavel Stehule (pavel.steh...@gmail.com) wrote: > 2017-01-30 14:46 GMT+01:00 Stephen Frost : > > > * Christoph Berg (christoph.b...@credativ.de) wrote: > > > Re: Daniel Verite 2017-01-28 <74e7fd23-f5a9-488d-a8c4- > > 1e0da674b...@manitou-mail.org> > > > > > Mysql's CLI client

Re: [HACKERS] Should we cacheline align PGXACT?

2017-01-30 Thread Alexander Korotkov
On Sat, Aug 20, 2016 at 9:38 PM, Tom Lane wrote: > Robert Haas writes: > > Wow, nice results. My intuition on why PGXACT helped in the first place > was that it minimized the number of cache lines that had to be touched to > take a snapshot. Padding

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-01-30 Thread Vladimir Rusinov
On Fri, Jan 27, 2017 at 11:03 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > 1. Rename nothing > 2. Rename directory only > 3. Rename everything > 3 or 1 (with a slight preference for 3). Not sure if my vote counts, but for me as ex-DBA consistency mattered *a lot*. This is

Re: [HACKERS] Subtle bug in "Simplify tape block format" commit

2017-01-30 Thread Heikki Linnakangas
On 01/07/2017 12:33 AM, Peter Geoghegan wrote: Previously, all calls to ltsGetFreeBlock() were immediately followed by a corresponding call to ltsWriteBlock(); we wrote out the newly-allocated-in-first-pass block there and then. It's a good idea for a corresponding ltsWriteBlock() call to happen

Re: [HACKERS] Push down more full joins in postgres_fdw

2017-01-30 Thread Ashutosh Bapat
On Mon, Jan 30, 2017 at 5:00 PM, Etsuro Fujita wrote: > On 2017/01/27 21:25, Etsuro Fujita wrote: >> >> On 2017/01/27 20:04, Ashutosh Bapat wrote: >>> >>> I think we should pick up your patch on >>> 27th December, update the comment per your mail on 5th Jan. I will

Re: [HACKERS] Supporting huge pages on Windows

2017-01-30 Thread Alvaro Herrera
Magnus Hagander wrote: > Taking a look at the actual code here, and a few small nitpicks: > > +errdetail("Failed system call was %s, > error code %lu", "LookupPrivilegeValue", GetLastError(; > > this seems to be a new pattern of code -- for other similar

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

2017-01-30 Thread Masahiko Sawada
On Thu, Jan 26, 2017 at 5:11 AM, Claudio Freire wrote: > On Wed, Jan 25, 2017 at 1:54 PM, Masahiko Sawada > wrote: >> Thank you for updating the patch! >> >> + /* >> +* Quickly rule out by lower bound (should happen a lot) Upper bound

Re: [HACKERS] [PATCH]: fix bug in SP-GiST box_ops

2017-01-30 Thread Kyotaro HORIGUCHI
Hello, At Mon, 30 Jan 2017 07:12:03 +0300, Nikita Glukhov wrote in <9ea5b157-478c-8874-bc9b-050076b7d...@postgrespro.ru> > Working on the tests for new SP-GiST opclasses for polygons and > circles, I've > found a bug in the SP-GiST box_ops (added in 9.6): some operators

Re: [HACKERS] pg_hba_file_settings view patch

2017-01-30 Thread Haribabu Kommi
On Mon, Jan 30, 2017 at 5:18 PM, Michael Paquier wrote: > On Mon, Jan 30, 2017 at 11:20 AM, Haribabu Kommi > wrote: > > On Sun, Jan 29, 2017 at 9:18 AM, Tom Lane wrote: > >> tgl wrote: > >> > I spent awhile hacking on

Re: [HACKERS] Supporting huge pages on Windows

2017-01-30 Thread Amit Kapila
On Mon, Jan 30, 2017 at 7:16 AM, Tsunakawa, Takayuki wrote: > From: Amit Kapila [mailto:amit.kapil...@gmail.com] >> Hmm. It doesn't work even on a command prompt with administrative >> privileges. It gives below error: >> >> waiting for server to

Re: [HACKERS] Push down more full joins in postgres_fdw

2017-01-30 Thread Etsuro Fujita
On 2017/01/27 21:25, Etsuro Fujita wrote: On 2017/01/27 20:04, Ashutosh Bapat wrote: I think we should pick up your patch on 27th December, update the comment per your mail on 5th Jan. I will review it once and list down the things left to committer's judgement. Sorry, I started thinking we

[HACKERS] wait events for disk I/O

2017-01-30 Thread Rushabh Lathia
Hi All, Attached is the patch, which extend the existing wait event infrastructure to implement the wait events for the disk I/O. Basically pg_stat_activity's wait event information to show data about disk I/O as well as IPC primitives. Implementation details: - Added PG_WAIT_IO to pgstat.h and

Re: [HACKERS] Parallel Index Scans

2017-01-30 Thread Amit Kapila
On Sat, Jan 28, 2017 at 1:34 AM, Robert Haas wrote: > On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote: >> parallel_index_opt_exec_support_v6 - Removed the usage of >> GatherSupportsBackwardScan. Expanded the comments in >> ExecReScanIndexScan.

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread Christoph Berg
Re: Daniel Verite 2017-01-28 <74e7fd23-f5a9-488d-a8c4-1e0da674b...@manitou-mail.org> > > Mysql's CLI client is using \G for this purpose, and adding the very > > same functionality to psql fits nicely into the set of existing > > backslash commands: \g sends the query buffer, \G will do exactly

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread David G. Johnston
On Mon, Jan 30, 2017 at 8:14 AM, Tom Lane wrote: > Stephen Frost writes: > > This particular bike-shedding really doesn't seem to be terribly useful > > or sensible, to me. \gx isn't "consistent" or "descriptive", frankly. > > Why not? To me it reads as

Re: [HACKERS] Superowners

2017-01-30 Thread Stephen Frost
Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > On 30 January 2017 at 14:43, Stephen Frost wrote: > > > We need to make sure that we're actually talking about the same things > > here, because we've now shifted from ownership-like privileges to those > > privielges

Re: [HACKERS] Deadlock in XLogInsert at AIX

2017-01-30 Thread Heikki Linnakangas
On 01/24/2017 04:47 PM, Konstantin Knizhnik wrote: As I already mentioned, we built Postgres with LOCK_DEBUG , so we can inspect lock owner. Backend is waiting for itself! Now please look at two frames in this stack trace marked with red. XLogInsertRecord is setting WALInsert locks at the

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread Christoph Berg
Re: Tom Lane 2017-01-30 <23622.1485788...@sss.pgh.pa.us> > FWIW, \gx makes sense to me as well, particularly if we make it a > complete extension of \g and allow an optional target file name. > Does that functionality exist in mysql's \G ? MySQL's (5.5 here) \G does not support a filename

Re: [HACKERS] multivariate statistics (v19)

2017-01-30 Thread Alvaro Herrera
Tomas Vondra wrote: > On 01/03/2017 05:22 PM, Tomas Vondra wrote: > > On 01/03/2017 02:42 PM, Dilip Kumar wrote: > ... > > > I think it should be easily reproducible, in case it's not I can send > > > call stack or core dump. > > > > > > > Thanks for the report. It was trivial to reproduce and

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread David G. Johnston
On Mon, Jan 30, 2017 at 8:35 AM, Stephen Frost wrote: > Tom, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > This particular bike-shedding really doesn't seem to be terribly useful > > > or sensible, to me. \gx isn't

Re: [HACKERS] privileges for changing schema owner

2017-01-30 Thread Robert Haas
On Fri, Jan 27, 2017 at 3:42 PM, Peter Eisentraut wrote: > Normally, when changing the owner of an object, we check (among other > things) that the new owner has the same privileges that would be needed > to create the object from scratch. For for example, when

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-01-30 Thread Daniel Verite
Corey Huinker wrote: > > \if ERROR > > \echo X > > \else > > \echo Y > > \endif > > > > having both X & Y printed and error reported on else and endif. I think > > that an expression error should just put the stuff in ignore state. > > > > Not just false, but ignore the

Re: [HACKERS] Superowners

2017-01-30 Thread Peter Eisentraut
On 1/29/17 7:44 PM, Stephen Frost wrote: > I would think we'd either do this with a default role or a role > attribute. That's not how I think about it. I think this would be a separate aclitem[] stored somewhere. The pg_xxx_aclcheck() functions could consult that implicitly. -- Peter

Re: [HACKERS] Superowners

2017-01-30 Thread Tom Lane
Simon Riggs writes: > Agreed. Let me reiterate: all I want in this release is > super-ownership. While I'm not entirely convinced whether super-ownership is a good idea or not, I am pretty sure that rushing to get it into v10 is a bad idea. This is a rather fundamental

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread Stephen Frost
Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > This particular bike-shedding really doesn't seem to be terribly useful > > or sensible, to me. \gx isn't "consistent" or "descriptive", frankly. > > Why not? To me it reads as "\g with an x option".

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread Tom Lane
Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Why not? To me it reads as "\g with an x option". The "x" refers to >> the implied "\x", so it's not an arbitrary choice at all. > That's not how '\dx' works, as I pointed out, so I don't see having the >

Re: [HACKERS] WIP: About CMake v2

2017-01-30 Thread Peter Eisentraut
On 1/30/17 1:28 AM, Andres Freund wrote: > Given that fact, I just don't buy why it's a good idea to not also > replace autoconf initially. Well, I find it a bit scary. If you do the big switch all at once, then you will have to dedicate the following 3 months to fixing complaints from

Re: [HACKERS] Superowners

2017-01-30 Thread Peter Eisentraut
On 1/30/17 9:04 AM, Simon Riggs wrote: > all I want in this release is > super-ownership. What exactly is super-ownership, and what problems does it solve? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-30 Thread Tom Lane
David Rowley writes: > I can make this change, but before I do I just want to point that I > don't think what you've said here is entirely accurate. > Let's assume unique joins are very common place, and join removals are > not so common. If a query has 5 left

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread Stephen Frost
David, * David G. Johnston (david.g.johns...@gmail.com) wrote: > On Mon, Jan 30, 2017 at 8:35 AM, Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > Stephen Frost writes: > > > > This particular bike-shedding really doesn't seem to be

Re: [HACKERS] multivariate statistics (v19)

2017-01-30 Thread Alvaro Herrera
Minor nitpicks: Let me suggest to use get_attnum() in CreateStatistics instead of SearchSysCacheAttName for each column. Also, we use type AttrNumber for attribute numbers rather than int16. Finally in the same function you have an erroneous ERRCODE_UNDEFINED_COLUMN which should be

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-01-30 Thread Fabien COELHO
Hello Daniel, [...] So psql is not following that model with ON_ERROR_STOP if it exits with an error when unable to evaluate an "if" expression. I'm not implying that we should necessarily adopt the shell behavior, but as these choices have certainly been made in POSIX for good reasons, we

Re: [HACKERS] sequence data type

2017-01-30 Thread Peter Eisentraut
On 1/30/17 12:42 AM, Michael Paquier wrote: > Sure. Thanks for looking into that and getting a patch out. Oh, I have > just noticed that sequence_1.out has been removed by 9c18104c. That's > nice. > Looking at the patch adding some new tests, the coverage really > increases (I did not run make

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

2017-01-30 Thread Pavan Deolasee
On Wed, Jan 25, 2017 at 10:06 PM, Alvaro Herrera wrote: > Reading 0001_track_root_lp_v9.patch again: > > Thanks for the review. > > +/* > > + * We use the same HEAP_LATEST_TUPLE flag to check if the tuple's > t_ctid field > > + * contains the root line pointer. We

Re: [HACKERS] Improvements in psql hooks for variables

2017-01-30 Thread Tom Lane
BTW, while testing this patch I noticed that the error reports are a tad redundant: regression=# \set AUTOCOMMIT foo unrecognized value "foo" for "AUTOCOMMIT": boolean expected \set: error while setting variable regression=# The "error while setting variable" message seems entirely

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

2017-01-30 Thread Alvaro Herrera
Pavan Deolasee wrote: > On Wed, Jan 25, 2017 at 10:06 PM, Alvaro Herrera > wrote: > > > +( \ > > > + ((tup)->t_infomask2 & HEAP_LATEST_TUPLE) != 0 \ > > > +) > > > > > > +#define HeapTupleHeaderGetRootOffset(tup) \ > > > +( \ > > > +

Re: [HACKERS] Checksums by default?

2017-01-30 Thread David Steele
On 1/25/17 10:38 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Wed, Jan 25, 2017 at 7:37 PM, Andres Freund wrote: >>> On 2017-01-25 19:30:08 -0500, Stephen Frost wrote: * Peter Geoghegan (p...@heroku.com) wrote: > On Wed, Jan 25, 2017

Re: [HACKERS] Subtle bug in "Simplify tape block format" commit

2017-01-30 Thread Peter Geoghegan
On Mon, Jan 30, 2017 at 4:04 AM, Heikki Linnakangas wrote: > Hmm. The LogicalTapeEndWriting() function is very similar to the > LogicalTapePause() function I had in the pause/resume patch. They both flush > the last block to disk. The difference is that LogicalTapePause() also >

Re: [HACKERS] Improvements in psql hooks for variables

2017-01-30 Thread Tom Lane
Rahila Syed writes: > Please consider following comments on the patch. > In function ParseVariableNum, >> if (!val || !val[0]) >> return false; > Check for 'val == NULL' as in above condition is done even in callers of > ParseVariableNum(). > There should be

Re: [HACKERS] COPY as a set returning function

2017-01-30 Thread Corey Huinker
On Fri, Jan 27, 2017 at 9:42 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 1/25/17 8:51 PM, Corey Huinker wrote: > > # select * from copy_srf('echo "x\ty"',true) as t(x text, y text); > > I find these parameters weird. Just looking at this, one has no idea > what the

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-30 Thread David Fetter
On Mon, Jan 30, 2017 at 08:22:40AM -0700, David G. Johnston wrote: > On Mon, Jan 30, 2017 at 8:14 AM, Tom Lane wrote: > > Stephen Frost writes: > > > This particular bike-shedding really doesn't seem to be terribly useful > > > or sensible, to me. \gx

Re: [HACKERS] [PATCH]: fix bug in SP-GiST box_ops

2017-01-30 Thread Nikita Glukhov
On 30.01.2017 12:04, Kyotaro HORIGUCHI wrote: Hello, At Mon, 30 Jan 2017 07:12:03 +0300, Nikita Glukhov wrote in <9ea5b157-478c-8874-bc9b-050076b7d...@postgrespro.ru>: Working on the tests for new SP-GiST opclasses for polygons and circles, I've found a bug in the

Re: [HACKERS] Speedup twophase transactions

2017-01-30 Thread Nikhil Sontakke
> --- a/src/backend/access/transam/xlog.c > +++ b/src/backend/access/transam/xlog.c > @@ -9573,6 +9573,7 @@ xlog_redo(XLogReaderState *record) > (errmsg("unexpected timeline ID %u (should be %u) > in checkpoint record", > checkPoint.ThisTimeLineID,

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

2017-01-30 Thread Pavan Deolasee
On Thu, Jan 26, 2017 at 2:38 AM, Alvaro Herrera wrote: > Looking at your 0002 patch now. It no longer applies, but the conflicts > are trivial to fix. Please rebase and resubmit. > > Thanks. > > Maybe I will spend some time trying to > convert it to Perl using

Re: [HACKERS] Subtle bug in "Simplify tape block format" commit

2017-01-30 Thread Heikki Linnakangas
On 01/30/2017 07:45 PM, Peter Geoghegan wrote: On Mon, Jan 30, 2017 at 4:04 AM, Heikki Linnakangas wrote: Alternatively, we could fix this with a small change in ltsWriteBlock(), see attached patch. When we're about to create a hole in the file, write all-zero blocks to avoid

Re: [HACKERS] Subtle bug in "Simplify tape block format" commit

2017-01-30 Thread Peter Geoghegan
On Mon, Jan 30, 2017 at 9:55 AM, Heikki Linnakangas wrote: > It won't make any difference for correctness what bit pattern you write to > "fill the hole", but you have to write something, and zeros seems like a > natural choice. Ah, okay. That's probably fine, then. Let me take

Re: [HACKERS] Proposal : For Auto-Prewarm.

2017-01-30 Thread Robert Haas
On Fri, Jan 27, 2017 at 5:34 PM, Jim Nasby wrote: > On 1/26/17 10:11 PM, Beena Emerson wrote: >> In that case, we could add the file location parameter. By default it >> would store in the cluster directory else in the location provided. We >> can update this parameter

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-30 Thread Tom Lane
David Rowley writes: > On 31 January 2017 at 04:56, Tom Lane wrote: >> I'm not following. If the join removal code had reached the stage of >> making a uniqueness check, and that check had succeeded, the join would be >> gone and there would be

Re: [HACKERS] Declarative partitioning - another take

2017-01-30 Thread Peter Eisentraut
On 1/25/17 12:54 AM, Ashutosh Bapat wrote: > The documentation available at > https://www.postgresql.org/docs/devel/static/sql-createtable.html, > does not make it clear that the lower bound of a range partition is > always inclusive and the higher one is exclusive. I think a note in > section "

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

2017-01-30 Thread Andres Freund
Hi, On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote: > Consider the below test; > > CREATE TABLE tab ( a int primary key); > > SELECT * > FROM pg_constraint pc, > CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, > array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

2017-01-30 Thread Tom Lane
Andres Freund writes: > On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote: >> SELECT * >> FROM pg_constraint pc, >> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, >> array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position; >> >> Above query is

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

2017-01-30 Thread Andres Freund
Hi, On 2017-01-30 16:55:56 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote: > >> SELECT * > >> FROM pg_constraint pc, > >> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, > >> array_upper(pc.conkey, 1))

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

2017-01-30 Thread Tom Lane
Andres Freund writes: > On 2017-01-30 16:55:56 -0500, Tom Lane wrote: >> No, but it allows whatever looks syntactically like a function, including >> casts. IIRC, we made func_expr work that way ages ago to deflect >> complaints that it wasn't very clear why some

Re: [HACKERS] [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

2017-01-30 Thread Stephen Frost
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > > This will be undone by the next perltidy run. > > > > Ugh. > > > > I certainly hope what was there before wasn't the result of a perltidy > > run as it was

Re: [HACKERS] multivariate statistics (v19)

2017-01-30 Thread Tomas Vondra
Hello, On 01/26/2017 10:03 AM, Ideriha, Takeshi wrote: Though I pointed out these typoes and so on, I believe these feedback are less priority compared to the source code itself. So please work on my feedback if you have time. I think getting the comments (and docs in general) right is

Re: [HACKERS] [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

2017-01-30 Thread Stephen Frost
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > > This will be undone by the next perltidy run. > > > > Ugh. > > > > I certainly hope what was there before wasn't the result of a perltidy > > run as it was

Re: [HACKERS] Improvements in psql hooks for variables

2017-01-30 Thread Tom Lane
I wrote: > Rahila Syed writes: >>> +* Switching AUTOCOMMIT from OFF to ON is not allowed when inside a >>> +* transaction, because it cannot be effective until the current >>> +* transaction is ended. >> The above change in autocommit behaviour

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-30 Thread David Rowley
On 31 January 2017 at 04:56, Tom Lane wrote: > David Rowley writes: >> I can make this change, but before I do I just want to point that I >> don't think what you've said here is entirely accurate. > >> Let's assume unique joins are very common

Re: [HACKERS] multivariate statistics (v19)

2017-01-30 Thread Tomas Vondra
On 01/30/2017 09:37 PM, Alvaro Herrera wrote: Tomas Vondra wrote: The 'built' flags may be easily replaced with a check if the bytea-like columns are NULL, and the 'enabled' columns may be replaced by the array of char, just like you proposed. That'd give us a single catalog looking like

Re: [HACKERS] patch: function xmltable

2017-01-30 Thread Alvaro Herrera
Pavel Stehule wrote: > I am sending new version - it is based on own executor scan node and > tuplestore. > > Some now obsolete regress tests removed, some new added. > > The executor code (memory context usage) should be cleaned little bit - but > other code should be good. I think you forgot

Re: [HACKERS] multivariate statistics (v19)

2017-01-30 Thread Alvaro Herrera
Tomas Vondra wrote: > The 'built' flags may be easily replaced with a check if the bytea-like > columns are NULL, and the 'enabled' columns may be replaced by the array of > char, just like you proposed. > > That'd give us a single catalog looking like this: > > pg_mv_statistics > starelid >

Re: [HACKERS] multivariate statistics (v19)

2017-01-30 Thread Tomas Vondra
On 01/26/2017 10:43 AM, Dilip Kumar wrote: histograms -- + if (matches[i] == MVSTATS_MATCH_FULL) + s += mvhist->buckets[i]->ntuples; + else if (matches[i] == MVSTATS_MATCH_PARTIAL) + s += 0.5 * mvhist->buckets[i]->ntuples; Isn't it will be better that take some percentage of the

Re: [HACKERS] [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

2017-01-30 Thread Alvaro Herrera
Stephen Frost wrote: > Uh, after finding our perltidyrc and running with that, I have to ask, > why are we setting vertical-tightness to 2 (never break before a closing > token)? The default of 0 (always break) end up being a lot nicer when > working on lists. Stacking isolated opening/closing

Re: [HACKERS] patch: function xmltable

2017-01-30 Thread Pavel Stehule
Hi 2017-01-30 20:38 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > > I am sending new version - it is based on own executor scan node and > > tuplestore. > > > > Some now obsolete regress tests removed, some new added. > > > > The executor code (memory context

Re: [HACKERS] multivariate statistics (v19)

2017-01-30 Thread Tomas Vondra
On 01/30/2017 05:12 PM, Alvaro Herrera wrote: > Hmm. So we have a catalog pg_mv_statistics which stores two things: 1. the configuration regarding mvstats that have been requested by user via CREATE/ALTER STATISTICS 2. the actual values captured from the above, via ANALYZE I think this

Re: [HACKERS] VACUUM's ancillary tasks

2017-01-30 Thread Alvaro Herrera
Thomas Munro wrote: > About BRIN indexes: I couldn't find an explanation of why BRIN > indexes don't automatically create new summary tuples when you insert > a new tuple in an unsummarised page range. Is it deferred until > VACUUM time in order to untangle some otherwise unresolvable >

Re: [HACKERS] patch: function xmltable

2017-01-30 Thread Pavel Stehule
Hi 2017-01-25 15:07 GMT+01:00 Alvaro Herrera : > Tom Lane wrote: > > Andres Freund writes: > > > On 2017-01-24 21:32:56 -0300, Alvaro Herrera wrote: > > >> XMLTABLE is specified by the standard to return multiple rows ... but > > >> then as far as

Re: [HACKERS] multivariate statistics (v19)

2017-01-30 Thread Tomas Vondra
On 01/30/2017 05:55 PM, Alvaro Herrera wrote: Minor nitpicks: Let me suggest to use get_attnum() in CreateStatistics instead of SearchSysCacheAttName for each column. Also, we use type AttrNumber for attribute numbers rather than int16. Finally in the same function you have an erroneous

Re: [HACKERS] patch proposal

2017-01-30 Thread David Steele
On 1/27/17 3:19 AM, Venkata B Nagothi wrote: > I will be adding the tests in > src/test/recovery/t/003_recovery_targets.pl > . My tests would look more or less > similar to recovery_target_action. I do not see any of the tests added > for the parameter

Re: [HACKERS] pg_hba_file_settings view patch

2017-01-30 Thread Tom Lane
Haribabu Kommi writes: > On Mon, Jan 30, 2017 at 5:18 PM, Michael Paquier > wrote: >> #define USER_AUTH_LAST uaPeer >> StaticAssertStmt(lengthof(UserAuthName) == USER_AUTH_LAST + 1, >> "UserAuthName must include all user authentication

Re: [HACKERS] patch proposal

2017-01-30 Thread Michael Paquier
On Tue, Jan 31, 2017 at 4:49 AM, David Steele wrote: > On 1/27/17 3:19 AM, Venkata B Nagothi wrote: >> I have split the patch into two different >> pieces. One is to determine if the recovery can start at all and other >> patch deals with the incomplete recovery situation. >

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

2017-01-30 Thread Andres Freund
On 2017-01-30 17:24:31 -0500, Tom Lane wrote: > Make it work like Agg and WindowFunc. To wit, dump the actually special > function calls (the set-returning functions) into a list that's internal > to the FunctionScan node, and then anything above those goes into scalar > expressions in the node's

Re: [HACKERS] Subtle bug in "Simplify tape block format" commit

2017-01-30 Thread Peter Geoghegan
On Mon, Jan 30, 2017 at 10:01 AM, Peter Geoghegan wrote: > Let me take another look at this later today before proceeding. I want > to run it against a custom test suite I've developed. I've done so. Some more thoughts: * I don't think that this is really any less efficient than

Re: [HACKERS] Improvements in psql hooks for variables

2017-01-30 Thread Tom Lane
So I pushed this, and the buildfarm members that are testing RedisFDW immediately fell over: *** /home/andrew/bf/root/HEAD/redis_fdw.build/test/expected/redis_fdw.out 2017-01-30 18:20:27.440677318 -0500 --- /home/andrew/bf/root/HEAD/redis_fdw.build/test/results/redis_fdw.out

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-30 Thread David Rowley
On 31 January 2017 at 13:10, David Rowley wrote: > I've attached a patch which implements this. Please disregards previous patch. (I forgot git commit before git diff to make the patch) I've attached the correct patch. -- David Rowley

[HACKERS] [PATCH] kNN for SP-GiST

2017-01-30 Thread Nikita Glukhov
Hello hackers, I'd like to present a series of patches which is a continuation of Vlad Sterzhanov's work on kNN for SP-GiST that was done for GSOC'14. Original thread: "KNN searches support for SP-GiST [GSOC'14]"

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

2017-01-30 Thread Tom Lane
Andres Freund writes: > Wonder if we there's an argument to be made for implementing this > roughly similarly to split_pathtarget_at_srf - instead of injecting a > ProjectSet node we'd add a FunctionScan node below a Result node. Yeah, possibly. That would have the advantage

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-30 Thread David Rowley
On 28 January 2017 at 05:44, Tom Lane wrote: > I wrote: >> David Rowley writes: >>> hmm. I'm having trouble understanding why this is a problem for Unique >>> joins, but not for join removal? > >> Ah, you know what, that's just mistaken. I was

Re: [HACKERS] Improvements in psql hooks for variables

2017-01-30 Thread Daniel Verite
Tom Lane wrote: > Also, if you want to argue that allowing it to change intra- > transaction is too confusing, why would we only forbid this direction > of change and not both directions? The thread "Surprising behaviour of \set AUTOCOMMIT ON" at:

Re: [HACKERS] Improvements in psql hooks for variables

2017-01-30 Thread Daniel Verite
Tom Lane wrote: > Evidently, this test script is relying on the preceding behavior that > setting a bool variable to an empty string was equivalent to setting > it to "true". If it's just that script I would be okay with saying > "well, it's a bug in that script" ... but I'm a bit

Re: [HACKERS] Improvements in psql hooks for variables

2017-01-30 Thread Tom Lane
"Daniel Verite" writes: > Tom Lane wrote: >> Evidently, this test script is relying on the preceding behavior that >> setting a bool variable to an empty string was equivalent to setting >> it to "true". If it's just that script I would be okay with saying >>

Re: [HACKERS] Allow interrupts on waiting standby

2017-01-30 Thread Michael Paquier
On Fri, Jan 27, 2017 at 10:17 PM, Michael Paquier wrote: > Two things I forgot in this patch: > - documentation for the new wait event > - the string for the wait event or this would show up as "???" in > pg_stat_activity. > There are no default clauses in the

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

2017-01-30 Thread Claudio Freire
On Mon, Jan 30, 2017 at 5:51 AM, Masahiko Sawada wrote: > > * We are willing to use at most maintenance_work_mem (or perhaps > * autovacuum_work_mem) memory space to keep track of dead tuples. We > * initially allocate an array of TIDs of that size, with an upper

Re: [HACKERS] Potential data loss of 2PC files

2017-01-30 Thread Michael Paquier
On Fri, Jan 6, 2017 at 9:26 PM, Ashutosh Bapat wrote: > On Wed, Jan 4, 2017 at 12:16 PM, Michael Paquier > wrote: >> On Wed, Jan 4, 2017 at 1:23 PM, Ashutosh Bapat >> wrote: >>> I don't have anything

Re: [HACKERS] Potential data loss of 2PC files

2017-01-30 Thread Michael Paquier
On Mon, Jan 30, 2017 at 10:52 PM, Heikki Linnakangas wrote: > So, if I understood correctly, the problem scenario is: > > 1. Create and write to a file. > 2. fsync() the file. > 3. Crash. > 4. After restart, the file is gone. Yes, that's a problem with fsync's durability, and we

  1   2   >