Re: [HACKERS] Retiring from the Core Team

Hi, On Wed, 2017-01-11 at 16:29 -0800, Josh Berkus wrote: > You will have noticed that I haven't been very active for the past year. >  My new work on Linux containers and Kubernetes has been even more > absorbing than I anticipated, and I just haven't had a lot of time for > PostgreSQL work. >

Re: [HACKERS] parallelize queries containing subplans

On Thu, Jan 12, 2017 at 9:22 AM, Amit Kapila wrote: > Valid point, but I think we can avoid that by returning false after > foreach(..) loop. I think one improvement could be that instead of > manually checking the parallel safety of each subplan, we can > recursively

Re: [HACKERS] Retiring from the Core Team

On Wed, Jan 11, 2017 at 4:29 PM, Josh Berkus wrote: > You will have noticed that I haven't been very active for the past year. > My new work on Linux containers and Kubernetes has been even more > absorbing than I anticipated, and I just haven't had a lot of time for >

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

On Thu, Jan 12, 2017 at 2:49 PM, Michael Paquier wrote: > On Thu, Jan 12, 2017 at 2:00 AM, Vladimir Rusinov wrote: >> On Tue, Jan 10, 2017 at 5:24 AM, Michael Paquier >> wrote: >>> As there are two school of thoughts on

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

On Thu, Jan 12, 2017 at 2:00 AM, Vladimir Rusinov wrote: > On Tue, Jan 10, 2017 at 5:24 AM, Michael Paquier > wrote: >> As there are two school of thoughts on this thread, keeping your patch >> with the compatibility table is the best move for now.

Re: [HACKERS] Proposal for changes to recovery.conf API

On Wed, Jan 11, 2017 at 7:36 PM, Simon Riggs wrote: > On 11 January 2017 at 09:51, Fujii Masao wrote: > >>> 5. recovery.conf parameters are all moved to postgresql.conf, with these >>> changes >> >> In current design of the patch, when recovery

Re: [HACKERS] background sessions

2017-01-12 9:01 GMT+05:00 Peter Eisentraut : > On 1/10/17 10:58 AM, Robert Haas wrote: >> On Thu, Dec 29, 2016 at 5:18 PM, Peter Eisentraut >> wrote: >>> For additional entertainment, I include patches that integrate >>>

Re: [HACKERS] many copies of atooid() and oid_cmp()

On Wed, Jan 11, 2017 at 9:42 PM, Peter Eisentraut wrote: > There are approximately 11 copies of atooid() and 3 of oid_cmp() or > equivalent, and pending patches are proposing to add more. I propose > these two patches to collect them in central places. > I've

Re: [HACKERS] Misplacement of function declaration in contrib/postgres_fdw/postgres_fdw.h

On Thu, Jan 12, 2017 at 8:49 AM, Etsuro Fujita wrote: > Hi, > > While working on pushing down more joins/updates to the remote, I noticed > that in contrib/postgres_fdw/postgres_fdw.h the declaration of > get_jointype_name is misplaced in the section of shippable.c.

Re: [HACKERS] Couple of issues with prepared FETCH commands

Robert Haas writes: > On Tue, Jan 10, 2017 at 5:38 PM, Andrew Gierth > wrote: >> But the problem that actually came up is this: if you do the PQprepare >> before the named cursor has actually been opened, then everything works >> _up until_ the

Re: [HACKERS] many copies of atooid() and oid_cmp()

Peter Eisentraut writes: > There are approximately 11 copies of atooid() and 3 of oid_cmp() or > equivalent, and pending patches are proposing to add more. I propose > these two patches to collect them in central places. +1 for the concept, but I'm a bit

Re: [HACKERS] Passing query string to workers

Robert Haas writes: > On Wed, Jan 11, 2017 at 6:36 PM, Tom Lane wrote: >> That would work, if you had a way to get at the active QueryDesc ... >> but we don't pass that down to executor nodes. > Hmm, that is a bit of a problem. Do you have a

