Re: [DOCS] [HACKERS] Questionable tag usage

On Fri, Jan 6, 2017 at 10:18 AM, Tom Lane wrote: >> I don't think there are a lto of people who use dead tree editions anymore, >> but they certainly do exist. A lot of people use the PDFs though, >> particularly for offline reading or loading them in ebook readers. So it >>

Re: [HACKERS] RustgreSQL

Robert Haas writes: > I'm not meaning to be funny or sarcastic or disrespectful when I say > that I think C is the best possible language for PostgreSQL. It works > great, and we've got a ton of investment in making it work. Yeah. There's certainly a whole lot of path

Re: [HACKERS] Off-by-one oddity in minval for decreasing sequences

On Fri, Jan 6, 2017 at 2:15 PM, Daniel Verite wrote: > When testing the patch at https://commitfest.postgresql.org/12/768/ > ("sequence data type" by Peter E.), I notice that there's a preexisting > oddity in the fact that sequences created with a negative increment > in

Re: [HACKERS] RustgreSQL

On Tue, Jan 10, 2017 at 10:55 AM, Tom Lane wrote: > Robert Haas writes: >> I'm not meaning to be funny or sarcastic or disrespectful when I say >> that I think C is the best possible language for PostgreSQL. It works >> great, and we've got a ton of

Re: [DOCS] [HACKERS] Questionable tag usage

On Tue, Jan 10, 2017 at 9:58 AM, Tom Lane wrote: > whether to continue using "see section m.n"-type cross-references For my part, I have a preference for including the section name with the link text, although if it took much work to add it (rather than being the new

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Jan 10, 2017 at 6:42 AM, Masahiko Sawada wrote: > Attached result of performance test with scale factor = 500 and the > test script I used. I measured each test at four times and plot > average of last three execution times to sf_500.png file. When table > has

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Jan 10, 2017 at 6:42 AM, Masahiko Sawada wrote: >> Does this work negate the other work to allow VACUUM to use > >> 1GB memory? > > Partly yes. Because memory space for dead TIDs needs to be allocated > in DSM before vacuum worker launches, parallel lazy vacuum

Re: [DOCS] [HACKERS] Questionable tag usage

On Tue, Jan 10, 2017 at 10:58 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Jan 6, 2017 at 10:18 AM, Tom Lane wrote: I don't think there are a lto of people who use dead tree editions anymore, but they certainly do

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

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. */ > > + Assert(query->jointree != NULL); >

Re: [HACKERS] [PATCH] ALTER DEFAULT PRIVILEGES with GRANT/REVOKE ON SCHEMAS

On Mon, Jan 9, 2017 at 10:58 AM, Ashutosh Sharma wrote: > > Also, should I add translations for that error message in other > languages (I > > can do that without help of tools for pt_BR) or is that a latter process > in > > the releasing? > > > > I think you should add it

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Alvaro Herrera wrote: > Daniel Verite wrote: > > > My tests are OK too but I see an issue with the code in > > enlargeStringInfo(), regarding integer overflow. > > The bit of comment that says: > > > > Note we are assuming here that limit <= INT_MAX/2, else the above > > loop could overflow.

Re: [HACKERS] background sessions

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, and then you can use the existing dblink

Re: [DOCS] [HACKERS] Questionable tag usage

Robert Haas writes: > On Fri, Jan 6, 2017 at 10:18 AM, Tom Lane wrote: >>> I don't think there are a lto of people who use dead tree editions anymore, >>> but they certainly do exist. A lot of people use the PDFs though, >>> particularly for offline

Re: [HACKERS] RustgreSQL

On Tue, Jan 10, 2017 at 7:48 AM, Robert Haas wrote: > I'm not meaning to be funny or sarcastic or disrespectful when I say > that I think C is the best possible language for PostgreSQL. It works > great, and we've got a ton of investment in making it work. I can't > see

Re: [HACKERS] Placement of InvokeObjectPostAlterHook calls

On Fri, Jan 6, 2017 at 12:53 PM, Tom Lane wrote: > While reviewing Etsuro-san's patch to force replanning after FDW option > changes, I noticed that there is a great lack of consistency about where > InvokeObjectPostAlterHook calls have been placed relative to other actions >

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

On Tue, Jan 10, 2017 at 08:31:47AM -0800, David Fetter wrote: > 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] GSoC 2017

