Re: [HACKERS] Logical Replication WIP

On 10/01/17 14:52, Peter Eisentraut wrote: > On 1/2/17 8:32 AM, Petr Jelinek wrote: >> On 02/01/17 05:23, Steve Singer wrote: >>> but I can't drop the subscription either >>> >>> >>> test_b=# drop subscription mysub; >>> ERROR: could not drop replication origin with OID 1, in use by PID 24996 >>>

Re: [HACKERS] proposal: session server side variables

Hello Craig. I'm not so sure about Craig precise opinion, but I cannot talk in his name. I think that I understood that he points out that there exists a situation where the use case is okay despite an untransactional variable: if the containing transaction is warranted not to fail, and probabl

Re: [HACKERS] Logical Replication WIP

On 10/01/17 15:06, Peter Eisentraut wrote: > On 1/3/17 5:23 PM, Petr Jelinek wrote: >> I got this remark about IsCatalogClass() from Andres offline as well, >> but it's not true, it only checks for FirstNormalObjectId for objects in >> pg_catalog and toast schemas, not anywhere else. > > I see you

Re: [HACKERS] postgres_fdw bug in 9.6

On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita wrote: > On 2017/01/11 13:40, Ashutosh Bapat wrote: >> >> CreateLocalJoinPath tries to construct a nestloop path for the given >> join relation because it wants to avoid merge/hash join paths which >> require expensive setup not required for EPQ. But

Re: [HACKERS] Typo in dsa.c

On Wed, Jan 11, 2017 at 8:28 AM, Masahiko Sawada wrote: > Hi, > > Attached fixes comment typos in dsa.c. > Thanks, pushed! -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

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

Amit Kapila wrote: > On Wed, Jan 11, 2017 at 2:44 AM, 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. >> >> Simple test case: >> >> p

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

On Mon, Jan 2, 2017 at 6:14 AM, Simon Riggs wrote: > On 20 December 2016 at 15:11, Simon Riggs wrote: >> On 20 December 2016 at 15:03, Fujii Masao wrote: >> >>> API for crash recovery will never be changed. That is, crash recovery needs >>> neither recovery.trigger nor standby.trigger. When the

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

On Tue, Jan 10, 2017 at 4:50 AM, Peter Eisentraut wrote: > On 1/1/17 4:14 PM, Simon Riggs wrote: >> OK, so here's the patch, plus doc cleanup patch. > > I don't think this patch is likely to succeed if we throw in more ideas > in every round. > > I think we have or are approaching agreement on mov

Re: [HACKERS] postgres_fdw bug in 9.6

On 2017/01/11 17:51, Ashutosh Bapat wrote: On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita wrote: On 2017/01/11 13:40, Ashutosh Bapat wrote: CreateLocalJoinPath tries to construct a nestloop path for the given join relation because it wants to avoid merge/hash join paths which require expensive

Re: [HACKERS] UNDO and in-place update

On Tue, Jan 10, 2017 at 7:28 PM, Amit Kapila wrote: > On Mon, Jan 9, 2017 at 11:47 PM, Robert Haas wrote: >> >> Yes, something like this can be done. You don't really need any new >> page-level header data, because you can get the XIDs from the TPD >> entry (or from the page itself if there's on

Re: [HACKERS] postgres_fdw bug in 9.6

On Wed, Jan 11, 2017 at 3:30 PM, Etsuro Fujita wrote: > On 2017/01/11 17:51, Ashutosh Bapat wrote: >> >> On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita >> wrote: >>> >>> On 2017/01/11 13:40, Ashutosh Bapat wrote: CreateLocalJoinPath tries to construct a nestloop path for the given

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

On 9 January 2017 at 19:50, Peter Eisentraut wrote: > On 1/1/17 4:14 PM, Simon Riggs wrote: >> OK, so here's the patch, plus doc cleanup patch. > > I don't think this patch is likely to succeed if we throw in more ideas > in every round. > > I think we have or are approaching agreement on moving r

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

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 parameters are misconfigured > (e.g., set recovery_target_timeline to invalid timeline id) and > the configurat

