Re: [HACKERS] inherit support for foreign tables

Hi Hanada-san, While still reviwing this patch, I feel this patch has given enough consideration to interactions with other commands, but found the following incorrect? behabior: postgres=# CREATE TABLE product (id INTEGER, description TEXT); CREATE TABLE postgres=# CREATE FOREIGN TABLE produ

Re: [HACKERS] A better way than tweaking NTUP_PER_BUCKET

On 25 January 2014 23:08, Simon Riggs wrote: > On 25 January 2014 22:33, Stephen Frost wrote: > >> * Tom Lane (t...@sss.pgh.pa.us) wrote: > >>> AFAICT, there was no consensus in this thread on what to do, which >>> probably has something to do with the lack of concrete performance >>> tests prese

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

Hackers, Is somebody available to volunteer to review the custom-scan patch? Even though Hanada-san acknowledged before, it seems to me this patch has potentially arguable implementations. Even if you have enough time to review whole of the code, it helps me if you can comment on the following to

Re: [HACKERS] GIN improvements part2: fast scan

On Sun, Jan 26, 2014 at 8:14 PM, Heikki Linnakangas wrote: > On 01/26/2014 08:24 AM, Tomas Vondra wrote: > >> Hi! >> >> On 25.1.2014 22:21, Heikki Linnakangas wrote: >> >>> Attached is a new version of the patch set, with those bugs fixed. >>> >> >> I've done a bunch of tests with all the 4 patch

Re: [HACKERS] plpgsql.warn_shadow

On Sun, Jan 26, 2014 at 11:19 AM, Simon Riggs wrote: > For 9.4, we should cut down the patch so it has > plpgsql.warnings = none (default) | all | [individual item list] > plpgsql.warnings_as_errors = off (default) | on I hope I'm not late for the bikeshedding :) Why not have 2 similar opti

Re: [HACKERS] plpgsql.warn_shadow

2014-01-27 Marti Raudsepp > On Sun, Jan 26, 2014 at 11:19 AM, Simon Riggs > wrote: > > For 9.4, we should cut down the patch so it has > > plpgsql.warnings = none (default) | all | [individual item list] > > > plpgsql.warnings_as_errors = off (default) | on > > I hope I'm not late for the bi

Re: [HACKERS] plpgsql.warn_shadow

On 27 January 2014 10:40, Marti Raudsepp wrote: > On Sun, Jan 26, 2014 at 11:19 AM, Simon Riggs wrote: >> For 9.4, we should cut down the patch so it has >> plpgsql.warnings = none (default) | all | [individual item list] > >> plpgsql.warnings_as_errors = off (default) | on > > I hope I'm not

Re: [HACKERS] Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

On 23/01/14, Christian Kruse wrote: > > Well, is it context or detail? Those fields have reasonably well > > defined meanings IMO. > > I find the distinction somewhat blurry and think both would be > appropriate. But since I wasn't sure I changed to detail. > > > If we need errcontext_plural, le

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

(2014/01/23 23:18), Andrew Dunstan wrote: What is more, if the square root calculation is affecting your benchmarks, I suspect you are benchmarking the wrong thing. I run another test that has two pgbench-clients in same time, one is select-only-query and another is executing 'SELECT *　pg_stat_s

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

(2014/01/26 17:43), Mitsumasa KONDO wrote: > 2014-01-26 Simon Riggs mailto:si...@2ndquadrant.com>> > > On 21 January 2014 19:48, Simon Riggs > wrote: > > On 21 January 2014 12:54, KONDO Mitsumasa > > wrote: >

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 01/27/2014 07:09 AM, KONDO Mitsumasa wrote: (2014/01/23 23:18), Andrew Dunstan wrote: What is more, if the square root calculation is affecting your benchmarks, I suspect you are benchmarking the wrong thing. I run another test that has two pgbench-clients in same time, one is select-only-

Re: [HACKERS] [Review] inherit support for foreign tables

2014-01-27 Etsuro Fujita : > (2014/01/25 11:27), Shigeru Hanada wrote: > Yeah, the consistency is essential for its ease of use. But I'm not sure > that inherited stats ignoring foreign tables is actually useful for query > optimization. What I think about the consistency is a) the ANALYZE comman

Re: [HACKERS] Changeset Extraction v7.1

On Sat, Jan 25, 2014 at 5:25 PM, Andres Freund wrote: >> Looking over patch 0002, I see that there's code to allow a walsender >> to create or drop a physical replication slot. Also, if we've >> acquired a replication slot, there's code to update it, and code to >> make sure we disconnect from it