2017-01-10 14:53 GMT+05:00 Alexander Korotkov : > 1. What project ideas we have? I have one more project of interest which I can mentor. Topic. GiST API advancement ===Idea=== GiST API was designed at the beginning of 90th to reduce boilerplate code around data access

Re: [HACKERS] pageinspect: Hash index support

On 01/10/2017 10:39 AM, Tom Lane wrote: Robert Haas writes: No, you're missing the point. The patch doesn't need to add pageinspect--1.6.sql at all, nor does it remove pageinspect--1.5.sql. It only needs to add pageinspect--1.5--1.6.sql and change the default version to

Re: [HACKERS] proposal: session server side variables

Hello Craig, I have submitted a proof of this fact in the form of a counter example which (1) (pseudo) implements the use-case by logging into an audit table the fact a user accesses the secure level (2) shows that the status of a non transactional session variable used for keeping this status

Re: [HACKERS] proposal: session server side variables

Hello Robert, You're just ignoring explanations from other people - Craig in particular - about why it DOES satisfy their use case. 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

[HACKERS] Couple of issues with prepared FETCH commands

(This came up on IRC, but I'm not sure to what extent it should be considered a "bug") If you do PQprepare(conn, "myfetch", "FETCH ALL FROM mycursor", ...); then the results are unpredictable in two ways: Firstly, nothing causes the plancache entry to be revalidated just because "mycursor" got

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Alvaro Herrera wrote: > With that, pushed and I hope this is closed for good. Great! I understand the fix couldn't be backpatched because we are not allowed to change the StringInfo struct in existing releases. But it occurs to me that the new "long_ok" flag might not be necessary after

Re: [HACKERS] proposal: session server side variables

I do not like Pavel's feature, this is a subjective opinion. This feature does not provide a correct solution for the use case, this is an objective fact. The presented feature does not have a real use case, this is too bad. Oh, also, you might want to tell Oracle and the many people who use

Re: [HACKERS] Replication/backup defaults

Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Tue, Jan 10, 2017 at 8:03 PM, Robert Haas wrote: > > > On Mon, Jan 9, 2017 at 11:02 AM, Peter Eisentraut > > wrote: > > > On 1/9/17 7:44 AM, Magnus Hagander wrote: > > >> So

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

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: postgres=# CREATE USER user1 LOGIN CONNECTION LIMIT 2; CREATE ROLE postgres=# \c postgres user1

Re: [HACKERS] sequence data type

Peter Eisentraut wrote: > This could probably be sorted out somehow, but I don't want > to be too lax now and cause problems for later features. There is a > similar case, namely changing the return type of a function, which we > also prohibit. Consider the case of a table with a SERIAL

Re: [HACKERS] Replication/backup defaults

On 1/10/17 3:06 PM, Stephen Frost wrote: > * Magnus Hagander (mag...@hagander.net) wrote: >> On Tue, Jan 10, 2017 at 8:03 PM, Robert Haas wrote: >>> I may be outvoted, but I'm still not in favor of changing the default >>> wal_level. That caters only to people who lack

Re: [HACKERS] RustgreSQL

On 01/09/2017 05:54 PM, Joel Jacobson wrote: > On Mon, Jan 9, 2017 at 3:22 PM, Jim Nasby wrote: >> I do wonder if there are parts of the codebase that would be much better >> suited to a language other than C, and could reasonably be ported. >> Especially if that could

Re: [HACKERS] sequence data type

> "Daniel" == Daniel Verite writes: Daniel> Consider the case of a table with a SERIAL column which later Daniel> has to become a BIGINT due to growth. Currently a user would Daniel> just alter the column's type and does need to do anything with Daniel> the

Re: [HACKERS] RustgreSQL

On 10 January 2017 at 23:10, otheus uibk wrote: > Craig, isn't it the case that C++ exceptions still cause tremendous > slow-downs of the entire code-base? No, and it hasn't been so for a long time even for gcc. See e.g.

Re: [HACKERS] proposal: session server side variables

On 11 January 2017 at 06:09, Fabien COELHO wrote: > 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

Re: [HACKERS] Replication/backup defaults

On Wed, Jan 11, 2017 at 10:06 AM, David Steele wrote: > On 1/10/17 3:06 PM, Stephen Frost wrote: >> * Magnus Hagander (mag...@hagander.net) wrote: >>> On Tue, Jan 10, 2017 at 8:03 PM, Robert Haas wrote: > I may be outvoted, but I'm still not in

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

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: > >

Re: [HACKERS] WARM and indirect indexes

On Wed, Jan 11, 2017 at 12:54 AM, Alvaro Herrera wrote: > Two options are on the table to attack the problem of updates causing > write amplification: WARM and indirect indexes. They are completely > different approaches but have overlapping effects on what scenarios

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

On Sat, Dec 31, 2016 at 9:01 AM, Amit Kapila wrote: > Agreed and changed accordingly. > >> 2. It seems that we have missed one unlock in case of absorbed >> wakeups. You have initialised extraWaits with -1 and if there is one >> extra wake up then extraWaits will become 0

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

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 appreciate > some feedback. I have some review feedback for your V3. I've chosen

Re: [HACKERS] WARM and indirect indexes

Bruce Momjian wrote: > 1. What percentage speedup is the _average_ user going to get? You > have to consider people who will use indirect indexes who get no benefit > or a net slowdown, and users who will get a benefit. > > 2. What percentage of users are going to use indirect indexes? > >

[HACKERS] Passing query string to workers

Hello everybody, Currently, query string is not passed to the workers and only master has it. In the events, when multiple queries are running on a server and for one query some worker crashes then it becomes quite burdensome to find the query with the crashed worker, since on the worker crash no

Re: [HACKERS] RustgreSQL

On 2017/01/11 8:02, Josh Berkus wrote: > On 01/09/2017 05:54 PM, Joel Jacobson wrote: >> On Mon, Jan 9, 2017 at 3:22 PM, Jim Nasby wrote: >>> I do wonder if there are parts of the codebase that would be much better >>> suited to a language other than C, and could

Re: [HACKERS] WARM and indirect indexes

On Tue, Jan 10, 2017 at 04:24:42PM -0300, Alvaro Herrera wrote: > Two options are on the table to attack the problem of updates causing > write amplification: WARM and indirect indexes. They are completely > different approaches but have overlapping effects on what scenarios are > improved.

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

On Sat, Dec 3, 2016 at 1:52 PM, Fabien COELHO wrote: > >> FWIW, I looked a bit further and concluded that probably psqlscan.l >> doesn't need to be modified; so likely you could do this across all of >> pgbench's commands without touching psql. That might be an acceptable >>

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

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 when we could run safely with >

Re: [HACKERS] postgres_fdw bug in 9.6

On Fri, Jan 6, 2017 at 6:31 PM, Etsuro Fujita wrote: > On 2017/01/05 12:10, Etsuro Fujita wrote: >> >> On 2016/12/28 17:34, Ashutosh Bapat wrote: >>> >>> Hmm. If I understand the patch correctly, it does not return any path >>> when merge join is allowed and there are

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

Hello, At Fri, 18 Nov 2016 10:58:27 +0100, Emre Hasegeli wrote in > > To keep such kind of integrity, we should deeply consider about > > errors. > > My point is that I don't think we can keep integrity

Re: [HACKERS] sequence data type

On Tue, Jan 10, 2017 at 5:03 AM, Peter Eisentraut wrote: > On 1/8/17 2:39 PM, Steve Singer wrote: >> The only concern I have with the functionality is that there isn't a way >> to change the type of a sequence. > > If we implement the NEXT VALUE FOR expression

Re: [HACKERS] proposal: session server side variables

2017-01-10 7:31 GMT+01:00 Fabien COELHO : > > Hello Robert, > > Half-persistence (in definition, not in value) is not a key feature needed >>> by the use-case. >>> >> >> Well, you don't get to decide that. >> > > I do not think that your reprimand is deserved about this

Re: [DOCS] [HACKERS] Questionable tag usage

On Tue, Jan 10, 2017 at 12:39:57PM -0500, Robert Haas wrote: > Since I've spent a fair amount of brainpower trying to use > rather than where possible, I'm not innately enthusiastic about > a project whose end is to get rid of . I won't lose a lot of > sleep over it if we decide to go that

Re: [HACKERS] WARM and indirect indexes

On Wed, Jan 11, 2017 at 7:55 AM, Bruce Momjian wrote: > On Tue, Jan 10, 2017 at 04:24:42PM -0300, Alvaro Herrera wrote: > > Two options are on the table to attack the problem of updates causing > > write amplification: WARM and indirect indexes. They are completely > >

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

Hi, In transformDeleteStmt: qry->hasWindowFuncs = pstate->p_hasWindowFuncs; qry->hasAggs = pstate->p_hasAggs; if (pstate->p_hasAggs) parseCheckAggregates(pstate, qry); These code set agg and window function status for delete query, but there is no similar code in

Re: [HACKERS] postgres_fdw bug in 9.6

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 it chooses cheap paths for joining relations which may not be

[HACKERS] Obsolete reference to ParallelMain() in a comment

The comment above ParallelQueryMain() still refers to ParallelMain() as its caller which is no longer the case. Attached fixes that. Thanks, Amit diff --git a/src/backend/executor/execParallel.c b/src/backend/executor/execParallel.c index 86d9fb59ba..6cf62daab8 100644 ---

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

On Wed, Dec 14, 2016 at 12:19 AM, Robert Haas wrote: > On Mon, Dec 12, 2016 at 4:31 AM, Gilles Darold > wrote: >> Applied in last version of the patch v18 as well as removing of an >> unused variable. > > OK, this looks a lot closer to being

Re: [HACKERS] parallelize queries containing subplans

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 this restriction in many cases especially when SubPlans are > parallel-safe. To

Re: [DOCS] [HACKERS] Questionable tag usage

On Tue, Jan 10, 2017 at 12:22 PM, Tom Lane wrote: > However, that complaint was already lodged in another thread. What I > think *this* thread is about is whether we ought to switch from the > up-to-now-project-standard style > > ... how to frob your wug (see ) ... > > to

Re: [HACKERS] RustgreSQL

On Tue, Jan 10, 2017 at 12:24 PM, Joshua D. Drake wrote: > In human terms, C is the only one of these that has been around long enough > to realize it isn't a teenager (or child really), and although you may still > be able to do the things you could in your 20s, you are

Re: [DOCS] [HACKERS] Questionable tag usage

Robert Haas writes: > Personally, I think that if the doc toolchain changeover changed the > way xrefs render - and it seems that it did - that's a bug that ought > to be fixed, I quite agree. We'll have enough to do with the toolchain changeover; we don't need random

Re: [HACKERS] Placement of InvokeObjectPostAlterHook calls

Robert Haas writes: > On Fri, Jan 6, 2017 at 12:53 PM, Tom Lane wrote: >> While reviewing Etsuro-san's patch to force replanning after FDW option >> changes, I noticed that there is a great lack of consistency about where >> InvokeObjectPostAlterHook

Re: [HACKERS] RustgreSQL

On 01/10/2017 08:12 AM, Robert Haas wrote: Really? What language would you pick in a vacuum? The Linux kernel is written in C, too, for pretty much the same reasons: it's the canonical language for system software. I don't deny that there may be some newer languages out which could

Re: [HACKERS] pg_restore accepts -j -1

On Tue, Jan 10, 2017 at 10:18 AM, Stephen Frost wrote: > Greetings, > > 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 parallel state being NULL and so things > don't

[HACKERS] Typo in dsa.c

Hi, Attached fixes comment typos in dsa.c. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center fix_typo_in_dsa_c.patch Description: binary/octet-stream -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code

On Fri, Dec 9, 2016 at 3:23 AM, Aleksander Alekseev wrote: >> You could just change it to >> if (str[strspn(str, " \t\n\r\f")] == '\0') >> to mitigate calling strlen. It's safe to do so because strspn will >> only return values from 0 to strlen(str). > >> [...] I have

Re: [HACKERS] WARM and indirect indexes

On Tue, Jan 10, 2017 at 11:36:24PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > > 1. What percentage speedup is the _average_ user going to get? You > > have to consider people who will use indirect indexes who get no benefit > > or a net slowdown, and users who will get a benefit. >

Re: [HACKERS] RustgreSQL

Joel Jacobson j...@trustly.com wrote: > My motivation is primarily I don't want to learn all the over-complicated details of C, That's rich, mate. C is one of the simplest languages. It's simplicity is its main benefit and its biggest drawback: it shields very little from the actual underlying

Re: [HACKERS] Hash support for grouping sets

On Thu, Jan 5, 2017 at 10:48 PM, Andrew Gierth wrote: > Herewith a patch for doing grouping sets via hashing or mixed hashing > and sorting. Cool. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] pageinspect: Hash index support