Re: [HACKERS] postgres_fdw bug in 9.6

On 2017/01/11 19:26, Ashutosh Bapat wrote: On Wed, Jan 11, 2017 at 3:30 PM, Etsuro Fujita wrote: On 2017/01/11 17:51, Ashutosh Bapat wrote: On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita wrote: On 2017/01/11 13:40, Ashutosh Bapat wrote: Or it can have foreign paths in there, which will need

Re: [HACKERS] PoC: Grouped base relation

On Mon, Jan 9, 2017 at 11:26 PM, Antonin Houska wrote: > Attached is a draft patch that lets partial aggregation happen at base > relation level. If the relations contain relatively small number of groups, > the number of input rows of the aggregation at the query level can be reduced > this way.

Re: [HACKERS] Parallel bitmap heap scan

On 01/10/2017 05:16 PM, Dilip Kumar wrote: Please try attached patch and confirm from your side. Thanks,issue seems to be fixed now. -- regards,tushar EnterpriseDB https://www.enterprisedb.com/ The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgre

Re: [HACKERS] pgbench - allow backslash continuations in \set expressions

Hello, The attached patch adds backslash-return (well newline really) continuations to all pgbench backslash-commands. The attached test uses continuations on all such commands (sleep set setshell and shell). I think that adding continuations to psql should be a distinct patch. The patch do

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

On 2017/01/05 21:38, Ashutosh Bapat wrote: On Thu, Jan 5, 2017 at 5:51 PM, Etsuro Fujita wrote: On 2017/01/05 21:11, Ashutosh Bapat wrote: On 2017/01/03 17:28, Ashutosh Bapat wrote: Also, in this function, if fpinfo->tlist is already set, why do we want to build it again? IIUC, for a rel

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

On Fri, Jan 6, 2017 at 11:54 AM, Ryan Murphy wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, failed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:tested, passe

Re: [HACKERS] Passing query string to workers

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. Now, for each of the worker when > ExecGetParallelQueryDesc is called, we retrieve the query text from shared

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

=?UTF-8?B?6auY5aKe55Cm?= writes: > In transformDeleteStmt: > qry->hasWindowFuncs = pstate->p_hasWindowFuncs; > qry->hasAggs = pstate->p_hasAggs; > if (pstate->p_hasAggs) > parseCheckAggregates(pstate, qry); > Do we support using agg or window function in delete statement? > O

Re: [HACKERS] WARM and indirect indexes

Pavan Deolasee wrote: > I was going to ask if we could implement indirect indexes as a separate > IndexAM. But I re-read this thread and found that you'd in fact done it > that way in the first version but then discarded it for performance > reasons. Is there a merit in evaluating that path for in

Re: [HACKERS] WARM and indirect indexes

Bruce Momjian wrote: > My point is that anything you add must be weighed against the value it > gives to users who use it, and the percentage of users who will use it. > Against that benefit, you have to look at the cost of exposing that API > to users, code complexity, maintenance, etc. I agree.

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

On Wed, Jan 11, 2017 at 7:36 PM, Simon Riggs wrote: > The specification of the recovery target parameters should be different, IMHO. > > If the user is performing a recovery and the target of the recovery is > incorrectly specified then it is clear that the recovery cannot > continue with an impre

Re: [HACKERS] WARM and indirect indexes

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, really hurts its inclusion. I think you're making this out to be far more c

Re: [HACKERS] proposal: session server side variables

On 11 Jan. 2017 16:29, "Fabien COELHO" wrote: > I'm lost. This is precisely what I had in mind above with "read-only transaction" which is "warranted not to fail". I do not understand about which point you write "No". I misread. We agree. >> Are you "voting" for or against [Pavel's] propos

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

