Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

I wrote: > However ... one thing I was intending to mention on this thread is that > "get the array type over this type" isn't the only extension one might > wish for. Another likely desire is "get the type of field 'foo' of this > composite type". I don't suggest that this patch needs to

Re: [HACKERS] pg_dump dump catalog ACLs

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Joe Conway writes: > > Would it be a terrible idea to add some attribute to ACLs which can be > > used to indicate they should not be dumped (and supporting syntax)? > > Yes, we'd need some way to mark non-null ACLs as being

[HACKERS] Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

14.03.2016 16:23, David Steele: On 2/25/16 4:44 PM, Vitaly Burovoy wrote: Added to the commitfest 2016-03. [CF] https://commitfest.postgresql.org/9/540/ This looks like a fairly straight-forward bug fix (the size of the patch is deceptive because there a lot of new tests included). It

Re: [HACKERS] unexpected result from to_tsvector

On 14.03.2016 16:22, Shulgin, Oleksandr wrote: Hm... now that doesn't look all that consistent to me (after applying the patch): =# select ts_debug('simple', 'a...@123-yyy.zzz'); ts_debug

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Joe Conway writes: > This new version of the patch was posted after the commitfest item was > marked ready for committer. Does anyone have further comments or > objections to the concept or syntax before I try to take this forward? The quoted excerpt fails to say what

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

On 2/23/16 2:17 AM, Michael Paquier wrote: As a continuation of the thread firstly dedicated to SCRAM: http://www.postgresql.org/message-id/55192afe.6080...@iki.fi Here is a new thread aimed at gathering all the ideas of this previous thread and aimed at clarifying a bit what has been discussed

Re: [HACKERS] [PATCH] Use correct types and limits for PL/Perl SPI query results

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > 1) Perl's integers are at least pointer-sized and either signed or >unsigned, so can potentially hold up to 2⁶⁴-1. Floating point numbers >can also be larger than double (up to 128bit), allowing for exact >

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

Hi Jeff, On 2/25/16 5:00 PM, Jeff Janes wrote: But, It doesn't sound like I am going to win that debate. Given that, I don't think we need a different name for the function. I'm fine with explaining the word-boundary subtlety in the documentation, and keeping the function name itself simple.

[HACKERS] [PATCH] Use correct types and limits for PL/Perl SPI query results

Hi hackers, Commit 23a27b039d94ba359286694831eafe03cd970eef changed the type of numbers-of-tuples-processed counters to uint64 and adjusted various PLs to cope with this. I noticed the PL/Perl changes did not take full advantage of what Perl is capable of handling, so here's a patch that

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

On Mon, Mar 14, 2016 at 4:32 PM, David Steele wrote: > On 2/23/16 2:17 AM, Michael Paquier wrote: > >> As a continuation of the thread firstly dedicated to SCRAM: >> http://www.postgresql.org/message-id/55192afe.6080...@iki.fi >> Here is a new thread aimed at gathering all

Re: [HACKERS] proposal: function parse_ident

I afraid so I cannot to fix this inconsistency (if this is inconsistency - the binary values are same) - the parameter of function is raw string with processed escape codes, and I have not any information about original escape sequences. When you enter octet value, and I show it as hex value,

Re: [HACKERS] [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

> On Mar 14, 2016, at 6:23 AM, David Steele wrote: > > On 2/25/16 4:44 PM, Vitaly Burovoy wrote: > >> Added to the commitfest 2016-03. >> >> [CF] https://commitfest.postgresql.org/9/540/ > > This looks like a fairly straight-forward bug fix (the size of the patch is >

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

On 14.03.2016 18:48, David Steele wrote: Hi Jeff, On 2/25/16 5:00 PM, Jeff Janes wrote: But, It doesn't sound like I am going to win that debate. Given that, I don't think we need a different name for the function. I'm fine with explaining the word-boundary subtlety in the documentation, and

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Jim Nasby wrote: > On 3/13/16 12:48 AM, Pavel Stehule wrote: > >crosstabview is really visualization tool. **But now, there are not any > >other tool available from terminal.** So this can be significant help to > >all people who would to use this functionality. > > Not just the terminal either.

[HACKERS] Re: [COMMITTERS] pgsql: Refactor to create generic WAL page read callback

Simon Riggs wrote: > Refactor to create generic WAL page read callback > > Previously we didn’t have a generic WAL page read callback function, > surprisingly. Logical decoding has logical_read_local_xlog_page(), which was > actually generic, so move that to xlogfunc.c and rename to >

Re: [HACKERS] pg_stat_get_progress_info(NULL) blows up

Thomas Munro writes: > I guess pg_stat_get_progress_info should either be strict (see > attached) or check for NULL. Pushed, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] remove wal_level archive