Re: [HACKERS] WARM and indirect indexes

On Thu, Jan 12, 2017 at 3:08 AM, Robert Haas wrote: > On Tue, Jan 10, 2017 at 2:24 PM, Alvaro Herrera > wrote: > > The big advantage of WARM is that it works automatically, like HOT: the > > user doesn't need to do anything different than today

Re: [HACKERS] background sessions

On 1/10/17 10:58 AM, Robert Haas wrote: > On Thu, Dec 29, 2016 at 5:18 PM, Peter Eisentraut > wrote: >> For additional entertainment, I include patches that integrate >> background sessions into dblink. So dblink can open a connection to a >> background session,

Re: [HACKERS] Retiring from the Core Team

On 01/11/2017 04:29 PM, Josh Berkus wrote: > For that reason, as of today, I am stepping down from the PostgreSQL > Core Team. > It's been a long, fun ride, and I'm proud of the PostgreSQL we have > today: both the database, and the community. Thank you for sharing it > with me. End of an

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/06 20:23, Amit Langote wrote: > On 2017/01/05 3:26, Robert Haas wrote: >> It's unclear to me why we need to do 0002. It doesn't seem like it >> should be necessary, it doesn't seem like a good idea, and the commit >> message you proposed is uninformative. > > If a single

Re: [HACKERS] parallelize queries containing subplans

On Tue, Jan 10, 2017 at 11:55 AM, Dilip Kumar wrote: > On Wed, Dec 28, 2016 at 11:47 AM, Amit Kapila wrote: >> Attached patch implements the above idea. This will enable >> parallelism for queries containing un-correlated subplans, an example >>

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Wed, Jan 11, 2017 at 2:56 PM, Peter Geoghegan wrote: > On Fri, Jan 6, 2017 at 12:01 PM, Thomas Munro > wrote: >> Here is a new WIP patch. I have plenty of things to tidy up (see note >> at end), but the main ideas are now pretty clear and I'd

[HACKERS] Misplacement of function declaration in contrib/postgres_fdw/postgres_fdw.h

Hi, While working on pushing down more joins/updates to the remote, I noticed that in contrib/postgres_fdw/postgres_fdw.h the declaration of get_jointype_name is misplaced in the section of shippable.c. Since that function is defined in contrib/postgres_fdw/deparse.c, we should put that

Re: [HACKERS] Passing query string to workers

On Wed, Jan 11, 2017 at 6:36 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jan 11, 2017 at 7:37 AM, Tom Lane wrote: >>> As far as reproducing the pg_stat_activity query goes, you could probably >>> grab that string out of the

Re: [HACKERS] parallelize queries containing subplans

On Wed, Jan 11, 2017 at 9:58 PM, Amit Kapila wrote: > The other alternative is to remember this information in SubPlan. We > can retrieve parallel_safe information from best_path and can use it > while generating SubPlan. The main reason for storing it in the plan > was

Re: [HACKERS] merging some features from plpgsql2 project

On Wed, Jan 11, 2017 at 2:57 PM, Robert Haas wrote: > - The E'' syntax and the standard_conforming_strings GUC were added in > PostgreSQL 8.0. The only legal value of standard_conforming_strings > was "false". > > - In PostgreSQL 8.1, it became possible to set >

Re: [HACKERS] Gather Merge

On Sun, Dec 4, 2016 at 7:36 PM, Haribabu Kommi wrote: > On Thu, Nov 24, 2016 at 11:12 PM, Rushabh Lathia > wrote: >> PFA latest patch with fix as well as few cosmetic changes. > > Moved to next CF with "needs review" status. I spent quite a

Re: [HACKERS] Do we support using agg or window functions in delete statement?

Thanks a lot for reply. 2017-01-11 20:46 GMT+08:00 Tom Lane : > =?UTF-8?B?6auY5aKe55Cm?= writes: > > In transformDeleteStmt: > > > qry->hasWindowFuncs = pstate->p_hasWindowFuncs; > > qry->hasAggs = pstate->p_hasAggs; > > if (pstate->p_hasAggs) >