Re: [HACKERS] inherit support for foreign tables

2014-01-27 Etsuro Fujita : > While still reviwing this patch, I feel this patch has given enough > consideration to interactions with other commands, but found the following > incorrect? behabior: > > postgres=# CREATE TABLE product (id INTEGER, description TEXT); > CREATE TABLE > postgres=# CREATE

Re: [HACKERS] Changeset Extraction v7.1

On Sat, Jan 25, 2014 at 5:25 PM, Andres Freund wrote: >> I'm also wondering about >> whether we've got the right naming here. AFAICT, it's not the case >> that we're going to use the "catalog xmin" for catalogs and the "data >> xmin" for non-catalogs. Rather, the "catalog xmin" is going to alway

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

2014-01-27 Andrew Dunstan > > On 01/27/2014 07:09 AM, KONDO Mitsumasa wrote: > >> (2014/01/23 23:18), Andrew Dunstan wrote: >> >>> What is more, if the square root calculation is affecting your >>> benchmarks, I >>> suspect you are benchmarking the wrong thing. >>> >> I run another test that has

Re: [HACKERS] What is happening on buildfarm member crake?

On Sat, Jan 25, 2014 at 5:04 PM, Tom Lane wrote: > Yeah. If Robert's diagnosis is correct, and it sounds pretty plausible, > then this is really just one instance of a bug that's probably pretty > widespread in our signal handlers. Somebody needs to go through 'em > all and look for touches of s

Re: [HACKERS] inherit support for foreign tables

Sent from my iPad > On 27-Jan-2014, at 21:03, David Fetter wrote: > >> On Mon, Jan 27, 2014 at 05:06:19PM +0900, Etsuro Fujita wrote: >> Hi Hanada-san, >> >> While still reviwing this patch, I feel this patch has given enough >> consideration to interactions with other commands, but found the

Re: [HACKERS] Retain dynamic shared memory segments for postmaster lifetime

On Mon, Jan 27, 2014 at 11:18 PM, Amit Langote wrote: > On Mon, Jan 13, 2014 at 2:50 PM, Amit Kapila wrote: >> I have extended test (contrib) module dsm_demo such that now user >> can specify during dsm_demo_create the lifespan of segment. >> The values it can accept are 0 or 1. Default value is

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

Amit Kapila writes: > On Fri, Jan 24, 2014 at 9:10 AM, Amit Kapila wrote: >> On Fri, Jan 24, 2014 at 2:38 AM, Robert Haas wrote: >>> I mean, if >>> there's a GUC that controls the event source name, then it can be >>> changed between restarts, regardless of what you call it. >> Yes, but not def

Re: [HACKERS] Race condition in b-tree page deletion

On 12/17/2013 04:55 AM, Jim Nasby wrote: On 11/9/13, 10:02 AM, Heikki Linnakangas wrote: 3. Another approach would be to get rid of the "can't delete rightmost child" limitation. We currently have that limitation because it ensures that we never need to change the high-key of a page. If we delet

Re: [HACKERS] Standalone synchronous master

On Sun, Jan 26, 2014 at 10:56 PM, Rajeev rastogi wrote: > On 01/25/2014, Josh Berkus wrote: >> > ISTM the consensus is that we need better monitoring/administration >> > interfaces so that people can script the behavior they want in >> > external tools. Also, a new synchronous apply replication mo

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

Simon Riggs writes: > Am I right in thinking that we have this fully working now? I will look at this at some point during the CF, but have not yet, and probably won't as long as it's not marked "ready for committer". regards, tom lane -- Sent via pgsql-hackers mailing

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

On 27 January 2014 15:04, Dean Rasheed wrote: > So for example, when planning the query to update an inheritance > child, the rtable will contain an RTE for the parent, but it will not > be referenced in the parse tree, and so it will not be expanded while > planning the child update. Am I right

Re: [HACKERS] dynamic shared memory and locks

On Thu, Jan 23, 2014 at 11:10 AM, Robert Haas wrote: > On Wed, Jan 22, 2014 at 12:42 PM, Andres Freund > wrote: >> On 2014-01-22 12:40:34 -0500, Robert Haas wrote: >>> On Wed, Jan 22, 2014 at 12:11 PM, Tom Lane wrote: >>> > Andres Freund writes: >>> >> Shouldn't we introduce a typedef LWLock*

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

