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

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] COPY as a set returning function

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] Subtle bug in "Simplify tape block format" commit

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.

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] Subtle bug in "Simplify tape block format" commit

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] Patch: Write Amplification Reduction Method (WARM)

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] Improvements in psql hooks for variables

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] Patch: Write Amplification Reduction Method (WARM)

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] Subtle bug in "Simplify tape block format" commit

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: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

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

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] Checksums by default?

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] One-shot expanded output in psql using \G

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: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

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] multivariate statistics (v19)

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: [HACKERS] privileges for changing schema owner

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: [HACKERS] Deadlock in XLogInsert at AIX

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] multivariate statistics (v19)

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

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] One-shot expanded output in psql using \G

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] Performance improvement for joins where outer side is unique

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] Superowners

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

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] One-shot expanded output in psql using \G

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] One-shot expanded output in psql using \G

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] Superowners

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] Superowners

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] Superowners

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] WIP: About CMake v2

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] One-shot expanded output in psql using \G

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] One-shot expanded output in psql using \G

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] One-shot expanded output in psql using \G

* 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] One-shot expanded output in psql using \G

"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

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] Superowners

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

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

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] Deadlock in XLogInsert at AIX

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

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] Potential data loss of 2PC files

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.

[HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

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] One-shot expanded output in psql using \G

* 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

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

[HACKERS] wait events for disk I/O

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] pg_hba_file_settings view patch

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

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] Push down more full joins in postgres_fdw

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] Subtle bug in "Simplify tape block format" commit

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

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

Re: [HACKERS] Parallel Index-only scan

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] [PATCH] Rename pg_switch_xlog to pg_switch_wal

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] Superowners

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] Supporting huge pages on Windows

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] Should we cacheline align PGXACT?

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] One-shot expanded output in psql using \G

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] Parallel Index Scans

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] [PATCH]: fix bug in SP-GiST box_ops

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] Vacuum: allow usage of more than 1GB of work mem

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

<    1   2