Re: [HACKERS] parallelize queries containing subplans

On Tue, Jan 10, 2017 at 10:55 PM, Robert Haas wrote: > On Wed, Dec 28, 2016 at 1:17 AM, Amit Kapila wrote: >> Currently, queries that have references to SubPlans or >> AlternativeSubPlans are considered parallel-restricted. I think we >> can lift

Re: [HACKERS] Retiring from the Core Team

On Wed, Jan 11, 2017 at 4:29 PM, Josh Berkus wrote: > > For that reason, as of today, I am stepping down from the PostgreSQL > Core Team. > Massive thanks Josh, you've been a great advocate and a wonderful bridge into the PgSQL community for those of us finding our way

Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together

> On 12 January 2017 at 09:36, Robert Haas wrote: >> One option is certainly to decide categorically that background >> workers are not connections, and therefore CountUserBackends() should >> ignore them and InitializeSessionUserId() shouldn't call it when the >> session

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Thu, Jan 12, 2017 at 4:09 AM, Robert Haas wrote: > On Tue, Jan 10, 2017 at 11:41 PM, Michael Paquier > wrote: >> Do you think that expanding the wait query by default could be >> intrusive for the other tests? I am wondering about such a white

Re: [HACKERS] Retiring from the Core Team

On Wed, Jan 11, 2017 at 04:29:19PM -0800, Josh Berkus wrote: > Hackers: > > You will have noticed that I haven't been very active for the past > year. My new work on Linux containers and Kubernetes has been even > more absorbing than I anticipated, and I just haven't had a lot of > time for

Re: [HACKERS] Multiple synchronous_standby_names rules

On Thu, Jan 12, 2017 at 9:53 AM, James Sewell wrote: > What is needed to support this is the ability to configure Px with something > like: > > 1 (P1, P2, P3), 1 (D1, D2, D3) > > Would there be any appetite for this - or would it be seen as over > complication of the

[HACKERS] Multiple synchronous_standby_names rules

Hello, When working with a production (P) and a DR (D) environment it is often a requirement to be able to protect against data loss when promoting within a site, and also when losing A and promoting a master at D. The current synchronous_standby_names do not allow this. In a simple example we

Re: [HACKERS] Retiring from the Core Team

Josh, * Josh Berkus (j...@agliodbs.com) wrote: > For that reason, as of today, I am stepping down from the PostgreSQL > Core Team. I'm sure you'll hear this a lot, but: Thank you. Your leadership as a member of core and your focus on advocacy has definitely helped this community and project

[HACKERS] Retiring from the Core Team

Hackers: You will have noticed that I haven't been very active for the past year. My new work on Linux containers and Kubernetes has been even more absorbing than I anticipated, and I just haven't had a lot of time for PostgreSQL work. For that reason, as of today, I am stepping down from the

Re: [HACKERS] Packages: Again

On 12 Jan. 2017 02:59, "Joshua D. Drake" wrote: -hackers, I know we have talked about this before but today it was impressed upon me rather firmly. I presented a Webinar: Postgres for Oracle People. The attendees were 90% pl/pgsql developers. 330 people registered for an

Re: [HACKERS] Packages: Again

Le 11/01/2017 à 20:32, Pavel Stehule a écrit : > > > 2017-01-11 19:57 GMT+01:00 Joshua D. Drake >: > > -hackers, > > I know we have talked about this before but today it was impressed > upon me rather firmly. I presented a

Re: [HACKERS] Passing query string to workers

Robert Haas writes: > On Wed, Jan 11, 2017 at 7:37 AM, Tom Lane wrote: >> As far as reproducing the pg_stat_activity query goes, you could probably >> grab that string out of the master backend's pgstat entry and pass it over >> at parallel query start.

Re: [HACKERS] Passing query string to workers