KaiGai Kohei, * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote: > Is somebody available to volunteer to review the custom-scan patch? I looked through it a bit and my first take away from it was that the patches to actually use the new hooks were also making more changes to the backend code, leaving

Re: [HACKERS] Retain dynamic shared memory segments for postmaster lifetime

On Mon, Jan 13, 2014 at 2:50 PM, Amit Kapila wrote: > I have extended test (contrib) module dsm_demo such that now user > can specify during dsm_demo_create the lifespan of segment. > The values it can accept are 0 or 1. Default value is 0. > 0 -- means segment will be accessible for session life

Re: [HACKERS] shouldn't we log permission errors when accessing the configured trigger file?

On Mon, Jan 27, 2014 at 3:43 PM, Robert Haas wrote: > On Sun, Jan 26, 2014 at 1:03 PM, Andres Freund > wrote: > > For some reason CheckForStandbyTrigger() doesn't report permission > > errors when stat()int the trigger file. Shouldn't we fix that? > > > > static bool > > CheckForStandbyTrigger(v

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 01/27/2014 08:48 AM, Mitsumasa KONDO wrote: > > > The issue of concern is not the performance of pg_stat_statements, > AUIU. The issue is whether this patch affects performance > generally, i.e. is there a significant cost in collecting these > extra stats. To test this you woul

Re: [HACKERS] shouldn't we log permission errors when accessing the configured trigger file?

On Sun, Jan 26, 2014 at 1:03 PM, Andres Freund wrote: > For some reason CheckForStandbyTrigger() doesn't report permission > errors when stat()int the trigger file. Shouldn't we fix that? > > static bool > CheckForStandbyTrigger(void) > { > ... > if (stat(TriggerFile, &stat_buf) == 0) >

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

On 27 January 2014 07:54, Kouhei Kaigai wrote: > Hello, > > I checked the latest updatable security barrier view patch. > Even though I couldn't find a major design problem in this revision, > here are two minor comments below. > > I think, it needs to be reviewed by committer to stick direction >

Re: [HACKERS] inherit support for foreign tables

On Mon, Jan 27, 2014 at 05:06:19PM +0900, Etsuro Fujita wrote: > Hi Hanada-san, > > While still reviwing this patch, I feel this patch has given enough > consideration to interactions with other commands, but found the > following incorrect? behabior: > > postgres=# CREATE TABLE product (id INTEG

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Fri, Jan 24, 2014 at 9:10 AM, Amit Kapila wrote: > On Fri, Jan 24, 2014 at 2:38 AM, Robert Haas wrote: >> On Thu, Jan 23, 2014 at 9:23 AM, Amit Kapila wrote: >>> On Thu, Jan 23, 2014 at 10:26 AM, Tom Lane wrote: I think what we might want to do is redefine the server's behavior >>>

Re: [HACKERS] GIN improvements part2: fast scan

On Sun, Jan 26, 2014 at 8:14 PM, Heikki Linnakangas wrote: > In addition to that, I'm using the ternary consistent function to check >> if minItem is a match, even if we haven't loaded all the entries yet. >> That's less important, but I think for something like "rare1 | (rare2 & >> frequent)" it

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

On 27 January 2014 16:11, Tom Lane wrote: > Simon Riggs writes: >> Am I right in thinking that we have this fully working now? > > I will look at this at some point during the CF, but have not yet, > and probably won't as long as it's not marked "ready for committer". I've marked it Ready for Co

[HACKERS] Fwd: Request for error explaination || Adding a new integer in indextupleData Structure

Hi All, I was trying to modify indextupledata structure by adding an integer variable. ButI faced an error message "psql: FATAL: could not find tuple for opclass 10032". Could anyone please help me in resolving this issue. Regards, Rohit Goyal -- Regards, Rohit Goyal

Re: [HACKERS] A better way than tweaking NTUP_PER_BUCKET

* Simon Riggs (si...@2ndquadrant.com) wrote: > I don't see anything for 9.4 in here now. Attached is what I was toying with (thought I had attached it previously somewhere.. perhaps not), but in re-testing, it doesn't appear to do enough to move things in the right direction in all cases. I did

Re: [HACKERS] A better way than tweaking NTUP_PER_BUCKET

* Stephen Frost (sfr...@snowman.net) wrote: > * Simon Riggs (si...@2ndquadrant.com) wrote: > > I don't see anything for 9.4 in here now. > > Attached [...] I'm apparently bad at this 'attaching' thing, particularly on this subject. Here it is. Thanks, Stephen colordiff

Re: [HACKERS] Fwd: Request for error explaination || Adding a new integer in indextupleData Structure

Rohit Goyal writes: > Hi All, > I was trying to modify indextupledata structure by adding an integer > variable. ButI faced an error message "psql: FATAL: could not find tuple > for opclass 10032". > Could anyone please help me in resolving this issue. You broke a system catalog index. Without

Re: [HACKERS] [bug fix] "pg_ctl stop" times out when it should respond quickly

Le mardi 7 janvier 2014 17:05:03 Michael Paquier a écrit : > On Sun, Jan 5, 2014 at 3:49 PM, MauMau wrote: > > Could you confirm again and tell me what problem is happening? > > FWIW, I just quickly tested those two patches independently and got > them correctly applied with patch -p1 < $PATCH on

Re: [HACKERS] A better way than tweaking NTUP_PER_BUCKET

2014-01-27 Stephen Frost > * Simon Riggs (si...@2ndquadrant.com) wrote: > > I don't see anything for 9.4 in here now. > > Attached is what I was toying with (thought I had attached it previously > somewhere.. perhaps not), but in re-testing, it doesn't appear to do > enough to move things in the

Re: [HACKERS] new json funcs

On Fri, Jan 24, 2014 at 3:26 PM, Josh Berkus wrote: > On 01/24/2014 12:59 PM, Andrew Dunstan wrote: >> >> On 01/24/2014 03:40 PM, Laurence Rowe wrote: >>> For consistency with the existing json functions (json_each, >>> json_each_text, etc.) it might be better to add separate >>> json_to_record_te

Re: [HACKERS] Add %z support to elog/ereport?

I wrote: >> the idea that we might get many dozen such warnings on more-current >> compilers is scarier, as that might well interfere with people's >> ability to do development on, say, Windows. Could somebody check >> whether MSVC for instance complains about format strings using "z"? >> Or shall

Re: [HACKERS] new json funcs

On 01/27/2014 12:43 PM, Merlin Moncure wrote: On Fri, Jan 24, 2014 at 3:26 PM, Josh Berkus wrote: On 01/24/2014 12:59 PM, Andrew Dunstan wrote: On 01/24/2014 03:40 PM, Laurence Rowe wrote: For consistency with the existing json functions (json_each, json_each_text, etc.) it might be better t

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

On 24 January 2014 08:33, Simon Riggs wrote: > On 24 January 2014 07:08, Peter Geoghegan wrote: >> On Wed, Jan 15, 2014 at 6:57 AM, Simon Riggs wrote: >>> v15 to fix the above problem. >> > v16 attached v17 attached This version adds a GUC called ddl_exclusive_locks which allows us to keep the

Re: [HACKERS] Planning time in explain/explain analyze

On 01/13/2014 09:48 PM, Robert Haas wrote: What I'm saying is that if EXPLAIN reports something that's labelled "Planning Time", it should *be* the planning time, and not anything else. When we retrieve a plan from cache, it would be sensible not to report the planning time at all, and IMHO it w

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

On 27 January 2014 17:58, Simon Riggs wrote: > On 24 January 2014 08:33, Simon Riggs wrote: >> On 24 January 2014 07:08, Peter Geoghegan wrote: >>> On Wed, Jan 15, 2014 at 6:57 AM, Simon Riggs wrote: v15 to fix the above problem. >>> >> v16 attached > > v17 attached Frostbite... -- Sim

Re: [HACKERS] A better way than tweaking NTUP_PER_BUCKET

On 27 January 2014 17:44, Pavel Stehule wrote: > This topic is interesting - we found very bad performance with hashing large > tables with high work_mem. MergeJoin with quicksort was significantly > faster. I've seen this also. > I didn't deeper research - there is a possibility of virtualizat

Re: [HACKERS] Failure while inserting parent tuple to B-tree is not fun

On 01/23/2014 11:36 PM, Peter Geoghegan wrote: The first thing I noticed about this patchset is that it completely expunges btree_xlog_startup(), btree_xlog_cleanup() and btree_safe_restartpoint(). The post-recovery cleanup that previously occurred to address both sets of problems (the problem ad

Re: [HACKERS] alternative back-end block formats

Hi Craig, On Sun, Jan 26, 2014 at 5:47 AM, Craig Ringer wrote: > On 01/21/2014 07:43 PM, Christian Convey wrote: > > Hi all, > > > > I'm playing around with Postgres, and I thought it might be fun to > > experiment with alternative formats for relation blocks, to see if I can > > get smaller fil

Re: [HACKERS] [PATCH] Support for pg_stat_archiver view

On Sat, Jan 25, 2014 at 3:19 PM, Michael Paquier wrote: > On Sat, Jan 25, 2014 at 5:41 AM, Fujii Masao wrote: >> On Thu, Jan 23, 2014 at 4:10 PM, Michael Paquier >> wrote: >>> On Thu, Jan 9, 2014 at 6:36 AM, Gabriele Bartolini >>> wrote: Il 08/01/14 18:42, Simon Riggs ha scritto: > Not

Re: [HACKERS] Standalone synchronous master

On 01/26/2014 07:56 PM, Rajeev rastogi wrote: > I shall rework to improve this patch. Below are the summarization of all > discussions, which will be used as input for improving the patch: > > 1. Method of degrading the synchronous mode: > a. Expose the configuration variable to a new SQL-ca

Re: [HACKERS] Failure while inserting parent tuple to B-tree is not fun

On Mon, Jan 27, 2014 at 10:27 AM, Heikki Linnakangas wrote: >> I think I see some bugs in _bt_moveright(). If you examine >> _bt_finish_split() in detail, you'll see that it doesn't just drop the >> write buffer lock that the caller will have provided (per its >> comments) - it also drops the buff

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

Heikki Linnakangas wrote: > I spent some time whacking this around, new patch version attached. > I moved the mmap() code into a new function, that leaves the > PGSharedMemoryCreate more readable. Did this patch go anywhere? Someone just pinged me about a kernel scalability problem in Linux with

Re: [HACKERS] PoC: Partial sort

Hi! On Tue, Jan 21, 2014 at 3:24 AM, Marti Raudsepp wrote: > On Tue, Jan 14, 2014 at 5:49 PM, Alexander Korotkov > wrote: > >On Tue, Jan 14, 2014 at 12:54 AM, Marti Raudsepp wrote: > >> I've been trying it out in a few situations. I implemented a new > >> enable_partialsort GUC to make it easi

Re: [HACKERS] Failure while inserting parent tuple to B-tree is not fun

On Mon, Jan 27, 2014 at 10:58 AM, Heikki Linnakangas wrote: > Okay, promise not to laugh. I did write a bunch of hacks, to generate > graphviz .dot files from the btree pages, and render them into pictures. It > consist of multiple parts, all in the attached tarball. It's funny that you should sa

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

On Mon, Jan 27, 2014 at 12:58 PM, Simon Riggs wrote: > On 24 January 2014 08:33, Simon Riggs wrote: >> On 24 January 2014 07:08, Peter Geoghegan wrote: >>> On Wed, Jan 15, 2014 at 6:57 AM, Simon Riggs wrote: v15 to fix the above problem. >>> >> v16 attached > > v17 attached > > This versio

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

On Mon, Jan 27, 2014 at 12:25 PM, Robert Haas wrote: > I haven't reviewed the patch, but -1 for adding a GUC. I'm pretty surprised that it's been suggested that some people might prefer AccessExclusiveLocks. Why would anyone prefer that? -- Peter Geoghegan -- Sent via pgsql-hackers mailing

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

Peter Geoghegan writes: > On Sun, Jan 26, 2014 at 10:38 AM, Tom Lane wrote: >> Meh. This line of argument seems to reduce to "we don't need to worry >> about performance of this code path because it won't be reached often". > I think I may have over-elaborated, giving you the false impression >

Re: [HACKERS] extension_control_path

Hi, Sergey Muraviov writes: > Now patch applies cleanly and works. :-) Cool ;-) > But I have some notes: > > 1. There is an odd underscore character in functions > find_in_extension_control_path and list_extension_control_paths: > \"extension_control__path\"" Fixed in the new version of the pa

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

On Mon, Jan 27, 2014 at 12:39 PM, Tom Lane wrote: > OK. Committed after a couple of small further revisions. Great. Thank you. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/p

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

Peter Geoghegan writes: > On Mon, Jan 27, 2014 at 12:25 PM, Robert Haas wrote: >> I haven't reviewed the patch, but -1 for adding a GUC. > I'm pretty surprised that it's been suggested that some people might > prefer AccessExclusiveLocks. Why would anyone prefer that? For one thing, so they can

Re: [HACKERS] new json funcs

Andrew Dunstan escribió: > Note that we can only do this when the result type stays the same. > It does not for json_each/json_each_text or > json_extract_path/json_extract_path_text, which is why we have > different functions for those cases. In C code, if I extract a value using json_object_fie

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

On 27 January 2014 20:35, Peter Geoghegan wrote: > On Mon, Jan 27, 2014 at 12:25 PM, Robert Haas wrote: >> I haven't reviewed the patch, but -1 for adding a GUC. > > I'm pretty surprised that it's been suggested that some people might > prefer AccessExclusiveLocks. Why would anyone prefer that?

Re: [HACKERS] new json funcs

On 01/27/2014 03:53 PM, Alvaro Herrera wrote: Andrew Dunstan escribió: Note that we can only do this when the result type stays the same. It does not for json_each/json_each_text or json_extract_path/json_extract_path_text, which is why we have different functions for those cases. In C code,

Re: [HACKERS] new json funcs

Andrew Dunstan escribió: > I'm not sure I understand the need. This is the difference between > the _text variants and their parents. Why would you call > json_object_field when you want the dequoted text? Because I first need to know its type. Sometimes it's an array, or an object, or a boolean

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

On 27 January 2014 20:47, Tom Lane wrote: > Peter Geoghegan writes: >> On Mon, Jan 27, 2014 at 12:25 PM, Robert Haas wrote: >>> I haven't reviewed the patch, but -1 for adding a GUC. > >> I'm pretty surprised that it's been suggested that some people might >> prefer AccessExclusiveLocks. Why wou

Re: [HACKERS] Freezing without write I/O

On 26 January 2014 12:58, Andres Freund wrote: > On 2014-01-25 20:26:16 -0800, Peter Geoghegan wrote: >> Shouldn't this patch be in the January commitfest? > > I think we previously concluded that there wasn't much chance to get > this into 9.4 and there's significant work to be done on the patch

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On Mon, Jan 27, 2014 at 4:45 AM, Andrew Dunstan wrote: > I personally don't give a tinker's cuss about whether the patch slows down > pg_stat_statements a bit. Why not? The assurance that the overhead is generally very low is what makes it possible to install it widely usually without a second th

Re: [HACKERS] INTERVAL overflow detection is terribly broken

On Sun, Jan 26, 2014 at 02:13:03PM +0100, Florian Pflug wrote: > On Jan26, 2014, at 03:50 , Bruce Momjian wrote: > > Patch attached. > > > + if ((float)tm->tm_year * MONTHS_PER_YEAR + tm->tm_mon > INT_MAX) > > + return -1; > > Is this bullet-proof? If float and int are both 32-bit, t

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 01/27/2014 04:37 PM, Peter Geoghegan wrote: On Mon, Jan 27, 2014 at 4:45 AM, Andrew Dunstan wrote: I personally don't give a tinker's cuss about whether the patch slows down pg_stat_statements a bit. Why not? The assurance that the overhead is generally very low is what makes it possible t

Re: [HACKERS] INTERVAL overflow detection is terribly broken

On Mon, Jan 27, 2014 at 04:47:22PM -0500, Bruce Momjian wrote: > The updated attached patch has overflow detection for interval > subtraction, multiply, and negate. There are also some comparison > cleanups. Oh, one odd thing about this patch. I found I needed to use INT64_MAX, but I don't see i

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On 25 January 2014 02:21, Florian Pflug wrote: > I've now split this up into > > invtrans_base: Basic machinery plus tests with SQL-language aggregates > invtrans_arith: COUNT(),SUM(),AVG(),STDDEV() and the like > invtrans_minmax: MIN(),MAX(),BOOL_AND(),BOOL_OR() > invtrans_collecting: ARRAY_AGG()

Re: [HACKERS] A minor correction in comment in heaptuple.c

Bruce Momjian wrote: > On Tue, Jun 18, 2013 at 11:04:25AM -0700, Kevin Grittner wrote: >> D'Arcy J.M. Cain >> >>> Although, the more I think about it, the more I think that the >>> comment is both confusing and superfluous.  The code itself is >>> much clearer. >> >> Seriously, if there is any co

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On Mon, Jan 27, 2014 at 2:01 PM, Andrew Dunstan wrote: > I care very much what the module does to the performance of all statements. > But I don't care much if selecting from pg_stat_statements itself is a bit > slowed. Perhaps I didn't express myself as clearly as I could have. Oh, I see. Of cou

Re: [HACKERS] INTERVAL overflow detection is terribly broken

Bruce Momjian writes: > Oh, one odd thing about this patch. I found I needed to use INT64_MAX, > but I don't see it used anywhere else in our codebase. Is this OK? Is > there a better way? Most of the overflow tests in int.c and int8.c are coded to avoid relying on the MIN or MAX constants; wh

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

Hi Stephen, Thanks for your comments. > * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote: > > Is somebody available to volunteer to review the custom-scan patch? > > I looked through it a bit and my first take away from it was that the patches > to actually use the new hooks were also making more ch

Re: [HACKERS] Race condition in b-tree page deletion

On Sat, Jan 18, 2014 at 11:45 AM, Kevin Grittner wrote: > Heikki Linnakangas wrote: > >> Here's a patch implementing this scheme. I thought I'd weigh in here too, since this is closely tied to the page split patch, which is dependent on this patch. > The basic approach is sound. The papers on

[HACKERS] git-review: linking commits to review discussion in git

Hello All, We have linked peer review discussions on 'pgsql-hackers' to their respective commits within the main postgresql.git repository. You can view the linked reviews from 2012 until present in the GitHub repo at https://github.com/mmukadam/postgres/tree/review If you want to wo

Re: [HACKERS] New option for pg_basebackup, to specify a different directory for pg_xlog

On 11/30/13, 6:59 AM, Haribabu kommi wrote: > To detect provided data and xlog directories are same or not, I reused the > Existing make_absolute_path() code as follows. I note that initdb does not detect whether the data and xlog directories are the same. I think there is no point in addressing

Re: [HACKERS] Freezing without write I/O

On Mon, Jan 27, 2014 at 4:16 PM, Simon Riggs wrote: > On 26 January 2014 12:58, Andres Freund wrote: >> On 2014-01-25 20:26:16 -0800, Peter Geoghegan wrote: >>> Shouldn't this patch be in the January commitfest? >> >> I think we previously concluded that there wasn't much chance to get >> this in

Re: [HACKERS] Add force option to dropdb

On 2014年1月17日 0:56, salah jubeh wrote: > >>If the user owns objects, that will prevent this from working also. I >>have the feeling that adding DROP OWNED BY and/or REASSIGNED OWNED BY >>calls to this utility would be a bit excessive, but who knows. > > Please find attached the first attempt to d

[HACKERS] Fix comment typo in /src/backend/command/cluster.c

Hi all, Attached patch fixes the typo which is in "src/backend/command/cluster.c". Regards, --- Sawada Masahiko fix_typo-cluster.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresq

Re: [HACKERS] Fix comment typo in /src/backend/command/cluster.c

On 01/27/2014 10:24 PM, Sawada Masahiko wrote: Hi all, Attached patch fixes the typo which is in "src/backend/command/cluster.c". Are you sure that's a typo? "iff" is usually short hand for "if and only if". cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

On 01/28/2014 12:09 AM, Simon Riggs wrote: > On 27 January 2014 15:04, Dean Rasheed wrote: > >> So for example, when planning the query to update an inheritance >> child, the rtable will contain an RTE for the parent, but it will not >> be referenced in the parse tree, and so it will not be expan

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Mon, Jan 27, 2014 at 9:01 PM, Tom Lane wrote: > Amit Kapila writes: >> On Fri, Jan 24, 2014 at 9:10 AM, Amit Kapila wrote: > >> To proceed with the review of this patch, I need to know about >> whether appending version number or any other constant togli > >> Default Event Source name is acce

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Mon, Jan 27, 2014 at 12:03 PM, Amit Kapila wrote: >> I think that's a good thing to try. Can you code it up? > > I have tried to improve algorithm in another way so that we can get > benefit of same chunks during find match (something similar to lz). > The main change is to consider chunks at

Re: [HACKERS] PoC: Partial sort

On Mon, Jan 27, 2014 at 9:26 PM, Alexander Korotkov wrote: > For now, I have attempt to fix extra columns in mergejoin problem. It would > be nice if you test it. Yes, it solves the test cases I was trying with, thanks. > 1) With enable_partialsort = off all mergejoin logic should behave as > wi