On Mon, Mar 14, 2016 at 12:50 PM, David Steele wrote: > On 3/11/16 1:29 PM, David Steele wrote: > >> Unless anyone has objections I would like to mark this 'ready for >> committer'. > > > This patch is now ready for committer. Yes, thanks, I am cool with this version as

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 11:40 AM, Vladimir Borodin wrote: > 12 марта 2016 г., в 13:59, Amit Kapila написал(а): >> I think here another point which needs more thoughts is that many of the >> pg_stat_activity fields are not relevant for background

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 14.03.2016 17:54, Tom Lane wrote: Joe Conway writes: This new version of the patch was posted after the commitfest item was marked ready for committer. Does anyone have further comments or objections to the concept or syntax before I try to take this forward? The

Re: [HACKERS] Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system

[Aside: your new mail editor is rewrapping lines in quoted material, and the result is messy. I have rerewrapped one paragraph below.] On Mon, Mar 14, 2016 at 02:00:03AM +0100, Tomas Vondra wrote: > On Sun, 2016-03-13 at 18:46 -0400, Noah Misch wrote: > > I've not attempted to study the behavior

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On 11 March 2016 at 20:15, Alvaro Herrera wrote: > Craig Ringer wrote: > > Hi all > > > > I think I found a couple of logical decoding issues while writing tests > for > > failover slots. > > > > Despite the docs' claim that a logical slot will replay data "exactly > >

Re: [HACKERS] Obsolete comment in postgres_fdw.c