On Wed, Jan 11, 2017 at 7:37 AM, Tom Lane wrote: > Rafia Sabih writes: >> Approach: >> A token for query string is created in the shared memory, this token is >> populated with the query string using the global string -- >> debug_query_string.

Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together

On 12 January 2017 at 09:36, Robert Haas wrote: > One option is certainly to decide categorically that background > workers are not connections, and therefore CountUserBackends() should > ignore them and InitializeSessionUserId() shouldn't call it when the > session being

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Wed, Jan 11, 2017 at 12:05 PM, Robert Haas wrote: > On Wed, Jan 11, 2017 at 2:20 PM, Peter Geoghegan wrote: >> You'd probably still want to throw an error when workers ended up not >> deleting BufFile segments they owned, though, at least for parallel

Re: [HACKERS] WARM and indirect indexes

On Tue, Jan 10, 2017 at 2:24 PM, Alvaro Herrera wrote: > The big advantage of WARM is that it works automatically, like HOT: the > user doesn't need to do anything different than today to get the > benefit. With indirect indexes, the user needs to create the index as >

Re: [HACKERS] Logical Replication WIP

On 1/11/17 3:35 PM, Petr Jelinek wrote: > On 11/01/17 18:32, Peter Eisentraut wrote: >> On 1/11/17 3:29 AM, Petr Jelinek wrote: >>> Okay, looking into my notes, I originally did this because we did not >>> allow adding tables without pkeys to publications which effectively >>> prohibited FOR ALL

Re: [HACKERS] Logical Replication WIP

On 1/11/17 3:35 PM, Petr Jelinek wrote: > On 11/01/17 18:27, Peter Eisentraut wrote: >> On 1/11/17 3:11 AM, Petr Jelinek wrote: >>> That will not help, issue is that we consider names for origins to be >>> unique across cluster while subscription names are per database so if >>> there is origin

Re: [HACKERS] Couple of issues with prepared FETCH commands

> "Robert" == Robert Haas writes: >> But the problem that actually came up is this: if you do the >> PQprepare before the named cursor has actually been opened, then >> everything works _up until_ the first event, such as a change to >> search_path, that forces a

Re: [HACKERS] plan_rows confusion with parallel queries

On Wed, Jan 11, 2017 at 1:24 PM, Robert Haas wrote: >> Well, it's not *that* consistent. If we were estimating all the numbers >> underneath the Gather as being per-worker numbers, that would make some >> amount of sense. But neither the other seqscan, nor the hash on it,

Re: [HACKERS] patch: function xmltable

Pavel Stehule wrote: > another update - lot of cleaning Thanks. The more I look at this, the less I like using NameArgExpr for namespaces. It looks all wrong to me, and it causes ugly code all over. Maybe I just need to look at it a bit longer. -- Álvaro Herrera

Re: [HACKERS] Packages: Again

On Wed, Jan 11, 2017 at 3:56 PM, Joshua D. Drake wrote: >> We have a schemas instead - the PostgreSQL schema is close to Oracle >> packages. > > No. It isn't. I'm gonna say "yeah, it is". And that's all I will say about this topic. -- Robert Haas EnterpriseDB:

Re: [HACKERS] merging some features from plpgsql2 project

On Mon, Jan 9, 2017 at 6:53 PM, Jim Nasby wrote: > I do think that whichever route we go, we're going to be stuck supporting > the old version for a LONG time. A big part of why > standard_conforming_strings was so ugly is users didn't have enough time to > adjust. If

Re: [HACKERS] Packages: Again

On 01/11/2017 11:32 AM, Pavel Stehule wrote: We have a schemas instead - the PostgreSQL schema is close to Oracle packages. No. It isn't. A Package is essentially a class with dependencies. It has nothing to do with schemas outside of being named qualified. For example:

Re: [HACKERS] pg_restore accepts -j -1

Ashutosh, * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > On Tue, Jan 10, 2017 at 10:18 AM, Stephen Frost wrote: > > For reasons which seem likely to be entirely unintentional, pg_restore > > will accept a '-1' for -j: > > > > pg_restore -j -1 > > > > This seems

Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together