Re: [HACKERS] Fix comment typo in /src/backend/command/cluster.c

On 28/01/14 16:33, Andrew Dunstan wrote: On 01/27/2014 10:24 PM, Sawada Masahiko wrote: Hi all, Attached patch fixes the typo which is in "src/backend/command/cluster.c". Are you sure that's a typo? "iff" is usually short hand for "if and only if". cheers andrew Certainly, that is

Re: [HACKERS] INTERVAL overflow detection is terribly broken

On Mon, Jan 27, 2014 at 07:19:21PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > Oh, one odd thing about this patch. I found I needed to use INT64_MAX, > > but I don't see it used anywhere else in our codebase. Is this OK? Is > > there a better way? > > Most of the overflow tests in int.c

Re: [HACKERS] Fix comment typo in /src/backend/command/cluster.c

> > On 01/27/2014 10:24 PM, Sawada Masahiko wrote: > >> Hi all, >> >> Attached patch fixes the typo which is in "src/backend/command/cluster. >> c". >> >> > > Are you sure that's a typo? "iff" is usually short hand for "if and only > if". > > Oops, I made mistake. Thanks! Regards, - Masahiko

[HACKERS] pg_basebackup and pg_stat_tmp directory

Hi, The files in pg_stat_tmp directory don't need to be backed up because they are basically reset at the archive recovery. So I think it's worth changing pg_basebackup so that it skips any files in pg_stat_tmp directory. Thought? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing lis

