Re: [HACKERS] pg_stat_statements: calls under-estimation propagation

> >You have added this email to the commit fest, but it contains no patch. > >Please add the email with the actual patch. > I hope its attached now! > Maybe the author should be > >given a chance to update the patches, though, because they are quite > >old. > I did connect with Daniel and he di

[HACKERS] Questions about checksum feature in 9.3

I am getting a new server ready for production and saw the release note on the new checksum feature. I thought it sounded like something we might want, and then after reading realized we have to initdb with the feature on. I figured I'd better check into it a little more since changing later mig

Re: [HACKERS] git apply vs patch -p1

On Sat, 2013-09-14 at 11:37 -0700, Josh Berkus wrote: > Lately I've been running into a lot of reports of false conflicts > reported by "git apply". The most recent one was the "points" patch, > which git apply rejected for completely ficticious reasons (it claimed > that the patch was trying to c

Re: [HACKERS] Assertions in PL/PgSQL

2013/9/15 Marko Tiikkaja > On 2013-09-15 00:09, Pavel Stehule wrote: > >> this is a possibility for introduction a new hook and possibility >> implement >> asserions and similar task in generic form (as extension). it can be >> assertions, tracing, profiling. >> > > You can already do tracing and

Re: [HACKERS] [PATCH] Revive line type

Here is a new patch for the line type, with a new input/output format {A,B,C}, as discussed in this thread. >From 837fcf5d9b1ee8e589ef4b19f7d6e575229ca758 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Sun, 15 Sep 2013 00:02:06 -0400 Subject: [PATCH] Revive line type Change the input/out

[HACKERS] Proposal: json_populate_record and nested json objects

Hi all; Currently json_populate_record and json_populate_recordset cannot work with nested json objects. This creates two fundamental problems when trying to use JSON as an interface format. The first problem is you can't easily embed a json data type in an json object and have it populate a rec

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