On Tue, Jan 10, 2017 at 4:14 PM, David Rowley wrote: > It has come to my attention that when a user has a CONNECTION LIMIT > set, and they make use of parallel query, that their queries can fail > due to the connection limit being exceeded. That's bad. > Now, as I

Re: [HACKERS] Logical Replication WIP

On 11/01/17 18:27, Peter Eisentraut wrote: > On 1/11/17 3:11 AM, Petr Jelinek wrote: >> That will not help, issue is that we consider names for origins to be >> unique across cluster while subscription names are per database so if >> there is origin per subscription (which there has to be) it will

Re: [HACKERS] Logical Replication WIP

On 11/01/17 18:32, Peter Eisentraut wrote: > On 1/11/17 3:29 AM, Petr Jelinek wrote: >> Okay, looking into my notes, I originally did this because we did not >> allow adding tables without pkeys to publications which effectively >> prohibited FOR ALL TABLES publication from working because of >>

Re: [HACKERS] pageinspect: Hash index support

Hi, > >> + /* >> + * We copy the page into local storage to avoid holding pin on >> the >> + * buffer longer than we must, and possibly failing to release >> it at >> + * all if the calling query doesn't fetch all rows. >> + */ >>

Re: [HACKERS] Packages: Again

2017-01-11 21:08 GMT+01:00 Bruce Momjian : > On Wed, Jan 11, 2017 at 08:56:23PM +0100, Fabien COELHO wrote: > > > > >I think we need to focus on things that _can't_ be done first, rather > > >than things that require porting, e.g. until we had savepoints, you > > >couldn't

Re: [HACKERS] Packages: Again

On Wed, Jan 11, 2017 at 03:08:58PM -0500, Bruce Momjian wrote: > On Wed, Jan 11, 2017 at 08:56:23PM +0100, Fabien COELHO wrote: > > > > >I think we need to focus on things that _can't_ be done first, rather > > >than things that require porting, e.g. until we had savepoints, you > > >couldn't

Re: [HACKERS] pageinspect: Hash index support

Hi, > +values[j++] = UInt16GetDatum(uargs->offset); > +values[j++] = CStringGetTextDatum(psprintf("(%u,%u)", > + > BlockIdGetBlockNumber(&(itup->t_tid.ip_blkid)), > +itup->t_tid.ip_posid)); > + > +ptr = (char *) itup +

Re: [HACKERS] Packages: Again

2017-01-11 20:56 GMT+01:00 Fabien COELHO : > > I think we need to focus on things that _can't_ be done first, rather >> than things that require porting, e.g. until we had savepoints, you >> couldn't migrate an application that needed it. It wasn't a question of >> porting

Re: [HACKERS] Packages: Again

On Wed, Jan 11, 2017 at 08:56:23PM +0100, Fabien COELHO wrote: > > >I think we need to focus on things that _can't_ be done first, rather > >than things that require porting, e.g. until we had savepoints, you > >couldn't migrate an application that needed it. It wasn't a question of > >porting

Re: [HACKERS] Couple of issues with prepared FETCH commands

On Tue, Jan 10, 2017 at 5:38 PM, Andrew Gierth wrote: > But the problem that actually came up is this: if you do the PQprepare > before the named cursor has actually been opened, then everything works > _up until_ the first event, such as a change to search_path, that

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-11 20:53 GMT+01:00 Merlin Moncure : > On Wed, Jan 11, 2017 at 11:11 AM, Peter Eisentraut > wrote: > > The current syntax was chosen because it is SQL-compatible. Adding > > redundant syntax to save a few characters without any new

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Wed, Jan 11, 2017 at 11:20 AM, Peter Geoghegan wrote: >> If multiple processes are using the same file via the BufFile >> interface, I think that it is absolutely necessary that there should >> be a provision to track the "attach count" of the BufFile. Each >> process that

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