Hello, On Wed, Jan 11, 2017 t 6:06 PM, Beena Emerson wrote: > > > On Fri, Jan 6, 2017 at 11:54 AM, Ryan Murphy > wrote: > >> The following review has been posted through the commitfest application: >> make installcheck-world: tested, failed >> Implements feature: tested, passed >> Spec c

[HACKERS] plpgsql - additional extra checks

Hi I am starting new thread for this patch (related to merging some ideas from plpgsql2 project thread). Here is simple patch with two new extra_warnings, extra_errors checks 1. strict_multi_assignment - checks the number of target variables and source values. 2. too_many_rows - checks if return

Re: [HACKERS] plpgsql - additional extra checks

On Wed, Jan 11, 2017 at 2:54 PM, Pavel Stehule wrote: > 1. strict_multi_assignment - checks the number of target variables and > source values. > I've proposed this before (maybe around a year ago), except the checks were done at parse time, rather than runtime. I much prefer that approach. If

Re: [HACKERS] WARM and indirect indexes

On 11 Jan. 2017 21:29, "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, really hurts its inclusio

Re: [HACKERS] pageinspect: Hash index support

> +itup = (IndexTuple) PageGetItem(uargs->page, id); > + > +MemSet(nulls, 0, sizeof(nulls)); > + > +j = 0; > +values[j++] = UInt16GetDatum(uargs->offset); > +values[j++] = CStringGetTextDatum(psprintf("(%u,%u)", > + > BlockIdGetBlockNumber(&(itup->t_tid.ip_bl

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

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 ../pg_stat_sql_row_mode_2.patch error: patch failed: src/include/catalog/pg_proc.h:2893 error: src/include/catalog/pg_proc.h

Re: [HACKERS] pageinspect: Hash index support

Jesper Pedersen wrote: > + /* > + * 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] plpgsql - additional extra checks

2017-01-11 15:08 GMT+01:00 Marko Tiikkaja : > On Wed, Jan 11, 2017 at 2:54 PM, Pavel Stehule > wrote: > >> 1. strict_multi_assignment - checks the number of target variables and >> source values. >> > > I've proposed this before (maybe around a year ago), except the checks > were done at parse ti

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 and > make it better". I hear this argument a lot

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 to result in the paral

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 something to look at.

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 b

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/ Postg

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

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

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 = epsil

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 str

[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] 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.

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] 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. > > > > > > This is essentially saying "PL/PgSQL isn't perfect, so we sho

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 after

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 of

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 doesn'

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 recovery."))); > I am not sure that th

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 parenthe

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 perfect, so we shouldn't try > and make it

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 ide

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 alread

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 l

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 this config setting >> even when con

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 Join (cost=2.00.

[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 fo

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 to delete at eoxact

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 lock or even a >> predicate lock: it's waiting for a time w

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 >> is owned by the backend in the conven

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 ev

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 for an event > that was on

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, t

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 argument in the > overall scheme of thin

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] 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] 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 > > to clean. Sure, th

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 pri

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] 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 than the > SharedTem

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 ../pg_stat_sql_row_mode_2.patch > error: patch failed: src/

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 reaches EOXact decre

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 functionality > > (performance, resource usage, safety, e

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 forces > a revalidation; and

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] 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 --- there was just no w

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 + IndexInfoFi

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 migr

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 migrate an application t

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

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] 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 understand it, during the desig

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 to result in the paral

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: https://docs.oracl

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 we'd had that enabled by defa

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: http://www.enterprisedb.com The E

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 Herrerahttps://www.2

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, nor >> the hashjoin's o

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 revalidation; and at that

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 per

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 TA

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 > indirect explicitely. Howe

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 >> tuplesort. > > Don't see why. Simply b

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 started is a background w

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. Now, for each of the worker when >> ExecGetParallelQu

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. But please don't confuse it with either >>

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 Webinar: Postgres for Oracle >

  1   2   >