Robert Haas writes: > No, you're missing the point. The patch doesn't need to add > pageinspect--1.6.sql at all, nor does it remove pageinspect--1.5.sql. > It only needs to add pageinspect--1.5--1.6.sql and change the default > version to 1.6. No other changes are

Re: [HACKERS] Re: new set of psql patches for loading (saving) data from (to) text, binary files

Hi Thank you for review 2017-01-09 17:24 GMT+01:00 Jason O'Donnell : > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: not tested >

Re: [HACKERS] pageinspect: Hash index support

On Fri, Jan 6, 2017 at 1:14 AM, Ashutosh Sharma wrote: >> The previous patch was using pageinspect--1.5.sql as a base, and then uses >> pageinspect--1.5-1.6.sql to upgrade to version 1.6. >> >> Removing pageinspect--1.5.sql, and adding pageinspect--1.6.sql with the >>

Re: [HACKERS] pageinspect: Hash index support

On Tue, Jan 10, 2017 at 12:19 PM, Jesper Pedersen wrote: > Revised patched attached. +itup = (IndexTuple) PageGetItem(uargs->page, id); + +MemSet(nulls, 0, sizeof(nulls)); + +j = 0; +values[j++] = UInt16GetDatum(uargs->offset); +

Re: [HACKERS] PoC: Grouped base relation