Re: [HACKERS] inherit support for foreign tables

(2014/01/28 0:55), Atri Sharma wrote: On 27-Jan-2014, at 21:03, David Fetter wrote: On Mon, Jan 27, 2014 at 05:06:19PM +0900, Etsuro Fujita wrote: Hi Hanada-san, While still reviwing this patch, I feel this patch has given enough consideration to interactions with other commands, but found the

Re: [HACKERS] pg_basebackup and pg_stat_tmp directory

On Tue, Jan 28, 2014 at 12:56 PM, Fujii Masao wrote: > Hi, > > The files in pg_stat_tmp directory don't need to be backed up because they are > basically reset at the archive recovery. So I think it's worth > changing pg_basebackup > so that it skips any files in pg_stat_tmp directory. Thought? Sk

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

> > AFAICS the only area of objection is the handling of inherited > > relations, which occurs within the planner in the current patch. I can > > see that would be a cause for concern since the planner is pluggable > > and it would then be possible to bypass security checks. Obviously > > installin

Re: [HACKERS] inherit support for foreign tables

> > I wonder what shall be the cases when foreign table is on a server which > does not support *all* SQL features. > > > > Does a FDW need to have the possible inherit options mentioned in its > documentation for this patch? > > The answer is no, in my understanding. The altering operation simpl