On Wed, Jan 11, 2017 at 9:17 AM, Dilip Kumar wrote: > On Mon, Dec 5, 2016 at 8:01 AM, Haribabu Kommi > wrote: >> Moved to next CF with "needs review" status. > > I have started reviewing the patch, Some initial comments. > > $ git apply

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Wed, Jan 11, 2017 at 2:20 PM, Peter Geoghegan wrote: > You'd probably still want to throw an error when workers ended up not > deleting BufFile segments they owned, though, at least for parallel > tuplesort. Don't see why. > This idea is something that's much more limited

Re: [HACKERS] Packages: Again

Fabien, * Fabien COELHO (coe...@cri.ensmp.fr) wrote: > >I think we need to focus on things that _can't_ be done first, rather > >than things that require porting, e.g. until we had savepoints, you > >couldn't migrate an application that needed it. It wasn't a question of > >porting --- there was

Re: [HACKERS] Packages: Again

I think we need to focus on things that _can't_ be done first, rather than things that require porting, e.g. until we had savepoints, you couldn't migrate an application that needed it. It wasn't a question of porting --- there was just no way to port it. Those _missing_ pieces should be a

Re: [HACKERS] Packages: Again

2017-01-11 20:42 GMT+01:00 Bruce Momjian : > On Wed, Jan 11, 2017 at 08:32:53PM +0100, Pavel Stehule wrote: > > Now I work on migration about 500K rows - and it is terrible work. It is > 20 > > years old project - lot of code is not clean, It is hard to migrate, it > is hard > >

Re: [HACKERS] Packages: Again

We have a schemas instead - the PostgreSQL schema is close to Oracle packages. Yes, a schema is a kind of a "namespace"-level package. Pg also has extensions, which is a group things put together, which may also contribute to packaging. What we cannot to substitute are package variables,

Re: [HACKERS] Proposal for changes to recovery.conf API

On 1/11/17 12:53 PM, Simon Riggs wrote: >> I'm concerned that having signal files somewhere else opens up a bunch >> more edge cases that need to be considered. For example, what if >> someone puts a signal file into a temporary directory that is cleared >> after a server crash and restart. That

Re: [HACKERS] merging some features from plpgsql2 project

On Wed, Jan 11, 2017 at 11:11 AM, Peter Eisentraut wrote: > The current syntax was chosen because it is SQL-compatible. Adding > redundant syntax to save a few characters without any new functionality > (performance, resource usage, safety, etc.) is a weak

Re: [HACKERS] Packages: Again

On Wed, Jan 11, 2017 at 08:32:53PM +0100, Pavel Stehule wrote: > Now I work on migration about 500K rows - and it is terrible work. It is 20 > years old project - lot of code is not clean, It is hard to migrate, it is > hard > to clean. Sure, there is not one line of tests. > > If we miss some,

Re: [HACKERS] Packages: Again

2017-01-11 19:57 GMT+01:00 Joshua D. Drake : > -hackers, > > I know we have talked about this before but today it was impressed upon me > rather firmly. I presented a Webinar: Postgres for Oracle People. The > attendees were 90% pl/pgsql developers. 330 people registered

Re: [HACKERS] Packages: Again

On Wed, Jan 11, 2017 at 10:57:58AM -0800, Joshua Drake wrote: > -hackers, > > I know we have talked about this before but today it was impressed upon me > rather firmly. I presented a Webinar: Postgres for Oracle People. The > attendees were 90% pl/pgsql developers. 330 people registered for an

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Wed, Jan 11, 2017 at 10:57 AM, Robert Haas wrote: > On Tue, Jan 10, 2017 at 8:56 PM, Peter Geoghegan wrote: >> Instead of all this, I suggest copying some of my changes to fd.c, so >> that resource ownership within fd.c differentiates between a vfd that

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Tue, Jan 10, 2017 at 11:41 PM, Michael Paquier wrote: > On Thu, Jan 5, 2017 at 6:41 AM, Thomas Munro > wrote: >> It's a bit of a strange case: we're indirectly waiting for other >> backends' transactions to end, but it's not exactly a

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Tue, Jan 10, 2017 at 8:56 PM, Peter Geoghegan wrote: > Instead of all this, I suggest copying some of my changes to fd.c, so > that resource ownership within fd.c differentiates between a vfd that > is owned by the backend in the conventional sense, including having a > need