On Sat, 2013-09-14 at 16:18 +0900, Satoshi Nagayasu wrote: > I'm looking forward to seeing more feedback on this approach, > in terms of design and performance improvement. > So, I have submitted this for the next CF. Your patch fails to build: pgstattuple.c: In function ‘pgstat_heap_sample’: pg

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Sat, 2013-09-14 at 04:58 +0200, Marko Tiikkaja wrote: > The attached patch (based on Pavel's patch) changes the default to be > slightly more verbose (the CONTEXT lines which were previously > omitted > will be visible), but adds a new PGVerbosity called COMPACT which > suppresses CONTEXT in

Re: [HACKERS] patch: add MAP_HUGETLB to mmap() where supported (WIP)

On Sat, 2013-09-14 at 00:41 +0100, Richard Poole wrote: > The attached patch adds the MAP_HUGETLB flag to mmap() for shared > memory on systems that support it. Please fix the tabs in the SGML files. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to you

Re: [HACKERS] plpgsql.print_strict_params

On Fri, 2013-09-13 at 23:56 +0200, Marko Tiikkaja wrote: > Attached is a patch for optionally printing more information on STRICT > failures in PL/PgSQL: Please fix the tabs in the SGML files. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subsc

Re: [HACKERS] GUC for data checksums

--On 15. September 2013 00:25:34 +0200 Andres Freund wrote: Looks like a good idea to me. The implementation looks sane as well, except that I am not sure if we really need to introduce that faux variable. If the variable cannot be set and we have a SHOW hook, do we need it? It's along th

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Sat, Sep 14, 2013 at 3:15 PM, Andres Freund wrote: >> Well, the reality is that the promises idea hasn't been described in >> remotely enough detail to compare it to what I have here. I've pointed >> out plenty of problems with it. > > Even if you disagree, I still think that doesn't matter in

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Sat, Sep 14, 2013 at 12:22 AM, Robert Haas wrote: >> I mean, if we do the promise tuple >> thing, and there are multiple unique indexes, what happens when an >> inserter needs to block pending the outcome of another transaction? >> They had better go clean up the promise tuples from the other u

Re: [HACKERS] Assertions in PL/PgSQL

On 2013-09-15 00:09, Pavel Stehule wrote: this is a possibility for introduction a new hook and possibility implement asserions and similar task in generic form (as extension). it can be assertions, tracing, profiling. You can already do tracing and profiling in an extension. I don't see what

Re: [HACKERS] GUC for data checksums

Hi, On 2013-09-14 18:33:38 +0200, Bernd Helmle wrote: > Attached is a small patch to add a new GUC to report wether data checksums > for a particular cluster are enabled. The only way to get this info afaik is > to look into pg_control and the version number used, but i'd welcome a way > to access

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On 2013-09-13 14:41:46 -0700, Peter Geoghegan wrote: > On Fri, Sep 13, 2013 at 12:23 PM, Andres Freund > wrote: > > The reason I wasn't saying "this will never get accepted" are twofold: > > a) I don't want to stiffle alternative ideas to the "promises" idea, > > just because I think it's the way

Re: [HACKERS] Assertions in PL/PgSQL

On 2013-09-14 23:55, Pavel Stehule wrote: but introduction a reserved keword for one very special purpose (without extensibility) is not prudent. How about using an existing keyword then? ASSERTION used to be reserved in the SQL standard but is unreserved in postgres. CHECK might work and i

Re: [HACKERS] Assertions in PL/PgSQL

Dne 14. 9. 2013 23:55 "Pavel Stehule" napsal(a): > > > Dne 14. 9. 2013 23:35 "Marko Tiikkaja" napsal(a): > > > > > On 2013-09-14 23:05, Pavel Stehule wrote: > >> > >> A some languages has a generic PRAGMA keyword. So I would be much more > >> happy with something like > >> > >> PRAGMA Assert(foun

Re: [HACKERS] Assertions in PL/PgSQL

Dne 14. 9. 2013 23:35 "Marko Tiikkaja" napsal(a): > > On 2013-09-14 23:05, Pavel Stehule wrote: >> >> A some languages has a generic PRAGMA keyword. So I would be much more >> happy with something like >> >> PRAGMA Assert(found); >> >> It is much more close to ADA, and it allows a reuse of new key

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On 2013-09-14 09:57:43 +0100, Greg Stark wrote: > It seems to me that the nature of the problem is that there will > unavoidably be a nexus between the two parts of the code here. We can try > to isolate it as much as possible but we're going to need a bit of a > compromise. I think Roberts and mi

Re: [HACKERS] Assertions in PL/PgSQL

On 2013-09-14 23:05, Pavel Stehule wrote: A some languages has a generic PRAGMA keyword. So I would be much more happy with something like PRAGMA Assert(found); It is much more close to ADA, and it allows a reuse of new keyword for any other usage in future (your proposal is too simply, without

Re: [HACKERS] [PATCH] bitmap indexes

Hi Abhijit, On 2013-09-14 23:44:24 +0530, Abhijit Menon-Sen wrote: > I've been working on this patch for a while, and have made some progress > towards (a) general fixing, and (b) a working VACUUM implementation (the > major remaining piece). Unfortunately, I've been busy moving house, and > the l

Re: [HACKERS] Where to load modules from?

On 2013-09-14 22:15:58 +0200, Dimitri Fontaine wrote: > The way they make that safe is by using cgroups and SELinux, IIUC. > > We can attack the problem in several ways: > > - have an initdb switch to tweak the library path per cluster, That sounds like an utterly horrible idea without any adv

Re: [HACKERS] PL/pgSQL, RAISE and error context

2013/9/14 Marko Tiikkaja > On 23/08/2013 10:36, I wrote: > >> On 8/23/13 8:38 AM, Pavel Stehule wrote: >> >>> do you prepare patch ? >>> >> >> I should have the time to produce one for the September commitfest, but >> if you (or anyone else) want to work on this, I won't object. >> >> My opinion

Re: [HACKERS] [RFC] Extend namespace of valid guc names

On 2013-02-25 22:15:33 +0100, Andres Freund wrote: > Currently guc-file.c allows the following as guc names: > > ID{LETTER}{LETTER_OR_DIGIT}* > QUALIFIED_ID {ID}"."{ID} > > That is either one token starting with a letter followed by numbers or > letters or exactly two of those separa

Re: [HACKERS] Assertions in PL/PgSQL

2013/9/14 Marko Tiikkaja > On 2013-09-14 22:40, I wrote: > >> Someone may prove me wrong here, but to me it looks like this would only >> prevent ASSERT from being used as the name of a PL/PgSQL variable. >> > > The comment at the beginning of pl_scanner.c seems to suggest same. > yes, there are

Re: [HACKERS] Assertions in PL/PgSQL

On 2013-09-14 22:40, I wrote: Someone may prove me wrong here, but to me it looks like this would only prevent ASSERT from being used as the name of a PL/PgSQL variable. The comment at the beginning of pl_scanner.c seems to suggest same. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mai

Re: [HACKERS] Assertions in PL/PgSQL

On 2013-09-14 22:24, Pavel Stehule wrote: There is a significant issue - new reserved keyword. There is high probability so lot of users has a functions named "assert". Someone may prove me wrong here, but to me it looks like this would only prevent ASSERT from being used as the name of a PL/P

Re: [HACKERS] Assertions in PL/PgSQL

El 14/09/2013 15:18, "Marko Tiikkaja" escribió: > > On 2013-09-14 21:55, Jaime Casanova wrote: >> >> On Sat, Sep 14, 2013 at 1:52 PM, Marko Tiikkaja wrote: >>> >>> And by "compile time" here, I mean at the time when the PL/PgSQL function >> >> is >>> >>> compiled, not the postgres server binary.

Re: [HACKERS] Assertions in PL/PgSQL

Hello There is a significant issue - new reserved keyword. There is high probability so lot of users has a functions named "assert". I like this functionality, but I dislike any compatibility break for feature, that can be implemented as extension without any lost of compatibility or lost of func

Re: [HACKERS] Assertions in PL/PgSQL

On 2013-09-14 21:55, Jaime Casanova wrote: On Sat, Sep 14, 2013 at 1:52 PM, Marko Tiikkaja wrote: And by "compile time" here, I mean at the time when the PL/PgSQL function is compiled, not the postgres server binary. and "compile time" means when the function is created or replaced? or the

[HACKERS] Where to load modules from?

Hi, This topic gets back at every release, more often now that we have proper Extensions with ability to dump&restore. Lately the guys from Open Shift project (a Red Hat team) have asked for a way to load DSO module files from user-owned directory. The way they make that safe is by using cgroups

Re: [HACKERS] information schema parameter_default implementation

Here is an updated patch which fixes the bug you have pointed out. On Thu, 2013-01-31 at 18:59 +0500, Ali Dar wrote: > I checked our your patch. There seems to be an issue when we have OUT > parameters after the DEFAULT values. Fixed. > Some other minor observations: > 1) Some variables are not

[HACKERS] PL Code Archive Proposal

Hi, In my efforts to allow PostgreSQL users to be able to fully use the server even when not granted file system level access to it, came the question of PL "lib" code management. Where do you manage the "library" code you need, those parts of your code that are not exposed at the SQL level? For

Re: [HACKERS] git apply vs patch -p1

On 09/14/2013 03:08 PM, Andres Freund wrote: On 2013-09-14 15:03:52 -0400, Andrew Dunstan wrote: On 09/14/2013 02:37 PM, Josh Berkus wrote: Folks, Lately I've been running into a lot of reports of false conflicts reported by "git apply". The most recent one was the "points" patch, which git

Re: [HACKERS] Assertions in PL/PgSQL

On Sat, Sep 14, 2013 at 1:52 PM, Marko Tiikkaja wrote: > On 14/09/2013 20:47, I wrote: >> >> These are >> similar to the Assert() backend macro: they can be disabled during >> compile time, but when enabled, abort execution if the passed expression >> is not true. > Hi, That's very good, thanks.

[HACKERS] json docs fixup

While writing slides for pgopen next week, I noticed that the JSON docs on json_populate_record and json_populate_recordset contain this sentence: A column may only be specified once. IIRC we removed that restriction during development, so unless there is a squawk I am going to simply r

Re: [HACKERS] git apply vs patch -p1

On 2013-09-14 15:03:52 -0400, Andrew Dunstan wrote: > > On 09/14/2013 02:37 PM, Josh Berkus wrote: > >Folks, > > > >Lately I've been running into a lot of reports of false conflicts > >reported by "git apply". The most recent one was the "points" patch, > >which git apply rejected for completely

Re: [HACKERS] Proposal: PL/PgSQL strict_mode

(Oops, just realized I only replied to a part of your message. I'm blaming it on my lack of sleep.) On 14/09/2013 06:53, chris travers wrote: 2) If you're running in strict mode and you want to insert/update/delete more than one row, things get a bit uglier; a wCTE would work for some cases. I

Re: [HACKERS] git apply vs patch -p1

On 09/14/2013 02:37 PM, Josh Berkus wrote: Folks, Lately I've been running into a lot of reports of false conflicts reported by "git apply". The most recent one was the "points" patch, which git apply rejected for completely ficticious reasons (it claimed that the patch was trying to create a

Re: [HACKERS] record identical operator

On 2013-09-14 11:25:52 -0700, Kevin Grittner wrote: > Andres Freund wrote: > > > what I am talking about is that > > e.g.: SELECT (ARRAY[1,2,3,NULL])[1:3] = ARRAY[1,2,3]; > > obviously should be true. > > The patch does not change the behavior of the = operator for any > type under any circumsta

Re: [HACKERS] Assertions in PL/PgSQL

On 14/09/2013 20:47, I wrote: These are similar to the Assert() backend macro: they can be disabled during compile time, but when enabled, abort execution if the passed expression is not true. And by "compile time" here, I mean at the time when the PL/PgSQL function is compiled, not the postgr

[HACKERS] Assertions in PL/PgSQL

Hi, Attached is a patch for supporting assertions in PL/PgSQL. These are similar to the Assert() backend macro: they can be disabled during compile time, but when enabled, abort execution if the passed expression is not true. A simple example: CREATE FUNCTION delete_user(username text) RET

Re: [HACKERS] pg_stat_statements: calls under-estimation propagation

On Sat, 2013-09-14 at 03:51 -0700, samthakur74 wrote: > We have a need to see this patch committed hence the revived interest > in this thread You have added this email to the commit fest, but it contains no patch. Please add the email with the actual patch. Maybe the author should be given a ch

[HACKERS] git apply vs patch -p1

Folks, Lately I've been running into a lot of reports of false conflicts reported by "git apply". The most recent one was the "points" patch, which git apply rejected for completely ficticious reasons (it claimed that the patch was trying to create a new file where a file already existed, which i

Re: [HACKERS] record identical operator

Andres Freund wrote: > what I am talking about is that > e.g.: SELECT (ARRAY[1,2,3,NULL])[1:3] = ARRAY[1,2,3]; > obviously should be true. The patch does not change the behavior of the = operator for any type under any circumstances. > But both arrays don't have the same binary representation s

[HACKERS] GUC for data checksums

Attached is a small patch to add a new GUC to report wether data checksums for a particular cluster are enabled. The only way to get this info afaik is to look into pg_control and the version number used, but i'd welcome a way to access this remotely, too. If there aren't any objections i'll add

Re: [HACKERS] review: pgbench progress report improvements

2013/9/12 Fabien COELHO > > Hello Pavel, > > Thanks for your review. > > > * patched with minor warning >> * compilable cleanly >> * zero impact on PostgreSQL server functionality >> * it does what was in proposal >> ** change 5sec progress as default (instead no progress) >> ** finalise a rate

Re: [HACKERS] review: pgbench progress report improvements

2013/9/13 Fabien COELHO > > Hello, > > About patch eols: > > >postgresql> patch -p1 < ../pgbench-measurements-v2.**patch >>> patching file contrib/pgbench/pgbench.c >>> patching file doc/src/sgml/pgbench.sgml >>> >> >> it can depends on o.s. I did tests on Fedora 14. and for patching

Re: [HACKERS] unaccent module - two params function should be immutable

2013/9/11 Bruce Momjian > On Tue, Feb 19, 2013 at 08:30:29AM +0100, Pavel Stehule wrote: > > Hello > > > > There was a proposal to change flag of function to immutable - should > > be used in indexes > > > > CREATE FUNCTION unaccent(regdictionary, text) > > RETURNS text > > AS 'MO

Re: [HACKERS] record identical operator

On 2013-09-13 19:20:11 -0700, Kevin Grittner wrote: > Andres Freund wrote: > > > Not one that's dependendant on padding bytes, null bitmaps that > > can or cannot be present and such. > > Can you provide an example of where that's an issue with this > patch? I haven't yet tested your patch, but

Re: [HACKERS] Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)

> "Peter" == Peter Eisentraut writes: Peter> Please fix compiler warnings: Someone should do the same in WaitForBackgroundWorkerStartup so that building with -Werror works. New patch coming shortly. -- Andrew. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To ma

Re: [HACKERS] pg_stat_statements: calls under-estimation propagation

>This patch needs documentation. At a minimum, the new calls_underest >field needs to be listed in the description of the pg_stat_statements. I have attached a version which includes documentation. pg_stat_statements-identification-v4.patch.gz

Re: [HACKERS] Proposal: PL/PgSQL strict_mode

On 14/09/2013 06:53, chris travers wrote: I am going to suggest that STRICT is semantically pretty far from what is meant here in common speech. I think STRICT here would be confusing. This would be really pretty severe for people coming from Perl or MySQL backgrounds. The name of the feature

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

I haven't read the patch and the btree code is an area I really don't know, so take this for what it's worth It seems to me that the nature of the problem is that there will unavoidably be a nexus between the two parts of the code here. We can try to isolate it as much as possible but we're go

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Fri, Sep 13, 2013 at 2:59 PM, Peter Geoghegan wrote: > I would suggest letting those other individuals speak for themselves > too. Particularly if you're going to name someone who is on vacation > like that. You seem to be under the impression that I'm mentioning Tom's name, or Andres's, becau

Re: [HACKERS] [PoC] pgstattuple2: block sampling to reduce physical read

(2013/07/23 20:02), Greg Smith wrote: > On 7/23/13 2:16 AM, Satoshi Nagayasu wrote: >> I've been working on new pgstattuple function to allow >> block sampling [1] in order to reduce block reads while >> scanning a table. A PoC patch is attached. > > Take a look at all of the messages linked in >

Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages

>On Monday, July 08, 2013 5:16 PM Andres Freund wrote: >>On 2013-07-08 17:10:43 +0530, Amit Kapila wrote: >>> On Monday, July 08, 2013 4:26 PM Andres Freund wrote: >>> > On 2013-07-08 16:17:54 +0530, Hari Babu wrote: >>> > > +This utility can also be used to decide whether backup is >>> > requi