Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Tue, Dec 20, 2016 at 10:47 AM, Michael Paquier wrote: > And Heikki has mentioned me that he'd prefer not having an extra > dependency for the normalization, which is LGPL-licensed by the way. > So I have looked at the SASLprep business to see what should be done > to

Re: [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG

On Fri, Jan 6, 2017 at 6:10 PM, Ideriha, Takeshi wrote: > Hi > Thank you for looking over my patch. > >> Thank you. Would it be possible for you to re-create the patch without the >> white-space changes? > > I'm sorry for adding redundant white-spaces. > Attached

Re: [HACKERS] Cache Hash Index meta page.

On Tue, Jan 17, 2017 at 10:07 AM, Amit Kapila wrote: > 1. > (a) I think you can retain the previous comment or modify it slightly. > Just removing the whole comment and replacing it with a single line > seems like a step backward. -- Fixed, Just modified to say it > (b)

Re: [HACKERS] Parallel Index Scans

>+ /* Check if the scan for current scan keys is finished */ >+ if (so->arrayKeyCount < btscan->btps_arrayKeyCount) >+ *status = false; >I didn't clearly understand, in which scenario the arrayKeyCount is less >than btps_arrayKeyCount? Consider following array scan keys select * from test2 where

Re: [HACKERS] Gather Merge

On Tue, Jan 17, 2017 at 6:44 PM, Amit Kapila wrote: > On Tue, Jan 17, 2017 at 5:19 PM, Rushabh Lathia > wrote: > > > > > > > > Here is the benchmark number which I got with the latest (v6) patch: > > > > - max_worker_processes = DEFAULT (8) > >

Re: [HACKERS] pg_hba_file_settings view patch

On Tue, Jan 17, 2017 at 5:24 PM, Michael Paquier wrote: > On Tue, Jan 17, 2017 at 10:19 AM, Haribabu Kommi > wrote: > > On Tue, Jan 10, 2017 at 6:35 PM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> +/* LDAP supports 10

Re: [HACKERS] RustgreSQL

On Mon, Jan 09, 2017 at 12:51:43PM -0500, Robert Haas wrote: > On Sun, Jan 8, 2017 at 4:59 AM, Gavin Flower > wrote: > >> Is this completely unrealistic or is it carved in stone PostgreSQL will > >> always be a C project forever and ever? > >> > > From my very

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

On Wed, Jan 18, 2017 at 10:55 AM, Michael Paquier wrote: > On Sun, Jan 8, 2017 at 10:55 AM, Tom Lane wrote: >> Ashutosh Bapat writes: >>> On Tue, Jan 3, 2017 at 5:57 PM, Rahila Syed wrote:

Re: [HACKERS] [COMMITTERS] pgsql: Fix cardinality estimates for parallel joins.

On Mon, Jan 16, 2017 at 7:23 AM, Amit Kapila wrote: > On Sat, Jan 14, 2017 at 12:07 AM, Robert Haas wrote: >> Fix cardinality estimates for parallel joins. >> > > + /* > +* In the case of a parallel plan, the row count needs to

Re: [HACKERS] Logical Replication WIP

On 1/15/17 1:48 PM, Petr Jelinek wrote: > It's meant to decouple the synchronous commit setting for logical > replication workers from the one set for normal clients. Now that we > have owners for subscription and subscription runs as that owner, maybe > we could do that via ALTER USER. I was

Re: [HACKERS] PoC: Grouped base relation

Ashutosh Bapat wrote: > [... snip ]] > > This all works well, as long as the aggregate is "summing" something > across rows. The method doesn't work when aggregation is say > "multiplying" across the rows or "concatenating" across the rows like > array_agg() or

Re: [HACKERS] Declarative partitioning - another take

On Mon, Jan 16, 2017 at 4:09 AM, Amit Langote wrote: > The problem is that whereas the SlotValueDescription that we build to show > in the error message should be based on the tuple that was passed to > ExecInsert() or whatever NextCopyFrom() returned for CopyFrom()

Re: [HACKERS] Hash support for grouping sets

On Mon, Jan 16, 2017 at 10:59 AM, Finnerty, Jim wrote: > The ability to exploit hashed aggregation within sorted groups, when the > order of the input stream can be exploited this way, is potentially a useful > way to improve aggregation performance more generally. This

Re: [HACKERS] Logical Replication WIP

On 1/15/17 2:28 PM, Petr Jelinek wrote: > Well the preinstalled information_schema is excluded by the > FirstNormalObjectId filter as it's created by initdb. If user drops and > recreates it that means it was created as user object. > > My opinion is that FOR ALL TABLES should replicate all user

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On 1/15/17 11:40 PM, Fujii Masao wrote: > This change may confuse the users who run "pg_ctl start" to perform a crash > recovery, archive recovery and standby server (with hot_standby=off) because > "pg_ctl start" would not return so long time. Well, this change was made because the previous

Re: [HACKERS] ISO/IEC 9075-2:2016 for postgres community

On Tue, Jan 17, 2017 at 6:26 PM, Alvaro Herrera wrote: > Oleg Bartunov wrote: > > Hi there, > > > > I just bought ISO/IEC 9075-2:2016 > > http://www.iso.org/iso/home/store/catalogue_tc/catalogue_ > detail.htm?csnumber=63556 > > to satisfy my interest on json support in

Re: [HACKERS] New CORRESPONDING clause design

On Tue, Jan 17, 2017 at 08:20:25AM -0600, Merlin Moncure wrote: > On Tue, Jan 17, 2017 at 12:37 AM, Surafel Temsgen > wrote: > > I am new here and I really want to contribute, I have read same resource > > that help understanding database system and postgresql. I would

Re: [HACKERS] Logical Replication WIP

On 17/01/17 17:09, Peter Eisentraut wrote: > >> Yes, that will need some discussion about corner case behaviour. For >> example, have partitioned table 'foo' which is in publication, then you >> have table 'bar' which is not in publication, you attach it to the >> partitioned table 'foo', should

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

On 1/13/17 10:18 AM, Stephen Frost wrote: > The point I was making was that serious montioring systems would have to > be changed and I stand by that. I don't think my monitoring systems are any less serious than yours. > Certainly, check_postgres is going to have to be changed to address this >

Re: [HACKERS] Logical Replication WIP

On 17/01/17 17:11, Peter Eisentraut wrote: > On 1/15/17 1:48 PM, Petr Jelinek wrote: >> It's meant to decouple the synchronous commit setting for logical >> replication workers from the one set for normal clients. Now that we >> have owners for subscription and subscription runs as that owner,

Re: [HACKERS] Logical Replication WIP

On 1/15/17 5:20 PM, Petr Jelinek wrote: > Well, it's 4 because max_worker_processes is 8, I think default > max_worker_processes should be higher than > max_logical_replication_workers so that's why I picked 4. If we are okay > wit bumping the max_worker_processes a bit, I am all for increasing >

Re: [HACKERS] New CORRESPONDING clause design

Surafel Temsgen writes: > My design is > *In parsing stage* > 1. Check at least one common column name appear in queries > 2. If corresponding column list is not specified, then make corresponding > list from common column name in queries target lists in the order >

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

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/13/17 10:18 AM, Stephen Frost wrote: > > Certainly, check_postgres is going to have to be changed to address this > > and, unsurprisingly, it's already had to address a variety of major > > version differences that have

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

Reading through the track_root_lp patch now. > + /* > + * For HOT (or WARM) updated tuples, we store the offset of the > root > + * line pointer of this chain in the ip_posid field of the new > tuple. > + * Usually this information will be

Re: [HACKERS] GSoC 2017

I'm ready to be a mentor. 10.01.2017 12:53, Alexander Korotkov: Hi all! In 2016 PostgreSQL project didn't pass to GSoC program. In my understanding the reasons for that are following. 1. We did last-minute submission of our application to GSoC. 2. In 2016 GSoC application form for

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

On Mon, Jan 16, 2017 at 2:13 PM, Tom Lane wrote: > Andres Freund writes: >> That worked quite well. So we have a few questions, before I clean this >> up: > >> - For now the node is named 'Srf' both internally and in explain - not >> sure if we want to

Re: [HACKERS] move collation import to backend

On 1/9/17 10:04 PM, Euler Taveira wrote: > On 18-12-2016 18:30, Peter Eisentraut wrote: >> Updated patch with that fix. >> > Peter, I reviewed and improved your patch. > > * I document the new function. Since collation is a database object, I > chose "Database Object Management Functions"

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

On 2017-01-17 13:43:38 -0500, Tom Lane wrote: > Although ... looking closer at Andres' patch, the new node type *is* > channeling Result, in the sense that it might or might not have any input > plan. This probably traces to what I wrote in September: > > + * XXX Possibly-temporary hack: if

Re: [HACKERS] Packages: Again

On Fri, Jan 13, 2017 at 7:24 PM, Peter Geoghegan wrote: > MERGE isn't UPSERT, and isn't even in competition with UPSERT as a > feature. I've written reams of text explaining why this is so in > precise detail, ... No matter how much text you write, I doubt that I will ever

Re: [HACKERS] Patch to implement pg_current_logfile() function

Le 17/01/2017 à 03:22, Michael Paquier a écrit : > On Tue, Jan 17, 2017 at 2:21 AM, Karl O. Pinc wrote: >> On January 15, 2017 11:47:51 PM CST, Michael Paquier >> wrote: >>> On Mon, Jan 16, 2017 at 1:14 PM, Karl O. Pinc wrote: >>> With

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

Andres Freund writes: > I'd not have gone for SetResult if we didn't already have Result. I'm > not super happy ending up having Project in ProjectSet but not in the > Result that end up doing the majority of the projection. But eh, we can > live with it. Using Result for

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Tue, 17 Jan 2017 19:06:22 +0100 Gilles Darold wrote: > Le 17/01/2017 à 03:22, Michael Paquier a écrit : > > On Tue, Jan 17, 2017 at 2:21 AM, Karl O. Pinc > > wrote: > >> On January 15, 2017 11:47:51 PM CST, Michael Paquier > >>

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

Andres Freund writes: > On 2017-01-17 13:43:38 -0500, Tom Lane wrote: >> I'm not convinced that that optimization is worth preserving, but if we >> keep it then ProjectSet isn't le mot juste here, any more than you'd want >> to rename Result to Project without changing its

Re: [HACKERS] Parallel Index Scans

On Mon, Jan 16, 2017 at 7:11 AM, Amit Kapila wrote: > Fixed. Thanks for the update. Some more comments: It shouldn't be necessary for MultiExecBitmapIndexScan to modify the IndexScanDesc. That seems really broken. If a parallel scan isn't supported here (and I'm sure

Re: [HACKERS] patch: function xmltable

2017-01-16 23:51 GMT+01:00 Alvaro Herrera : > Given > https://www.postgresql.org/message-id/20170116210019. > a3glfwspg5lnf...@alap3.anarazel.de > which is going to heavily change how the executor works in this area, I > am returning this patch to you again. I would

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Sat, Jan 14, 2017 at 12:22 AM, Tom Lane wrote: > > $ cat loop.sql > \if :x < 1000 > \echo :x > \set x :x + 1 > \include loop.sql > \fi > $ psql --set x=0 -f loop.sql > > Somebody is going to think of that workaround for not having loops, and > then whine about how

Re: [HACKERS] PoC: Grouped base relation

[ Trying to respond to both Tomas and David. I'll check tomorrow if anything else of the thread needs my comment. ] Tomas Vondra wrote: > On 01/17/2017 12:42 AM, David Rowley wrote: > > On 10 January 2017 at 06:56, Antonin Houska wrote: > > I've

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

On Tue, Jan 17, 2017 at 1:18 PM, Tom Lane wrote: > Andres Freund writes: >> I'd not have gone for SetResult if we didn't already have Result. I'm >> not super happy ending up having Project in ProjectSet but not in the >> Result that end up doing the

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

On Tue, Jan 17, 2017 at 12:52 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jan 16, 2017 at 2:13 PM, Tom Lane wrote: >>> "Srf" is ugly as can be, and unintelligible. SetResult might be OK. > >> The operation we're performing

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

Robert Haas writes: > On Tue, Jan 17, 2017 at 1:18 PM, Tom Lane wrote: >> Using Result for two completely different things is a wart though. If we >> had it to do over I think we'd define Result as a scan node that produces >> rows from no input, and

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

Robert Haas writes: > On Mon, Jan 16, 2017 at 2:13 PM, Tom Lane wrote: >> "Srf" is ugly as can be, and unintelligible. SetResult might be OK. > The operation we're performing here, IIUC, is projection. SetResult > lacks a verb, although Set could be

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

Hi, On 2017-01-17 12:52:20 -0500, Tom Lane wrote: > Robert Haas writes: > > On Mon, Jan 16, 2017 at 2:13 PM, Tom Lane wrote: > >> "Srf" is ugly as can be, and unintelligible. SetResult might be OK. > > > The operation we're performing here, IIUC, is

Re: [HACKERS] Gather Merge

On Tue, Jan 17, 2017 at 4:26 AM, Rushabh Lathia wrote: > Another observation is, HashAggregate (case 1) is performs better compare to > GroupAggregate (case 2), but still it doesn't justify the cost difference of > those two. It may not be the only issue, or even the

Re: [HACKERS] DROP FUNCTION of multiple functions

On 1/10/17 1:52 AM, Michael Paquier wrote: > I don't see any problems with 0001. I was wondering, should we rename funcname -> name, and funcargs -> args, or perhaps the whole FuncWithArgs struct, so there is no confusion when used with operators? In 0002, the comment of >

Re: [HACKERS] ISO/IEC 9075-2:2016 for postgres community

Oleg Bartunov wrote: > Hi there, > > I just bought ISO/IEC 9075-2:2016 > http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63556 > to satisfy my interest on json support in SQL. I am not ready to discuss > here implementation details, but there is one problem with the

Re: [HACKERS] generating fmgr prototypes automatically

On 1/5/17 12:24 PM, Pavel Stehule wrote: > I checked last set of patches and I didn't find any issue. > > There are no problems with patching, compilation and all regress tests > passed. > > I'll mark this patch as ready for commiter This has been committed. -- Peter Eisentraut

Re: [HACKERS] [COMMITTERS] pgsql: Generate fmgr prototypes automatically

Tom Lane wrote: > Alternatively ... is there a specific reason why you chose to make > builtins.h the key inclusion file for this change, rather than having > callers include fmgrprotos.h directly? It seems like the stuff remaining > in builtins.h is just a laundry list of random utility

Re: [HACKERS] Improving RLS planning

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Here's an updated version of the RLS planning patch that gets rid of > >> the incorrect interaction with Query.hasRowSecurity and adjusts > >> terminology as

Re: [HACKERS] PoC: Grouped base relation

On 01/17/2017 08:05 PM, Antonin Houska wrote: [ Trying to respond to both Tomas and David. I'll check tomorrow if anything else of the thread needs my comment. ] Tomas Vondra wrote: On 01/17/2017 12:42 AM, David Rowley wrote: On 10 January 2017 at 06:56,

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

* Robert Haas (robertmh...@gmail.com) wrote: > I'm OK with continuing to use "xlog" as the user-facing name for the > write-ahead log, and I am OK with switching to wal. But leaving > things in the halfway in-between state where they are right now seems > like a mess. It conveniences the people

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Fri, Jan 13, 2017 at 10:58 AM, Dilip Kumar wrote: > If you execute the query with EXECUTE then commandTag will be EXECUTE > that way we will not show the actual query type, I mean all the > statements will get the common tag "EXECUTE". Somebody might say that's a

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On Tue, Jan 17, 2017 at 11:27 AM, Peter Eisentraut wrote: > On 1/15/17 11:40 PM, Fujii Masao wrote: >> This change may confuse the users who run "pg_ctl start" to perform a crash >> recovery, archive recovery and standby server (with hot_standby=off) because >>

Re: [HACKERS] Logical Replication WIP

On Tue, Jan 17, 2017 at 11:15 AM, Petr Jelinek wrote: >> Is there anything stopping anyone from implementing it? > > No, just didn't seem priority for the functionality right now. Why is it OK for this to not support rename like everything else does? It shouldn't

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Jan 17, 2017 at 11:27 AM, Peter Eisentraut > wrote: > > On 1/15/17 11:40 PM, Fujii Masao wrote: > >> This change may confuse the users who run "pg_ctl start" to perform a crash > >> recovery, archive recovery

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On 1/3/17 9:09 AM, Heikki Linnakangas wrote: > Since not everyone agrees with this approach, I split this patch into > two. The first patch refactors things, replacing the isMD5() function > with get_password_type(), without changing the representation of > pg_authid.rolpassword. That is

Re: [HACKERS] Patch to implement pg_current_logfile() function

Le 17/01/2017 à 19:58, Karl O. Pinc a écrit : > On Tue, 17 Jan 2017 19:06:22 +0100 > Gilles Darold wrote: > >> Le 17/01/2017 à 03:22, Michael Paquier a écrit : >>> On Tue, Jan 17, 2017 at 2:21 AM, Karl O. Pinc >>> wrote: On January 15, 2017

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On Tue, Jan 17, 2017 at 4:46 PM, Stephen Frost wrote: >> But what if we're restarting after, say, rebooting? Then there's >> nobody to see the progress messages, perhaps. The system just seems >> to take an eternity to return to the usual runlevel. > > Not unlike an fsck.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix an assertion failure related to an exclusive backup.

On Tue, Jan 17, 2017 at 11:42 PM, Fujii Masao wrote: > With the patch, what happens if pg_stop_backup exits with an error > after removing backup_label file before resetting the backup state > to none? Removing the backup_label file is the last error that can happen during

Re: [HACKERS] [COMMITTERS] pgsql: Generate fmgr prototypes automatically

Alvaro Herrera wrote: > It is possible to replace many occurrences of builtins.h with > fmgrprotos.h. I just tried this >git grep -l 'include.*utils/builtins.h' -- *.c | xargs perl -pi -e > 's{utils/builtins.h}{utils/fmgrprotos.h}' > There's a large number of changes that the oneliner

Re: [HACKERS] Too many autovacuum workers spawned during forced auto-vacuum

On Fri, Jan 13, 2017 at 8:45 AM, Alvaro Herrera wrote: > Amit Khandekar wrote: >> In a server where autovacuum is disabled and its databases reach >> autovacuum_freeze_max_age limit, an autovacuum is forced to prevent >> xid wraparound issues. At this stage, when the

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

On Mon, Jan 16, 2017 at 10:48 PM, Fujii Masao wrote: > If we do that, we should vote on all the "renaming" stuff, i.e., not only > function names but also program names like pg_receivexlog, directory names > like clog, option names like xlogdir option of initdb, return

Re: [HACKERS] [WIP]Vertical Clustered Index (columnar store extension)

On 12/29/16 10:55 PM, Haribabu Kommi wrote: > Fujitsu was interested in developing a columnar storage extension with > minimal > changes the server backend. > > The columnar store is implemented as an extension using index access > methods. > This can be easily enhanced with pluggable storage

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

On Tue, Jan 17, 2017 at 7:36 PM, Kyotaro HORIGUCHI wrote: > I managed to reproduce this. A little tweak as the first patch > lets the standby to suicide as soon as walreceiver sees a > contrecord at the beginning of a segment. Good idea. > I believe that a

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On 1/17/17 8:35 PM, Michael Paquier wrote: > Yeah, it seems to me that we are likely looking for a wait mode saying > to exit pg_ctl once Postgres is happily rejecting connections, because > that means that it is up and that it is sorting out something first > before accepting them. This would

[HACKERS] reminder: PGCon 2017 CFP

Hello, There are two days left in the PGCon 2017 CFP, which closes on 19 January. Please get your submissions in soon. PGCon 2017 will be on 23-26 May 2017 at University of Ottawa. * 23-24 (Tue-Wed) tutorials * 24 (Wed) The Unconference * 25-26 (Thu-Fri) talks - the main part of the conference

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On Wed, Jan 18, 2017 at 10:35 AM, Michael Paquier wrote: > On Wed, Jan 18, 2017 at 7:31 AM, Stephen Frost wrote: >> Perhaps we need a way for pg_ctl to realize a cold-standby case and >> throw an error or warning if --wait is specified then, but

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Wed, Jan 18, 2017 at 3:06 AM, Gilles Darold wrote: > This have already been discuted previously in this thread, one of my > previous patch version has implemented this behavior but we decide that > what we really want is to be able to use the function using the >

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Wed, Jan 18, 2017 at 7:36 AM, Karl O. Pinc wrote: > Maybe. It's not user-supplied data that's corrupted but it is > PG generated data which is generated for and supplied to the user. > I just looked at all uses of XX001 and it is true that they all > involve corruption of

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Wed, 18 Jan 2017 11:08:25 +0900 Michael Paquier wrote: > Our ideas rather map here, ERRCODE_INTERNAL_ERROR would be adapted for > this situation. Do any of you want to give it a shot or should I? You're welcome to it. Karl Free Software: "You

Re: [HACKERS] postgres_fdw bug in 9.6

On 2017/01/16 11:38, Etsuro Fujita wrote: On 2017/01/14 6:39, Jeff Janes wrote: I do get a compiler warning: foreign.c: In function 'CreateLocalJoinPath': foreign.c:832: warning: implicit declaration of function 'pathkeys_contained_in' Will fix. Done. Attached is the new version. I also

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On 1/13/17 9:22 AM, Peter Moser wrote: > The goal of temporal aligners and normalizers is to split ranges to allow a > reduction from temporal queries to their non-temporal counterparts. > Splitting > ranges is necessary for temporal query processing. Temporal aligners and > normalizer may then be

Re: [HACKERS] Parallel Index Scans

On Mon, Jan 16, 2017 at 11:11 PM, Amit Kapila wrote: > > Changed as per suggestion. > > > I have also rebased the optimizer/executor support patch > (parallel_index_opt_exec_support_v4.patch) and added a test case in > it. Thanks for the patch. Here are comments found

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On Wed, Jan 18, 2017 at 7:31 AM, Stephen Frost wrote: > Perhaps we need a way for pg_ctl to realize a cold-standby case and > throw an error or warning if --wait is specified then, but that hardly > seems like the common use-case. It also wouldn't make any sense to have >

Re: [HACKERS] increasing the default WAL segment size

On Tue, Jan 17, 2017 at 7:19 PM, Beena Emerson wrote: > PFA the patch with the documentation included. It is usually better to keep doc lines under control of 72-80 characters if possible. + /* column 1: Wal segment size */ + len = strlen(value); + pq_sendint(,

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Jan 17, 2017 at 4:46 PM, Stephen Frost wrote: > >> But what if we're restarting after, say, rebooting? Then there's > >> nobody to see the progress messages, perhaps. The system just seems > >> to take an eternity to

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Tue, 17 Jan 2017 23:00:43 +0100 Gilles Darold wrote: > Le 17/01/2017 à 19:58, Karl O. Pinc a écrit : > > On Tue, 17 Jan 2017 19:06:22 +0100 > > Gilles Darold wrote: > > > >> Le 17/01/2017 à 03:22, Michael Paquier a écrit : > >>> On Tue,

Re: [HACKERS] [COMMITTERS] pgsql: Generate fmgr prototypes automatically

Alvaro Herrera writes: > Alvaro Herrera wrote: >> It is possible to replace many occurrences of builtins.h with >> fmgrprotos.h. I just tried this >> git grep -l 'include.*utils/builtins.h' -- *.c | xargs perl -pi -e >> 's{utils/builtins.h}{utils/fmgrprotos.h}' >>

Re: [HACKERS] pageinspect: Hash index support

On Tue, Jan 17, 2017 at 1:22 PM, Mithun Cy wrote: >> >> 7. I think it is not your bug, but probably a bug in Hash index >> itself; page flag is set to 66 (for below test); So the page is both >> LH_BUCKET_PAGE and LH_BITMAP_PAGE. Is not this a bug in hash index? >> >>

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

Hello. I added pgsql-hackers. This occurs also on git master and back to 9.4. At Fri, 13 Jan 2017 08:47:06 -0600, Jonathon Nelson wrote in > On Mon, Nov 28, 2016 at 1:39 PM, Jonathon Nelson

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

Auch! It is wrong. Not decrement keep, decrement segno. 2017年1月17日(火) 19:37 Kyotaro HORIGUCHI : > Hello. I added pgsql-hackers. > > This occurs also on git master and back to 9.4. > > At Fri, 13 Jan 2017 08:47:06 -0600, Jonathon Nelson > wrote

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Jan 17, 2017 at 11:39 AM, Dilip Kumar wrote: > On Wed, Jan 11, 2017 at 10:55 AM, Dilip Kumar wrote: >> I have reviewed the latest patch and I don't have any more comments. >> So if there is no objection from other reviewers I can move it to

Re: [HACKERS] Gather Merge

On Tue, Jan 17, 2017 at 5:19 PM, Rushabh Lathia wrote: > > > On Fri, Jan 13, 2017 at 10:52 AM, Rushabh Lathia > wrote: > >> >> >> On Thu, Jan 12, 2017 at 8:50 AM, Robert Haas >> wrote: >> >>> On Sun, Dec 4, 2016 at

[HACKERS] New CORRESPONDING clause design

I am new here and I really want to contribute, I have read same resource that help understanding database system and postgresql. I would like to start implementing sql syntax corresponding by clause because I believe implementing sql syntax gives an opportunity to familiarize many part of

[HACKERS] ISO/IEC 9075-2:2016 for postgres community

Hi there, I just bought ISO/IEC 9075-2:2016 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63556 to satisfy my interest on json support in SQL. I am not ready to discuss here implementation details, but there is one problem with the status of this document, which is

Re: [HACKERS] Gather Merge

On Tue, Jan 17, 2017 at 5:19 PM, Rushabh Lathia wrote: > > > > Here is the benchmark number which I got with the latest (v6) patch: > > - max_worker_processes = DEFAULT (8) > - max_parallel_workers_per_gather = 4 > - Cold cache environment is ensured. With every query

Re: [HACKERS] pageinspect: Hash index support

On Fri, Jan 13, 2017 at 12:49 AM, Jesper Pedersen wrote: > Hi, > > On 01/11/2017 03:16 PM, Ashutosh Sharma wrote: >> >> >> I have rephrased it to make it more clear. >> > > Rebased, and removed the compile warn in hashfuncs.c > Review comments: 1. +static Page

Re: [HACKERS] Re: [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

I sent this email one month ago but forgot to cc pgsql-hackers ;) For the record, it is the set of patches attached that have been pushed as 974ece5, and only Fujii-san has received them... Thanks for committing the fix by the way! On Thu, Dec 15, 2016 at 3:30 AM, Fujii Masao

Re: [HACKERS] PoC: Grouped base relation

On 01/17/2017 06:39 AM, David Rowley wrote: On 17 January 2017 at 16:30, Tomas Vondra wrote: Let's instead use an example similar to what Antonin mentioned in the initial post - two tables, with two columns each. CREATE TABLE t1 (a INT, b INT); CREATE

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Tue, Jan 17, 2017 at 8:11 PM, Magnus Hagander wrote: > Committed. Yeah, thanks! -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Gather Merge

On Fri, Jan 13, 2017 at 10:52 AM, Rushabh Lathia wrote: > > > On Thu, Jan 12, 2017 at 8:50 AM, Robert Haas > wrote: > >> On Sun, Dec 4, 2016 at 7:36 PM, Haribabu Kommi >> wrote: >> > On Thu, Nov 24, 2016 at 11:12 PM,

Re: [HACKERS] pageinspect: Hash index support

On Tue, Jan 17, 2017 at 3:06 PM, Amit Kapila wrote: > > I think your calculation is not right. 66 indicates LH_BUCKET_PAGE | > LH_BUCKET_NEEDS_SPLIT_CLEANUP which is a valid state after the split. > This flag will be cleared either during next split or when vacuum >

Re: [HACKERS] increasing the default WAL segment size

On Tue, Jan 17, 2017 at 12:50 PM, Beena Emerson wrote: > > > On Tue, Jan 17, 2017 at 12:38 PM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> On Tue, Jan 17, 2017 at 4:06 PM, Beena Emerson >> wrote: >> > I have already made patch for

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Mon, Jan 16, 2017 at 1:46 PM, Michael Paquier wrote: > On Mon, Jan 16, 2017 at 9:12 PM, Magnus Hagander > wrote: > > Where did your research point to then? :) I just read the gzip rfc > > (http://www.zlib.org/rfc-gzip.html) which seems to call

Re: [HACKERS] jsonb_delete with arrays

On Tue, Jan 17, 2017 at 8:25 AM, Michael Paquier wrote: > On Sun, Dec 18, 2016 at 1:27 AM, Dmitry Dolgov <9erthali...@gmail.com> > wrote: > > Speaking about implementation of `jsonb_delete_array` - it's fine, but I > > would like to suggest two modifications: > > > > *

[HACKERS] Re: [COMMITTERS] pgsql: Fix an assertion failure related to an exclusive backup.

On Tue, Jan 17, 2017 at 5:40 PM, Fujii Masao wrote: > Fix an assertion failure related to an exclusive backup. > > Previously multiple sessions could execute pg_start_backup() and > pg_stop_backup() to start and stop an exclusive backup at the same time. > This could trigger

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Tue, 17 Jan 2017 11:22:45 +0900 Michael Paquier wrote: > On Tue, Jan 17, 2017 at 2:21 AM, Karl O. Pinc wrote: > >>Also, I would rather see an ERROR returned to the user in case of > >>bad data in current_logfiles, I did not change that either as >

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Tue, 17 Jan 2017 07:58:43 -0600 "Karl O. Pinc" wrote: > On Tue, 17 Jan 2017 11:22:45 +0900 > Michael Paquier wrote: > > > On Tue, Jan 17, 2017 at 2:21 AM, Karl O. Pinc > > wrote: > > > >>Also, I would rather see an ERROR returned

Re: [HACKERS] New CORRESPONDING clause design

On Tue, Jan 17, 2017 at 12:37 AM, Surafel Temsgen wrote: > I am new here and I really want to contribute, I have read same resource > that help understanding database system and postgresql. I would like to > start implementing sql syntax corresponding by clause because I

Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix an assertion failure related to an exclusive backup.

On Tue, Jan 17, 2017 at 10:37 PM, Michael Paquier wrote: > On Tue, Jan 17, 2017 at 5:40 PM, Fujii Masao wrote: >> Fix an assertion failure related to an exclusive backup. >> >> Previously multiple sessions could execute pg_start_backup() and >>

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Wed, Jan 18, 2017 at 11:36 AM, Karl O. Pinc wrote: > On Wed, 18 Jan 2017 11:08:25 +0900 > Michael Paquier wrote: > >> Our ideas rather map here, ERRCODE_INTERNAL_ERROR would be adapted for >> this situation. Do any of you want to give it a shot or

  1   2   >