[HACKERS] Packages: Again

-hackers, I know we have talked about this before but today it was impressed upon me rather firmly. I presented a Webinar: Postgres for Oracle People. The attendees were 90% pl/pgsql developers. 330 people registered for an event that was only allowed to host 100 people. The webinar went on

Re: [HACKERS] plan_rows confusion with parallel queries

On Wed, Nov 2, 2016 at 10:54 PM, Tom Lane wrote: I got confused by that a minute ago, so no you're not alone. The problem is even worse in join cases. For example: Gather (cost=34332.00..53265.35 rows=100 width=8) Workers Planned: 2 -> Hash

Re: [HACKERS] Proposal for changes to recovery.conf API

Having already agreed to remove the two mentioned aspects, I'm just replying to fill in some historical details. On 11 January 2017 at 17:25, Peter Eisentraut wrote: > On 1/11/17 5:27 AM, Simon Riggs wrote: >> * Renaming primary_* parameters - Currently we use

Re: [HACKERS] Logical Replication WIP

On 1/11/17 3:29 AM, Petr Jelinek wrote: > Okay, looking into my notes, I originally did this because we did not > allow adding tables without pkeys to publications which effectively > prohibited FOR ALL TABLES publication from working because of > information_schema without this. Since this is no

Re: [HACKERS] Logical Replication WIP

On 1/11/17 3:11 AM, Petr Jelinek wrote: > That will not help, issue is that we consider names for origins to be > unique across cluster while subscription names are per database so if > there is origin per subscription (which there has to be) it will always > clash if we just use the name. I

Re: [HACKERS] Proposal for changes to recovery.conf API

On 1/11/17 5:27 AM, Simon Riggs wrote: > * Renaming primary_* parameters - Currently we use this config setting > even when connecting to a standby, so the parameter is confusingly > named, so 10.0 is a good chance to name it correctly. Will submit as > separate patch. I don't subscribe to the

Re: [HACKERS] merging some features from plpgsql2 project

On 1/10/17 8:44 AM, Marko Tiikkaja wrote: > On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut > > wrote: > > It's not like PL/pgSQL is the king of brevity. > > > This is essentially saying "PL/PgSQL isn't

Re: [HACKERS] Questionable tag usage

On 1/6/17 8:56 AM, Magnus Hagander wrote: > You could argue that nobody reads the PG docs on dead trees anymore > and we should embrace the hyperlink style with enthusiasm. I wouldn't > be against that personally, but there are a lot of places to change if > we decide that

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