On 2016/03/14 16:42, Ashutosh Bapat wrote: On Mon, Mar 14, 2016 at 9:05 AM, Etsuro Fujita > wrote: Here is the comments for foreign_join_ok in postgres_fdw.c: /* * Assess whether the join between inner and outer

Re: [HACKERS] Use %u to print user mapping's umid and userid

Hi, On 2016/02/09 14:09, Ashutosh Bapat wrote: Sorry, I was wrong. For public user mapping userid is 0 (InvalidOid), which is returned as is in UserMapping object. I confused InvalidOid with -1. I think the following umid handling in postgresGetForeignPlan has the same issue: /* *

Re: [HACKERS] Use %u to print user mapping's umid and userid

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita > Sent: Monday, March 14, 2016 4:59 PM > To: Ashutosh Bapat; Tom Lane > Cc: pgsql-hackers > Subject: Re: [HACKERS] Use %u to print user mapping's umid

Re: [HACKERS] Use %u to print user mapping's umid and userid

On Mon, Mar 14, 2016 at 1:29 PM, Etsuro Fujita wrote: > Hi, > > On 2016/02/09 14:09, Ashutosh Bapat wrote: > >> Sorry, I was wrong. For public user mapping userid is 0 (InvalidOid), >> which is returned as is in UserMapping object. I confused InvalidOid >> with -1.

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On 14 March 2016 at 17:16, Petr Jelinek wrote: > It will not change the fact that slot can go backwards Sure. I don't consider that a problem in general though. It's similar to the way we lose cached sequence chunks on crash - a performance optimisation with a user

Re: [HACKERS] Obsolete comment in postgres_fdw.c

On Mon, Mar 14, 2016 at 9:05 AM, Etsuro Fujita wrote: > Hi, > > Here is the comments for foreign_join_ok in postgres_fdw.c: > > /* > * Assess whether the join between inner and outer relations can be > pushed down > * to the foreign server. As a side effect, save

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On 14/03/16 08:08, Craig Ringer wrote: On 11 March 2016 at 20:15, Alvaro Herrera > wrote: Craig Ringer wrote: > Hi all > > I think I found a couple of logical decoding issues while writing tests for > failover

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On 14/03/16 10:48, Craig Ringer wrote: You btw can emulate asking for the specific LSN in SQL interface by first calling the pg_logical_slot_get_changes function with upto_lsn set to whatever lsn you expect to start at, but it's ugly. Ugh. I didn't realise

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, While I am still looking at this WIP patch, I had one suggestion. Instead of making changes in the index AM API can we have a call to update the shared state using pgstat_progress* API directly from specific index level code? Like pgstat_count_index_scan(rel) call from _bt_first does.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat

On Mon, Mar 14, 2016 at 8:21 AM, Tom Lane wrote: > Etsuro Fujita writes: > > On 2016/03/13 4:46, Andres Freund wrote: > >> ... The difference apears to be the > >> check that's now in build_simple_rel() - there was nothing hitting the > >> user

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Wed, Feb 10, 2016 at 12:33 AM, Daniel Verite wrote: > Shulgin, Oleksandr wrote: > > > Most importantly, I'd like to learn of better options than storing the > > whole last_result in psql's pset structure. > > I guess that you could, each time a query fails,

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hi, Thanks for taking a look at the patch. On Mon, Mar 14, 2016 at 6:55 PM, Rahila Syed wrote: > Hello, > > While I am still looking at this WIP patch, I had one suggestion. > > Instead of making changes in the index AM API can we have a call to update > the shared state

Re: [HACKERS] Sanity checking for ./configure options?

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Looks good to me. It only allows valid number between 1 and 65535,

Re: [HACKERS] psql metaqueries with \gexec

> > > I'm getting a warning from this patch: > > 1 warning generated. > Fixed that one. (note that I'm using CC='ccache clang -Qunused-arguments > -fcolor-diagnostics') > > for (r = 0; r < nrows; r++) >> { >> for (c = 0; c < ncolumns; c++) >> { >>

Re: [HACKERS] remove wal_level archive

On 3/11/16 1:29 PM, David Steele wrote: Unless anyone has objections I would like to mark this 'ready for committer'. This patch is now ready for committer. -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Batch update of indexes

Hi Konstantin, On 2/3/16 11:47 AM, Konstantin Knizhnik wrote: Attached please find patch for "ALTER INDEX ... WHERE ..." clause. It is now able to handle all three possible situations: 1. Making index partial (add WHERE condition to the ordinary index) 2. Extend partial index range (less

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

On 2/18/16 6:54 AM, Kyotaro HORIGUCHI wrote: First, I rebased the previous patch set and merged three of them. Now they are of three patches. 1. Making SQL parser part of psqlscan independent from psql. Moved psql's baskslsh command stuff out of original psqlscan.l and some psql

Re: [HACKERS] Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system

Hi, On 03/14/2016 07:14 AM, Noah Misch wrote: [Aside: your new mail editor is rewrapping lines in quoted material, and the result is messy. I have rerewrapped one paragraph below.] Thanks, I've noticed that too. I've been testing Evolution in the past few days, and apparently the line

Re: [HACKERS] [WIP] speeding up GIN build with parallel workers

On 2/18/16 10:10 AM, Constantin S. Pan wrote: On Wed, 17 Feb 2016 23:01:47 +0300 Oleg Bartunov wrote: My feedback is (Mac OS X 10.11.3) set gin_parallel_workers=2; create index message_body_idx on messages using gin(body_tsvector); LOG: worker process: parallel worker

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

Hi Thomas, On 2/24/16 11:21 AM, Tomas Vondra wrote: Overall, I still believe the FK patch is a clear improvement of the current status - while it's true it does not improve all possible cases and there's a room for additional improvements (like handling multiple candidate FK constraints), it

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

Hi Anastasia, On 2/18/16 12:29 PM, Anastasia Lubennikova wrote: 18.02.2016 20:18, Anastasia Lubennikova: 04.02.2016 20:16, Peter Geoghegan: On Fri, Jan 29, 2016 at 8:50 AM, Anastasia Lubennikova wrote: I fixed it in the new version (attached). Thank you for

Re: [HACKERS] Prepared Statement support for Parallel query

On Fri, Feb 26, 2016 at 4:37 PM, Robert Haas wrote: > > > And, I'm going to revert this part. If you'd run the regression tests > under force_parallel_mode=regress, max_parallel_degree>0, you would > have noticed that this part breaks it, because of CREATE TABLE ... AS >

[HACKERS] Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

On 2/25/16 4:44 PM, Vitaly Burovoy wrote: Added to the commitfest 2016-03. [CF] https://commitfest.postgresql.org/9/540/ This looks like a fairly straight-forward bug fix (the size of the patch is deceptive because there a lot of new tests included). It applies cleanly. Anastasia, I see

Re: [HACKERS] unexpected result from to_tsvector

On Mon, Mar 7, 2016 at 10:46 PM, Artur Zakirov wrote: > Hello, > > On 07.03.2016 23:55, Dmitrii Golub wrote: > >> >> >> Hello, >> >> Should we added tests for this case? >> > > I think we should. I have added tests for teo...@123-stack.net and > 1...@stack.net emails. >

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Fri, Mar 11, 2016 at 7:45 PM, Peter Geoghegan wrote: > On Fri, Mar 11, 2016 at 4:30 PM, Jim Nasby wrote: >> Right, but you still have the option to enable them if you don't want to >> swamp your IO system. That's why CIC obeys it too. If I was

Re: [HACKERS] WIP: Upper planner pathification

On Mon, Mar 14, 2016 at 1:37 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Mar 14, 2016 at 1:04 PM, Tom Lane wrote: >>> It would be better if we invent an FDW callback that's meant to be >>> invoked at this stage, but only

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

On Sun, Mar 13, 2016 at 9:53 PM, Kouhei Kaigai wrote: > OK, I split the previous small patch into two tiny patches. > The one is bugfix around max length of the extnodename. > The other replaces Assert() by ereport() according to the upthread discussion. Committed, except

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

On 2/26/16 11:37 PM, Amit Kapila wrote: On Sat, Feb 27, 2016 at 10:03 AM, Amit Kapila

Re: [HACKERS] Obsolete comment in postgres_fdw.c

On Mon, Mar 14, 2016 at 4:31 AM, Etsuro Fujita wrote: >> It was left there intentionally to document all the conditions in one >> place (some from the core and some from the FDW itself), for a ready >> reference. In case tomorrow core thinks that matching user mapping

Re: [HACKERS] [PATCH] Use correct types and limits for PL/Perl SPI query results

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Tom Lane writes: >> I thought about using UV where feasible, but it was not clear to me >> whether unsigned numbers behave semantically differently from signed ones >> in Perl. If they do, the change you

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Tue, Mar 15, 2016 at 6:58 AM, Robert Haas wrote: > On Sun, Mar 13, 2016 at 11:50 PM, Thomas Munro > wrote: >> The last patches I posted don't apply today due to changes in master, >> so here's a freshly merged patch series. > > +

Re: [HACKERS] [PATCH] Obsolete wording in PL/Perl comment

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > The comment in hv_store_string() says that negative key length to > hv_store() for UTF-8 is not documented, and mentions that 5.6 doesn't > track UTF-8-ness of keys. However, the negative length convention has > been

Re: [HACKERS] [PATCH] we have added support for box type in SP-GiST index

On 2/15/16 10:29 AM, Teodor Sigaev wrote: It's very pity but author is not able to continue work on this patch, and I would like to raise this flag. I'd like to add some comments about patches: traversalValue patch adds arbitrary value assoсiated with branch in SP-GiST tree walk. Unlike to

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

Hi Abhijit, On 3/1/16 8:36 AM, Jim Nasby wrote: On 2/29/16 10:33 PM, Abhijit Menon-Sen wrote: >Given the audience for this, I think it'd probably be OK to just >provide a function that does this, instead of DDL. That seems like a promising idea. Can you suggest some possible usage?

Re: [HACKERS] Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat

Robert Haas writes: > On Sun, Mar 13, 2016 at 10:51 PM, Tom Lane wrote: >> I'm not really sold on enforcing that people create meaningless user >> mappings. For one thing, they're likely to be sloppy about it, which >> could lead to latent security

Re: [HACKERS] [PATCH] Use correct types and limits for PL/Perl SPI query results

Tom Lane writes: > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: >> 1) Perl's integers are at least pointer-sized and either signed or >>unsigned, so can potentially hold up to 2⁶⁴-1. Floating point numbers >>can also be larger than double (up

Re: [HACKERS] Prepared Statement support for Parallel query

On Mon, Mar 14, 2016 at 9:18 AM, Amit Kapila wrote: > On Fri, Feb 26, 2016 at 4:37 PM, Robert Haas wrote: >> And, I'm going to revert this part. If you'd run the regression tests >> under force_parallel_mode=regress, max_parallel_degree>0, you

Re: [HACKERS] Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat

On Mon, Mar 14, 2016 at 1:05 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Mar 13, 2016 at 10:51 PM, Tom Lane wrote: >>> I'm not really sold on enforcing that people create meaningless user >>> mappings. For one thing,

Re: [HACKERS] WIP: Upper planner pathification

On Mon, Mar 14, 2016 at 1:04 PM, Tom Lane wrote: > Petr Jelinek writes: >> On 14/03/16 02:43, Kouhei Kaigai wrote: >>> Even though I couldn't check the new planner implementation entirely, >>> it seems to be the points below are good candidate to inject

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Sun, Mar 13, 2016 at 11:50 PM, Thomas Munro wrote: > The last patches I posted don't apply today due to changes in master, > so here's a freshly merged patch series. +from the current synchronous stanbyindicates it has received the Uh, no. -

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

> 10 марта 2016 г., в 14:38, Simon Riggs написал(а): > > On 10 March 2016 at 09:22, Michael Paquier > wrote: > On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Sat, Mar 12, 2016 at 7:49 AM, Amit Langote wrote: > On Fri, Mar 11, 2016 at 2:31 PM, Amit Langote > wrote: >> On 2016/03/11 13:16, Robert Haas wrote: >>> On Thu, Mar 10, 2016 at 9:04 PM, Amit Langote >>>

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On Sat, Mar 12, 2016 at 11:21 AM, Robert Haas wrote: > I'd also be interested in hearing Kevin Grittner's thoughts about > serializability in a distributed environment, since he's obviously > thought about the topic of serializability quite a bit. I haven't done a

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Jim Nasby wrote: > Ultimately I'd really like some way to remove/reduce the restriction of > result set definitions needing to be determined at plan time. That would > open the door for server-side crosstab/pivot as well a a host of other > things (such as dynamically turning a

Re: [HACKERS] WIP: Upper planner pathification

Petr Jelinek writes: > On 14/03/16 02:43, Kouhei Kaigai wrote: >> Even though I couldn't check the new planner implementation entirely, >> it seems to be the points below are good candidate to inject CustomPath >> (and potentially ForeignScan). >> >> - create_grouping_paths

Re: [HACKERS] WIP: Upper planner pathification

Robert Haas writes: > On Mon, Mar 14, 2016 at 1:04 PM, Tom Lane wrote: >> It would be better if we invent an FDW callback that's meant to be >> invoked at this stage, but only call it for FDW(s) actively involved >> in the query. I'm not sure exactly

[HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On 2/24/16 12:40 AM, Michael Paquier wrote: This has the merit to be clear, thanks for the input. Whatever the approach taken at the end we have two candidates: - Extend XLogInsert() with an extra argument for flags (Andres) - Introduce XLogInsertExtended with this extra argument and let

Re: [HACKERS] WIP: Upper planner pathification

Robert Haas writes: > On Mon, Mar 14, 2016 at 1:37 PM, Tom Lane wrote: >> Yeah. An alternative definition that would support that would be to >> call the upper-path-providing callback for each FDW that's responsible >> for any base relation of the

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On Sat, Mar 12, 2016 at 10:34 AM, Daniel Verite wrote: >> But worse than either of those things, there is no real >> agreement on what the overall design of this feature >> should be. > > The part in the design that raised concerns upthread is > essentially how headers

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On Mon, Mar 14, 2016 at 12:04 PM, Tom Lane wrote: > I wrote: >> However ... one thing I was intending to mention on this thread is that >> "get the array type over this type" isn't the only extension one might >> wish for. Another likely desire is "get the type of field 'foo'

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

Hi Fabien, On 3/14/16 3:27 PM, Fabien COELHO wrote: >> Any takers to review this updated patch? > > I intend to have a look at it, I had a look at a previous instance, but > I'm ok if someone wants to proceed. There's not exactly a long line of reviewers at the moment so if you could do a

Re: [HACKERS] WIP: Upper planner pathification

Robert Haas writes: > On Mon, Mar 14, 2016 at 1:37 PM, Tom Lane wrote: >> Yeah. An alternative definition that would support that would be to >> call the upper-path-providing callback for each FDW that's responsible >> for any base relation of the

Re: [HACKERS] Background Processes and reporting

On Mon, Mar 14, 2016 at 3:54 PM, Vladimir Borodin wrote: > 5. Show extra information about wait event (i.e. exclusive of shared mode > for LWLocks, relation/forknum/blknum for I/O operations, etc.). I doubt that this is a good idea. Everybody will pay the cost of it, and who

Re: [HACKERS] Fix for OpenSSL error queue bug

On Thu, Mar 10, 2016 at 8:16 PM, Peter Geoghegan wrote: > On Thu, Mar 10, 2016 at 7:22 PM, Peter Eisentraut wrote: >> Arguably, if everyone followed "my" approach, this should be very easy >> to fix everywhere. > > I don't think that there is any clear

Re: [HACKERS] Background Processes and reporting

> 14 марта 2016 г., в 22:21, Robert Haas написал(а): > > On Sat, Mar 12, 2016 at 6:05 AM, Oleg Bartunov wrote: >>> So? >> >> So, Robert already has experience with the subject, probably, he has bad >> experience with edb implementation and he'd

Re: [HACKERS] [PATCH v6] GSSAPI encryption support

On 3/14/16 4:10 PM, Robbie Harwood wrote: > David Steele writes: > >> Hi Robbie, >> >> On 3/8/16 5:44 PM, Robbie Harwood wrote: >>> Hello friends, >>> >>> Here's yet another version of GSSAPI encryption support. It's also >>> available for viewing on my github: >> >> The

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

"Shulgin, Oleksandr" writes: > What I dislike about this POC is all the disruption in libpq, to be > honest. Yeah, I don't much like that either. But I don't think we can avoid some refactoring there; as designed, conversion of an error message into user-visible

[HACKERS] Upcoming back-branch releases

In view of some rather important recent fixes such as commits bf7ced5e2dc8622f and 301cc3549c29aaa5, the release team has decided that it'd be a good thing to schedule a set of minor releases in the near future. The nearest convenient time seems to be week after next, that is, wrap Monday Mar 28

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 6:05 AM, Oleg Bartunov wrote: >> So? > > So, Robert already has experience with the subject, probably, he has bad > experience with edb implementation and he'd like to see something better in > community version. That's fair and I accept his position.

Re: [HACKERS] Background Processes and reporting

Hi, On 2016-03-14 16:16:43 -0400, Robert Haas wrote: > > I have already shown [0, 1] the overhead of measuring timings in linux on > > representative workload. AFAIK, these tests were the only one that showed > > any numbers. All other statements about terrible performance have been and > >

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

Hello David, Any takers to review this updated patch? I intend to have a look at it, I had a look at a previous instance, but I'm ok if someone wants to proceed. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Mon, Mar 14, 2016 at 10:39 AM, Robert Haas wrote: > I don't particularly like that interface. I also suggest that it > would be better to leave throttling to a future commit, and focus on > getting the basic feature in first. Works for me. I don't think throttling is

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

Hi, On 03/14/2016 02:12 PM, David Steele wrote: Hi Thomas, ... I don't think it would be clear to any reviewer which patch to apply even if they were working. I'm marking this "waiting for author". Yeah. Rebasing the patches to current master was simple enough (there was just a simple

Re: [HACKERS] Parallel Aggregate

On Sun, Mar 13, 2016 at 7:31 PM, David Rowley wrote: > On 14 March 2016 at 14:52, James Sewell wrote: >> One question - how is the upper limit of workers chosen? > > See create_parallel_paths() in allpaths.c. Basically the bigger the >

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

On 2016-01-31 05:09:33 +0800, Craig Ringer wrote: > On 29 January 2016 at 18:16, Andres Freund wrote: > > > Hi, > > > > so, I'm reviewing the output of: > > > > Thankyou very much for the review. Afaics you've not posted an updated version of this? Any chance you could?

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Robert Haas writes: > On Mon, Mar 14, 2016 at 12:04 PM, Tom Lane wrote: >> Or in short: maybe it's time to blow up %TYPE and start fresh. > That's not a dumb idea. I think %TYPE is an Oracle-ism, and it > doesn't seem to have been their best-ever

Re: [HACKERS] Parallel Aggregate

On Sun, Mar 13, 2016 at 5:44 PM, David Rowley wrote: > On 12 March 2016 at 16:31, David Rowley wrote: >> I've attached an updated patch which is based on commit 7087166, >> things are really changing fast in the grouping path area at

Re: [HACKERS] Background Processes and reporting

On 2016-03-12 16:29:11 +0530, Amit Kapila wrote: > On Sat, Mar 12, 2016 at 3:10 AM, Andres Freund wrote: > > > > > > > Similarly for the wait event stuff - checkpointer, wal writer, > > > background writer are in many cases processes that very often are > > > blocked on locks,

Re: [HACKERS] [PATCH v6] GSSAPI encryption support

David Steele writes: > Hi Robbie, > > On 3/8/16 5:44 PM, Robbie Harwood wrote: >> Hello friends, >> >> Here's yet another version of GSSAPI encryption support. It's also >> available for viewing on my github: > > The build went fine but when testing I was unable to logon

Re: [HACKERS] Parallel Aggregate

On Mon, Mar 14, 2016 at 3:56 PM, Paul Ramsey wrote: > On Sun, Mar 13, 2016 at 7:31 PM, David Rowley > wrote: >> On 14 March 2016 at 14:52, James Sewell wrote: >>> One question - how is the upper limit of workers

Re: [HACKERS] Timeline following for logical slots

On 2016-03-14 20:10:58 -0300, Alvaro Herrera wrote: > Great, thanks. I've studied this to the point where I'm confident that > it makes sense, so I'm about to push it. I didn't change any logic, > only updated comments here and there, both in the patch and in some > preexisting code. I also

Re: [HACKERS] Parallel Aggregate

On Mon, Mar 14, 2016 at 6:24 PM, James Sewell wrote: > Any chance of getting a GUC (say min_parallel_degree) added to allow setting > the initial value of parallel_degree, then changing the small relation check > to also pass if parallel_degree > 1? > > That way you

Re: [HACKERS] [PATCH v6] GSSAPI encryption support

On 3/14/16 7:20 PM, Robbie Harwood wrote: > David Steele writes: > >> >> Strange timing since I was just testing this. Here's what I got: >> >> $ pg/bin/psql -h localhost -U vagr...@pgmasters.net postgres >> conn->inStart = 179, conn->inEnd = 179, conn->inCursor = 179 >>

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-03-14 20:38 GMT+01:00 Tom Lane : > Robert Haas writes: > > On Mon, Mar 14, 2016 at 12:04 PM, Tom Lane wrote: > >> Or in short: maybe it's time to blow up %TYPE and start fresh. > > > That's not a dumb idea. I think %TYPE is an

Re: [HACKERS] Background Processes and reporting

On Mon, Mar 14, 2016 at 4:42 PM, Andres Freund wrote: > On 2016-03-14 16:16:43 -0400, Robert Haas wrote: >> > I have already shown [0, 1] the overhead of measuring timings in linux on >> > representative workload. AFAIK, these tests were the only one that showed >> > any

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Pavel Stehule writes: > Where you are expecting the implementation? In PLpgSQL only, or generally > in DDL, or in both levels? I'd envision this as something the main parser does and plpgsql piggybacks on. One of the many half-baked things about %TYPE is that the main

Re: [HACKERS] Fix for OpenSSL error queue bug

Peter Geoghegan writes: > On Mon, Mar 14, 2016 at 3:06 PM, Tom Lane wrote: >> Agreed, we need to deal with this one way or the other. My proposal >> is: >> >> 1. In HEAD, do it as Peter E. suggests, ie clear error queue before calls. >> >> 2. In back

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 1:58 AM, Amit Kapila wrote: > Yeah, that makes the addition of test for this functionality difficult. > Robert, do you have any idea what kind of test would have caught this issue? Yep. Committed with that test: DO $$ BEGIN EXECUTE

Re: [HACKERS] Parallel Aggregate

On Tue, Mar 15, 2016 at 9:32 AM, Robert Haas wrote: > > I kind of doubt this would work well, but somebody could write a patch > for it and try it out. OK I'll give this a go today and report back. Would the eventual plan be to use pg_proc.procost for the functions from

  1   2   >