On Mon, Jan 9, 2017 at 12:56 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

Re: [HACKERS] PoC: Grouped base relation

On Mon, Jan 9, 2017 at 5:56 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 >

Re: [HACKERS] PoC: Grouped base relation

On Tue, Jan 10, 2017 at 6:52 PM, Pantelis Theodosiou wrote: > > > On Mon, Jan 9, 2017 at 5:56 PM, Antonin Houska wrote: > >> Attached is a draft patch that lets partial aggregation happen at base >> relation level. If the relations contain relatively small

Re: [HACKERS] Replication/backup defaults

On Mon, Jan 9, 2017 at 11:02 AM, Peter Eisentraut wrote: > On 1/9/17 7:44 AM, Magnus Hagander wrote: >> So based on that, I suggest we go ahead and make the change to make both >> the values 10 by default. And that we do that now, because that lets us >> get it

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Mon, Jan 9, 2017 at 3:14 PM, Peter Eisentraut wrote: > To achieve consistent support for specifying the current database, we > would need to change the grammar for every command involving databases. I wouldn't have thought there would be all that many of

Re: [HACKERS] Cache Hash Index meta page.

On Tue, Dec 27, 2016 at 3:06 AM, Mithun Cy wrote: > Thanks, just like _bt_getroot I am introducing a new function > _hash_getbucketbuf_from_hashkey() which will give the target bucket > buffer for the given hashkey. This will use the cached metapage > contents instead

