Re: [HACKERS] GIN improvements part2: fast scan

On 01/28/2014 05:54 AM, Tomas Vondra wrote: Then I ran those scripts on: * 9.3 * 9.4 with Heikki's patches (9.4-heikki) * 9.4 with Heikki's and first patch (9.4-alex-1) * 9.4 with Heikki's and both patches (9.4-alex-2) It would be good to also test with unpatched 9.4 (ie. git maste

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

On 01/28/2014 08:58 AM, David Fetter wrote: On Tue, Jan 28, 2014 at 02:51:22PM +0900, Michael Paquier wrote: On Tue, Jan 28, 2014 at 2:29 PM, David Fetter wrote: On Tue, Jan 28, 2014 at 04:48:35PM +1300, Gavin Flower wrote: I came across that abbreviation in a first years Maths course "Princi

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

On 01/27/2014 11:36 PM, Murtuza Mukadam wrote: 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.co

[HACKERS] Re: [COMMITTERS] pgsql: Keep pg_stat_statements' query texts in a file, not in shared me

Then I will post my response. On Mon, Jan 27, 2014 at 8:54 PM, Peter Geoghegan wrote: > On Mon, Jan 27, 2014 at 8:20 PM, KONDO Mitsumasa > wrote: >> At least, only postgres superuser can see pg_stat_statemnet view in old >> version. >> And you should change document at this sentences. > > No, it

[HACKERS] Union-ifying RangeTblEntry

Hi all I'm about to have to add _another_ flag to RangeTblEntry, to track row-security expansion. In the process I noticed the comment: /* * XXX the fields applicable to only some rte kinds should be * merged into a union. I didn't do this yet because the diffs * would impact

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

On 27th January, Mitsumasa KONDO wrote: > > 2014-01-26 Simon Riggs > > > > > > On 21 January 2014 19:48, Simon Riggs > > wrote: > > > On 21 January 2014 12:54, KONDO Mitsumasa > >

Re: [HACKERS] Infinite recursion in row-security based on updatable s.b. views

On 01/24/2014 07:16 PM, Dean Rasheed wrote: > My first thought is to add a boolean flag to RangeTblEntry (similar to > the "inh" flag) to say whether RLS expansion is requested for that > RTE. Then set it to false on each RTE as you add new RLS quals to it's > securityQuals. That's what I was get

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

On Tue, Jan 28, 2014 at 2:29 PM, David Fetter wrote: > 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/co

Re: [HACKERS] PoC: Partial sort

On Tue, Jan 28, 2014 at 7:41 AM, Marti Raudsepp wrote: > 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

Re: [HACKERS] Why conf.d should be default, and auto.conf and recovery.conf should be in it

On Wed, Jan 22, 2014 at 8:56 PM, Tom Lane wrote: > Amit Kapila writes: >> On Tue, Jan 21, 2014 at 8:25 PM, Robert Haas wrote: >>> While reviewing, I noted that the >>> "skipping missing configuration file" message in ParseConfigFile() >>> uses an elevel of LOG, while the other messages in the sa

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

On Tue, Jan 28, 2014 at 1:41 PM, Amit Kapila wrote: > 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >