Re: [HACKERS] Proposal: BSD Authentication support

On Sat, Mar 12, 2016 at 5:14 AM, David Steele wrote: > On 1/14/16 11:22 PM, Robert Haas wrote: >> On Tue, Jan 12, 2016 at 2:27 AM, Marisa Emerson wrote: >>> I've attached the latest version of this patch. I've fixed up an issue with >>> the configuration scripts that I missed. >> Looks reasonable

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

On 2016/03/12 6:31, Peter Geoghegan wrote: > On Thu, Mar 10, 2016 at 9:18 AM, Tomas Vondra > wrote: >> I've looked at this patch today, mostly to educate myself, so this >> probably should not count as a full review. Anyway, the patch seems in >> excellent shape - it'd be great if all patches (inc

Re: [HACKERS] propose: detail binding error log

On 15 March 2016 at 10:52, Ioseph Kim wrote: > Hi, hackers. > > I had a error message while using PostgreSQL. > > "ERROR: 42804: column "a" is of type boolean but expression is of type > integer at character 25 > LOCATION: transformAssignedExpr, parse_target.c:529" > > This error is a java jdbc

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

On Tue, Mar 15, 2016 at 5:22 AM, Robert Haas wrote: > > 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 te

Re: [HACKERS] propose: detail binding error log

thanks for reply. value of log_statement is already 'all' I set log_min_messages = debug5, log_error_verbosity = verbose and debug_print_parse = on too. but I could not a value of client in server log. this case is occured only at jdbc prepare statement and wrong type binding. reguards, Ioseph.

Re: [HACKERS] [PATCH] Logical decoding support for sequence advances

On 11 March 2016 at 22:24, Petr Jelinek wrote: > On 02/03/16 08:05, Craig Ringer wrote: > >> On 1 March 2016 at 05:30, Petr Jelinek > > wrote: >> > > >> >> I wonder if it would be acceptable to create new info flag for >> RM_SEQ_ID that would behave just like

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

On 2016/03/15 3:41, Robert Haas wrote: > On Sat, Mar 12, 2016 at 7:49 AM, Amit Langote wrote: >> Instead, the attached patch adds a IndexBulkDeleteProgressCallback >> which AMs should call for every block that's read (say, right before a >> call to ReadBufferExtended) as part of a given vacuum run

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

On Tue, Mar 15, 2016 at 12:00 AM, David Steele wrote: > > On 2/26/16 11:37 PM, Amit Kapila wrote: > >> On Sat, Feb 27, 2016 at 10:03 AM, Amit Kapila > >> Here, we can see that there is a gain of ~15% to ~38% at higher >> client count. >> >> The attached document (perf_write_clogcontrol

Re: [HACKERS] Prepared Statement support for Parallel query

On Tue, Mar 15, 2016 at 12:21 AM, Robert Haas wrote: > > On Mon, Mar 14, 2016 at 9:18 AM, Amit Kapila wrote: > > On Fri, Feb 26, 2016 at 4:37 PM, Robert Haas wrote: > > > > > > The failure cases fall into that category, basically wholePlanParallelSafe > > will be false, but parallelModeNeeded wi

Re: [HACKERS] jsonb array-style subscription

On Thu, Mar 3, 2016 at 2:31 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: > Well, actually, I agree with that. I can try to rework the patch to achieve > this goal. Good idea. I wonder, having taken a quick look at the patch, how this works?: +select * from test_jsonb_subscript where test_jso

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

On 15 March 2016 at 04:48, Andres Freund wrote: > 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 up

Re: [HACKERS] Timeline following for logical slots

On 15 March 2016 at 07:10, Alvaro Herrera wrote: > Petr Jelinek wrote: > > On 04/03/16 17:08, Craig Ringer wrote: > > >I'd really appreciate some review of the logic there by people who know > > >timelines well and preferably know the xlogreader. It's really just one > > >function and 2/3 comment

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

On Fri, Mar 11, 2016 at 8:19 AM, Anastasia Lubennikova wrote: > But I have some concerns about compatibility with my patches. > I've tried to call bt_index_check() over my "including" patch [1] and caught > a segfault. > > LOG: server process (PID 31794) was terminated by signal 11: Segmentation

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

Petr, The attached patch is the revised one that follows the new extensible- node routine. It is almost same the previous version except for: - custom-apis.[ch] was renamed to custom-node.[ch] - check for the length of custom-scan-method name followed the manner of RegisterExtensibleNodeMethods

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On Mon, Mar 14, 2016 at 8:43 PM, Peter Geoghegan wrote: > * I think the comparison logic may have a bug. > > Does this work with amcheck? Maybe it works with bt_index_check(), but > not bt_index_parent_check()? I think that you need to make sure that > _bt_compare() knows about this, too. That's b

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On Mon, Mar 14, 2016 at 8:43 PM, Peter Geoghegan wrote: > > Does this work with amcheck? Maybe it works with bt_index_check(), but > not bt_index_parent_check()? I think that you need to make sure that > _bt_compare() knows about this, too. That's because it isn't good > enough to let a truncated

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On Wed, Sep 16, 2015 at 8:53 AM, Nicolas Barbier wrote: > After thinking about it a bit more, it indeed seems never useful to > have f3 in the internal nodes if it is not part of the columns that > determine the UNIQUE property. It could as well be pushed out of the > internal nodes and only appea

Re: [HACKERS] Identifying a message in emit_log_hook.

Thnak you for scooping up this. At Thu, 10 Mar 2016 08:14:09 -0500, David Steele wrote in <56e17321.5050...@pgmasters.net> > Hi Simon, > > On 3/10/16 7:26 AM, Simon Riggs wrote: > > > > Can you add this to the CF? It was submitted before deadline. > > I presume you have access to do that? > >

Re: [HACKERS] Choosing parallel_degree

On 15 March 2016 at 15:24, James Sewell wrote: > > I did want to test with some really slow aggs, but even when I take out the > small table test in create_parallel_paths I can't seem to get a parallel plan > for a tiny table. Any idea on why this would be David? In the test program I attached

Re: [HACKERS] propose: detail binding error log

Ioseph Kim writes: > I want see that value of bind variable at a server log. That's available if you turn on log_statements, IIRC. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.p

[HACKERS] propose: detail binding error log

Hi, hackers. I had a error message while using PostgreSQL. "ERROR: 42804: column "a" is of type boolean but expression is of type integer at character 25 LOCATION: transformAssignedExpr, parse_target.c:529" This error is a java jdbc binding error. column type is boolean but bind variable is in

Re: [HACKERS] Minor bug affecting ON CONFLICT lock wait log messages

On Mon, Mar 7, 2016 at 1:46 PM, Peter Geoghegan wrote: > Attached patch fixes a bug reported privately by Stephen this morning. Bump. I would like to see this in the next point release. It shouldn't be hard to review. Thanks -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] Choosing parallel_degree

Thanks David, Eventually it would be great to take into account the cost of the function doing the agg (pg_proc.procost, which is a multiple of CPU units). This would allow people to mark specific aggregations as needing more CPU power, therefore needing more workers per page (or should it be tup

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

On Mon, Mar 14, 2016 at 01:33:08PM +0100, Tomas Vondra wrote: > On 03/14/2016 07:14 AM, Noah Misch wrote: > >On Mon, Mar 14, 2016 at 02:00:03AM +0100, Tomas Vondra wrote: > >>+* XXX Maybe this should also care about the clock skew, just like the > >>+* block a few lines down. > > > >Yes

Re: [HACKERS] Fix for OpenSSL error queue bug

On Mon, Mar 14, 2016 at 4:11 PM, Peter Geoghegan wrote: > Yes, with one small difference: I wouldn't be calling ERR_get_error() > in the common case where SSL_get_error() returns SSL_ERROR_NONE, on > the theory that skipping that case represents no risk. I'm making a > concession to Peter E's view

[HACKERS] Choosing parallel_degree

Over in [1] James mentioned about wanting more to be able to have more influence over the partial path's parallel_degree decision. At risk of a discussion on that hijacking the parallel aggregate thread, I thought I'd start this for anyone who would want to discuss making changes to that. I've at

Re: [HACKERS] WIP: Upper planner pathification

> -Original Message- > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > Sent: Tuesday, March 15, 2016 2:04 AM > To: Petr Jelinek > Cc: Kaigai Kouhei(海外 浩平); David Rowley; Robert Haas; > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] WIP: Upper planner pathification > > Petr Jelinek

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 that (1

Re: [HACKERS] Parallel Aggregate

On 15 March 2016 at 11:24, James Sewell wrote: > On Tuesday, 15 March 2016, Robert Haas wrote: >> >> > Does the cost of the aggregate function come into this calculation at >> > all? In PostGIS land, much smaller numbers of rows can generate loads >> > that would be effective to parallelize (work

Re: [HACKERS] Parallel Aggregate

On 15 March 2016 at 11:39, Tomas Vondra wrote: > I've looked at this patch today. The patch seems quite solid, but I do have > a few minor comments (or perhaps questions, given that this is the first > time I looked at the patch). > > 1) exprCollation contains this bit: > -

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Mon, Mar 14, 2016 at 5:21 PM, Andres Freund wrote: > So? You're not the only one. I don't see why we shouldn't move this to > 'returned with feedback' until there's a new version. I don't see any point in that; I intend to get a revision in to the ongoing CF. But fine. -- Peter Geoghegan -

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

On 3/14/16, Anastasia Lubennikova wrote: > 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

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 2016-03-14 17:17:02 -0700, Peter Geoghegan wrote: > On Mon, Mar 14, 2016 at 5:04 PM, Robert Haas wrote: > > There hasn't been a new version of this patch in 9 months, you're > > clearly not in a hurry to produce one, and nobody else seems to feel > > strongly that this is something that needs t

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Mon, Mar 14, 2016 at 5:04 PM, Robert Haas wrote: > There hasn't been a new version of this patch in 9 months, you're > clearly not in a hurry to produce one, and nobody else seems to feel > strongly that this is something that needs to be done at all. I think > we could just let this go and be

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

On 3/14/16, Mark Dilger wrote: > The first thing I notice about this patch is that > src/include/datatype/timestamp.h > has some #defines that are brittle. The #defines have comments explaining > their logic, but I'd rather embed that in the #define directly: > > This: > > +#ifdef HAVE_INT64_TIME

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Sat, Mar 12, 2016 at 5:53 PM, Peter Geoghegan wrote: > On Sat, Mar 12, 2016 at 2:43 PM, Michael Paquier > wrote: >> Only one version of this patch has been sent at the beginning of this >> thread, and Heikki has clearly expressed his disagreement about at >> least a portion of it at the beginn

Re: [HACKERS] Parallel Aggregate

On 15 March 2016 at 08:53, Robert Haas wrote: > I haven't fully studied every line of this yet, but here are a few comments: > > + case T_PartialAggref: > + coll = InvalidOid; /* XXX is this correct? */ > + break; > > I doubt it. Thanks fo

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 'EXPLAIN ANALYZE SELECT * INTO T

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 each aggregate concerne

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 >> psql (9.6devel) >> Type

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 chan

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

David Steele writes: > On 3/14/16 4:10 PM, Robbie Harwood wrote: > >> David Steele writes: >> >>> On 3/8/16 5:44 PM, Robbie Harwood wrote: >>> Here's yet another version of GSSAPI encryption support. It's also available for viewing on my github: >>> >>> psql simply hangs and never ret

[HACKERS] [PATCH v7] GSSAPI encryption support

Hello friends, New week, new version. GitHub link: https://github.com/frozencemetery/postgres/tree/feature/gssencrypt7 Changes in this version: - Removed extra whitespace in auth code movement. - Fixed connection desync issue. A diff of this and v6 will reveal three issues: - First, that

Re: [HACKERS] Fix for OpenSSL error queue bug

On Mon, Mar 14, 2016 at 4:05 PM, Tom Lane wrote: > So your proposal is basically to do #2 in all branches? I won't fight it, > if it doesn't bloat the code much. The overhead should surely be trivial > compared to network communication costs, and I'm afraid you might be right > about the risk of

Re: [HACKERS] Timeline following for logical slots

Petr Jelinek wrote: > On 04/03/16 17:08, Craig Ringer wrote: > >I'd really appreciate some review of the logic there by people who know > >timelines well and preferably know the xlogreader. It's really just one > >function and 2/3 comments; the code is simple but the reasoning leading > >to it is n

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 branches, clear error queue before *and* af

Re: [HACKERS] Fix for OpenSSL error queue bug

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 branches, clear error queue before *and* after calls. This > will waste a few

Re: [HACKERS] Parallel Aggregate

Hi, On 03/13/2016 10: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 the moment, but hopefully the dust is starting to settle now. The attac

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 could set min_parallel_degree o

Re: [HACKERS] Parallel Aggregate

On Tuesday, 15 March 2016, Robert Haas wrote: > > > Does the cost of the aggregate function come into this calculation at > > all? In PostGIS land, much smaller numbers of rows can generate loads > > that would be effective to parallelize (worker time much >> than > > startup cost). > > Unfortunat

Re: [HACKERS] Fix for OpenSSL error queue bug

Peter Geoghegan writes: > 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 indication tha

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 numbers. All other stateme

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 parser has an implementatio

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 Oracle-ism, and it > > doesn't seem to have been their best-eve

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 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? Greetings, Andres Freu

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

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 will get a benefit?

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 build went fine but when

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 at all. I'm > using th

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 query. But I think that that would often >> lea

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, IO and such. Thus r

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 > relation (in pages) the more workers will be allocated, up un

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 like to see something better in >> community ver

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 the >> moment, but hopefully the dust is starting to settle now

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 #inc

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 design decision. It is, and it wasn't. What co

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 follo

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 an especially compelling

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

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' of this >> composite

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 indication that the OpenSSL > people would s

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. Bingo - though maybe

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

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 sorting is exposed to the u

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 form is too tightly tied to recei

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 would >> have noticed that this part breaks it, beca

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 documente

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 >>> wrote: So, from what I understand here, we should not put total count of index

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. > > +from the current synchronous stanbyindicates it has recei

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 is >> not required, postgres_

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 This patch no longer applies cleanly: $ git apply ../other/group_update_clog_v6.patch error: patch failed: src/backend/storage/lmgr/proc.c:404 error: src/backend/storage/lmgr/proc.c: patch does not apply err

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 suggest would create

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 query. But I think that that would often >> lea

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? pg_extens

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 > wrote: > > Let’s do immediately after you will send a new version of yo

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 rec

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. -SyncRepWaitForLSN(gxact->prepare_end_ls

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 that (1) I replaced erep

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

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 call it for FDW(s) actively involved >>> in the query. I'm not su

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 running a >> consistency check on a production sys

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 what that ought to look like though. >> Maybe

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 to 128bit), allowing

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 CustomPath >>> (and potentially ForeignScan

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, they're likely to be sloppy about it, which >>> could lead to latent

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 hstore/j

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 problems if the FDW later acquires a >> concept

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

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 thorough search of the academic

  1   2   >