[HACKERS] WARM and indirect indexes

Two options are on the table to attack the problem of updates causing write amplification: WARM and indirect indexes. They are completely different approaches but have overlapping effects on what scenarios are improved. Here's a recap of both features, with the intent that we make a

Re: [HACKERS] Replication/backup defaults

On Tue, Jan 10, 2017 at 8:03 PM, Robert Haas wrote: > On Mon, Jan 9, 2017 at 11:02 AM, Peter Eisentraut > wrote: > > On 1/9/17 7:44 AM, Magnus Hagander wrote: > >> So based on that, I suggest we go ahead and make the change to make both >

Re: [HACKERS] proposal: session server side variables

On Tue, Jan 10, 2017 at 1:31 AM, Fabien COELHO wrote: > I have submitted a proof of this fact in the form of a counter example which > (1) (pseudo) implements the use-case by logging into an audit table the fact > a user accesses the secure level (2) shows that the status of

Re: [HACKERS] merging some features from plpgsql2 project

On 1/10/17 12:06 AM, Pavel Stehule wrote: > A check how much rows was impacted by query is relative often task. So > we can do this task more user friendly. > > Second motivation - ROW_COUNT is working for static and for dynamic SQL > - it can be partial replace of FOUND variable. What is

Re: [HACKERS] _hash_addovflpage has a bug

On Mon, Jan 9, 2017 at 10:46 PM, Amit Kapila wrote: > Yeah, we can write code that way, but then it is better to rely just > on retain_pin variable in the function and add an Assert for bucket > page whenever we are retaining pin. How about doing something like >

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/10/2017 05:24 AM, Ashutosh Sharma wrote: Thanks for reporting this problem. It is basically coming because i forgot to unpin the bucketbuf in hash_xlog_vacuum_one_page(). Please find the attached v5 patch that fixes the issue. The crash is now fixed, but the --- test.sql

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-10 14:26 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 1/10/17 12:06 AM, Pavel Stehule wrote: > > A check how much rows was impacted by query is relative often task. So > > we can do this task more user friendly. > > > > Second motivation - ROW_COUNT is working for

Re: [HACKERS] RustgreSQL

On Monday, January 9, 2017 7:39:49 PM EST Joel Jacobson wrote: > On Mon, Jan 9, 2017 at 6:03 PM, Craig Ringer wrote: > > Immutable functions can and do use functionality from all over the > > server. They just don't depend on user-visible mutable _state_ > > elsewhere in

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> 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, and as long as people keep

Re: [HACKERS] RustgreSQL

On Tue, Jan 10, 2017 at 8:42 AM, Jan de Visser wrote: > Be that as it may, I don't think you have convinced anybody that that is > something worth doing. The fact it *could* be done doesn't mean it *should* be > done. +1. > What you are proposing is not going to happen

Re: [HACKERS] pg_stat_lwlock wait time view

On Mon, Jan 9, 2017 at 12:13 AM, Haribabu Kommi wrote: > Whenever the Backend is waiting for an LWLock, it sends the message to > "stats collector" with PID and wait_event_info of the lock. Once the stats > collector receives the message, Adds that Backend entry to Hash

Re: [HACKERS] Logical Replication WIP

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 >> >> alter subscription mysub disable; >> ALTER

Re: [HACKERS] GSoC 2017

Count me in as a mentor On 10-Jan-2017 3:24 PM, "Alexander Korotkov" wrote: > 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

Re: [HACKERS] GSoC 2017