On Tue, Jan 10, 2017 at 5:24 AM, Michael Paquier wrote: > -errhint("pg_xlogfile_name_offset() cannot be executed > during recovery."))); > +errhint( > +"pg_wal_file_name_offset() cannot be executed > during

Re: [HACKERS] PATCH: recursive json_populate_record()

On 01/08/2017 09:52 PM, Tom Lane wrote: The example you quoted at the start of the thread doesn't fail for me in HEAD, so I surmise that it's falling foul of some assertion you added in the 0001 patch, but if so I think that assertion is wrong. attndims is really syntactic sugar only and

Re: [HACKERS] Questionable tag usage

On 1/4/17 11:50 PM, Tom Lane wrote: > Anyway, bottom line is I'm not terribly excited about fixing just this > one place. I think we need to decide whether we like the new more-verbose > output for links. If we don't, we need to fix the markup rules to not do > that. If we do, there are a lot

Re: [HACKERS] pg_restore accepts -j -1

Ashutosh, * Stephen Frost (sfr...@snowman.net) wrote: > Attached patch adds the same check to pg_restore that's in pg_dump > already. Looks like it should back-patch to 9.3 pretty cleanly and I'll > add a similar check for 9.2. After playing with this, it seems entirely wrong to wait until

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-11 15:37 GMT+01:00 Merlin Moncure : > On Tue, Jan 10, 2017 at 7:44 AM, Marko Tiikkaja wrote: > > On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut > > wrote: > >> > >> It's not like PL/pgSQL is the king of brevity. > >

Re: [HACKERS] WARM and indirect indexes

On Wed, Jan 11, 2017 at 12:24:55PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > > Therefore, I think we need WARM done first, then we can test indirect > > indexes to see if they are a sufficient win to add it for the small > > percentage of users who will use it. > > Agreed -- that's

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

Thanks for the review Beena, I'm glad the patch is ready to go! I think because of my environment/setup, I get errors when I try "make install-world", but I'm at work now, when I have time I will go back and try again and figure out what is wrong. I'll let you guys know if I have any questions.

[HACKERS] many copies of atooid() and oid_cmp()

There are approximately 11 copies of atooid() and 3 of oid_cmp() or equivalent, and pending patches are proposing to add more. I propose these two patches to collect them in central places. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote

Re: [HACKERS] Logical replication existing data copy

On 12/19/16 4:30 AM, Petr Jelinek wrote: > This patch implements data synchronization for the logical replication. > It works both for initial setup of subscription as well as for tables > added later to replication when the subscription is already active. First detailed read-through. General

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> - Floating point comparisons for gemetric types > > Comparison related to geometric types is performed by FPeq > macro and similars defined in geo_decls.h. This intends to give > tolerance to the comparisons. > > A > FPeq: |<=e-|-e=>|(<= means inclusive, e =

Re: [HACKERS] WARM and indirect indexes

On Wed, Jan 11, 2017 at 08:28:28AM -0500, Andrew Dunstan wrote: > > > On 01/10/2017 09:25 PM, Bruce Momjian wrote: > >I am not saying we shouldn't do it, but I am afraid that the complexity > >in figuring out when to use indirect indexes, combined with the number > >of users who will try them,

Re: [HACKERS] WARM and indirect indexes

On Wed, Jan 11, 2017 at 12:36:24PM +0530, Pavan Deolasee wrote: > That could also be seen as an advantage to indirect indexes. While I haven't > seen the code, I believe indirect index code will only be hit if someone > actually uses them. So there won't be any overhead for other users who do not

Re: [HACKERS] WARM and indirect indexes

Bruce Momjian wrote: > Therefore, I think we need WARM done first, then we can test indirect > indexes to see if they are a sufficient win to add it for the small > percentage of users who will use it. Agreed -- that's my plan. -- Álvaro Herrerahttps://www.2ndQuadrant.com/

Re: [HACKERS] WARM and indirect indexes

On Tue, Jan 10, 2017 at 09:25:05PM -0500, Bruce Momjian wrote: > Thank you for the summary. I think we have to consider two things with > indirect indexes: > > 1. What percentage speedup is the _average_ user going to get? You > have to consider people who will use indirect indexes who get no

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

Hi 2017-01-10 17:31 GMT+01:00 David Fetter : > On Mon, Jan 09, 2017 at 07:52:11PM -0300, Alvaro Herrera wrote: > > David Fetter wrote: > > > > > + if (query->commandType == CMD_UPDATE || query->commandType == > CMD_DELETE) > > > + { > > > + /* Make sure there's

Re: [HACKERS] pg_restore accepts -j -1

Ashutosh, * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > On Tue, Jan 10, 2017 at 10:18 AM, Stephen Frost wrote: > > For reasons which seem likely to be entirely unintentional, pg_restore > > will accept a '-1' for -j: > > > > pg_restore -j -1 > > > > This seems

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Jan 10, 2017 at 7:44 AM, Marko Tiikkaja wrote: > On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut > wrote: >> >> It's not like PL/pgSQL is the king of brevity. > > > This is essentially saying "PL/PgSQL isn't perfect, so we shouldn't try

  1   2   >