Re: [HACKERS] Retain dynamic shared memory segments for postmaster lifetime

On Mon, Jan 27, 2014 at 7:48 PM, Amit Langote wrote: > On Mon, Jan 13, 2014 at 2:50 PM, Amit Kapila wrote: >> I have extended test (contrib) module dsm_demo such that now user >> can specify during dsm_demo_create the lifespan of segment. > > Applied dsm_keep_segment_v1.patch and dsm_demo_v1.patc

Re: [HACKERS] pg_basebackup and pg_stat_tmp directory

On Tue, Jan 28, 2014 at 1:08 PM, Michael Paquier wrote: > On Tue, Jan 28, 2014 at 12:56 PM, Fujii Masao wrote: >> Hi, >> >> The files in pg_stat_tmp directory don't need to be backed up because they >> are >> basically reset at the archive recovery. So I think it's worth >> changing pg_basebacku

Re: [HACKERS] pg_basebackup and pg_stat_tmp directory

On Tue, Jan 28, 2014 at 9:26 AM, Fujii Masao wrote: > Hi, > > The files in pg_stat_tmp directory don't need to be backed up because they are > basically reset at the archive recovery. So I think it's worth > changing pg_basebackup > so that it skips any files in pg_stat_tmp directory. Thought? I

Re: [HACKERS] Fix comment typo in /src/backend/command/cluster.c

On Tue, Jan 28, 2014 at 04:48:35PM +1300, Gavin Flower wrote: > On 28/01/14 16:33, Andrew Dunstan wrote: > >On 01/27/2014 10:24 PM, Sawada Masahiko wrote: > >>Hi all, > >> > >>Attached patch fixes the typo which is in > >>"src/backend/command/cluster.c". > > > >Are you sure that's a typo? "iff" is

  1   2   >