2017-01-10 14:53 GMT+05:00 Alexander Korotkov : > 1. What project ideas we have? Hi! I'd like to propose project on sorting algorithm research. I’m ready to be a mentor on this project. ===Topic=== Sorting algorithms benchmark and implementation. ===Idea=== Currently

Re: [HACKERS] proposal: session server side variables

On 10 January 2017 at 14:31, Fabien COELHO wrote: > I do not like Pavel's feature, this is a subjective opinion. This feature > does not provide a correct solution for the use case, this is an objective > fact. The presented feature does not have a real use case, this is too

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/05 5:50, Robert Haas wrote: > On Tue, Dec 27, 2016 at 3:59 AM, Amit Langote > wrote: >> Patches 0001 to 0006 unchanged. > > Committed 0001 earlier, as mentioned in a separate email. Committed > 0002 and part of 0003. Thanks! I realized however that the

Re: [HACKERS] Microvacuum support for Hash Index

Hi Jesper, > However (master / WAL v7 / MV v4), > > --- ddl.sql --- > CREATE TABLE test AS SELECT generate_series(1, 10) AS id, 0 AS val; > CREATE INDEX IF NOT EXISTS idx_id ON test USING hash (id); > CREATE INDEX IF NOT EXISTS idx_val ON test USING hash (val); > ANALYZE; > --- ddl.sql --- > >

Re: [HACKERS] Parallel bitmap heap scan

On 01/10/2017 11:29 AM, tushar wrote: On 01/09/2017 07:22 PM, Dilip Kumar wrote: Thanks, Tushar. I have fixed it. The defect was in 0002. I have also observed another issue related to code refactoring, Actually, there was some code present in 0001 which supposed to be in 0003. Thanks, I have

Re: [HACKERS] Block level parallel vacuum WIP

On Mon, Jan 9, 2017 at 6:01 PM, Simon Riggs wrote: > On 9 January 2017 at 08:48, Masahiko Sawada wrote: > >> I had not considered necessity of dead lock detection support. > > It seems like a big potential win to scan multiple indexes in parallel. >

[HACKERS] GSoC 2017

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 mentoring organizations has been changed. In particular, it required more

Re: [HACKERS] Declarative partitioning - another take

Hi Amul, On 2017/01/09 17:29, amul sul wrote: > I got server crash due to assert failure at ATTACHing overlap rang > partition, here is test case to reproduce this: > > CREATE TABLE test_parent(a int) PARTITION BY RANGE (a); > CREATE TABLE test_parent_part2 PARTITION OF test_parent FOR VALUES >

Re: [HACKERS] Declarative partitioning - another take

Hi Kieth, On 2017/01/10 14:44, Keith Fiske wrote: > Is there any reason for the exclusion of parent tables from the pg_tables > system catalog view? They do not show up in information_schema.tables as > well. I believe I found where to make the changes and I tested to make sure > it works for my

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

On Wed, Jan 4, 2017 at 4:32 PM, Andres Freund wrote: > Hi, > > On 2017-01-03 10:37:08 -0500, Stephen Frost wrote: >> * Vladimir Rusinov (vrusi...@google.com) wrote: >> > I think I +1 on this. >> > I've did a github search on these function names and there is a lot of code >> >

Re: [HACKERS] proposal: session server side variables

On 10 January 2017 at 14:31, Fabien COELHO wrote: > I have submitted a proof of this fact in the form of a counter example which > (1) (pseudo) implements the use-case by logging into an audit table the fact > a user accesses the secure level (2) shows that the status of a

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Jan 10, 2017 at 2:19 PM, tushar wrote: > We found a regression , earlier the testcase was working fine (against the > older patches of Parallel bitmap heap scan) but now getting a server crash > against v8 patches. > > Testcase - (one of the table of TPC-H

Re: [HACKERS] postgres_fdw bug in 9.6

> >> If the inner and/or outer paths are not ordered as required, we will need >> to >> order them. Code below doesn't seem to handle that case. >> /* >> * If the paths are already well enough ordered, we >> can >> * skip doing an

  1   2   >