[HACKERS] Doc typo in "9.28. Event Trigger Functions"

Just a single missing 's'. Regards Ian Barwick -- Ian Barwick http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml new file mode 100644 index 6e2fbda..b5807f3 *** a/doc/src/sgml/fu

Re: [HACKERS] PostgreSQL Columnar Store for Analytic Workloads

Hi Hadi Do you think that cstore_fd*w* is also welll suited for storing and retrieving linked data (RDF)? -S. 2014-04-03 18:43 GMT+02:00 Hadi Moshayedi : > Dear Hackers, > > We at Citus Data have been developing a columnar store extension for > PostgreSQL. Today we are excited to open source

Re: [HACKERS] four minor proposals for 9.5

On Mon, Apr 7, 2014 at 12:16 AM, Pavel Stehule wrote: > 2014-04-04 6:51 GMT+02:00 Amit Kapila : >> On Tue, Apr 1, 2014 at 11:42 PM, Pavel Stehule >> wrote: >> > 2014-03-27 17:56 GMT+01:00 Pavel Stehule : >> >> So I'll prepare a some prototypes in next month for >> >> >> >> 1. log a execution time

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

Robert Haas writes: > On Mon, Apr 7, 2014 at 4:19 PM, Tom Lane wrote: >> Alvaro Herrera writes: >>> What it does is add a new function pg_stat_statements_reset_time() which >>> resets the min and max values from all function's entries, without >>> touching the stddev state variables nor the numb

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

On Mon, Apr 7, 2014 at 4:19 PM, Tom Lane wrote: > Alvaro Herrera writes: >> I just noticed that this patch not only adds min,max,stddev, but it also >> adds the ability to reset an entry's counters. This hasn't been >> mentioned in this thread at all; there has been no discussion on whether >> t

Re: [HACKERS] WAL replay bugs

On Tue, Apr 8, 2014 at 3:16 AM, Heikki Linnakangas wrote: > > I've been playing with a little hack that records a before and after image > of every page modification that is WAL-logged, and writes the images to a > file along with the LSN of the corresponding WAL record. I set up a > master-standb

[HACKERS] Default gin operator class of jsonb failing with index row size maximum reached

Hi all, While doing some tests with jsonb, I found a failure as told in $subject: =# create table data_jsonb (data jsonb); CREATE TABLE =# insert into data_jsonb ... tuple in the script attached INSERT 1 =# create index data_index on data_jsonb using gin(data); ERROR: 54000: index row size 1808 e

Re: [HACKERS] WAL replay bugs

On 04/07/2014 02:16 PM, Heikki Linnakangas wrote: > I've been playing with a little hack that records a before and after > image of every page modification that is WAL-logged, and writes the > images to a file along with the LSN of the corresponding WAL record. I > set up a master-standby replicati

Re: [HACKERS] Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers

Andres Freund writes: > On 2014-04-07 16:29:57 -0400, Tom Lane wrote: >> In that case you should have another tuple slot of your own and let it >> keep the tuple (and buffer pin). > that's not going to work, because scantuple might be free'd or pointing > to another tuple, from the next index_get

Re: [HACKERS] CREATE FOREIGN TABLE ( ... LIKE ... )

On Tue, Apr 8, 2014 at 5:24 AM, Andres Freund wrote: > On 2014-04-05 11:46:16 -0400, Tom Lane wrote: >> ISTM this is because the proposed feature is wrongheaded. The basic >> concept of CREATE TABLE LIKE is that you're copying properties from >> another object of the same type. You might or migh

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 3:49 PM, Robert Haas wrote: > Now that is definitely interesting, and it does seem to demonstrate > that the worst case for this patch might not be as bad as I had feared > - it's about a 5% regression: not great, but perhaps tolerable. It's > not actually a worse case unle

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 4:35 PM, Peter Geoghegan wrote: > The much earlier datum1 optimization is mostly compelling for > pass-by-value types, for reasons that prominently involve > cache/locality considerations. I agree. > That's probably why this patch is so > compelling - it makes those advant

Re: [HACKERS] Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers

On 2014-04-07 16:29:57 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-04-07 15:58:31 -0400, Tom Lane wrote: > >> There's an assumption that if you are asking to pin a buffer, the tuple > >> pointer you're passing is pointing into that buffer (and is therefore not > >> something that co

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 11:47 AM, Robert Haas wrote: > It's not a question of whether your test case is contrived. Your test > case can be (and likely is) extremely realistic and still not account > for other cases when the patch regresses performance. If I understand > correctly, and I may not b

Re: [HACKERS] Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers

Andres Freund writes: > On 2014-04-07 15:58:31 -0400, Tom Lane wrote: >> There's an assumption that if you are asking to pin a buffer, the tuple >> pointer you're passing is pointing into that buffer (and is therefore not >> something that could be pfree'd). If it isn't pointing into a buffer, >>

Re: [HACKERS] CREATE FOREIGN TABLE ( ... LIKE ... )

On 2014-04-05 11:46:16 -0400, Tom Lane wrote: > ISTM this is because the proposed feature is wrongheaded. The basic > concept of CREATE TABLE LIKE is that you're copying properties from > another object of the same type. You might or might not want every > property, but there's no question of whe

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

Andres Freund writes: > I am a bit confused. To my eyes there's been a huge number of actually > trivial patches in this commitfest? Even now, there's some: > * Bugfix for timeout in LDAP connection parameter resolution > * Problem with displaying "wide" tables in psql > * Enable CREATE FOREIGN T

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

Alvaro Herrera writes: > I just noticed that this patch not only adds min,max,stddev, but it also > adds the ability to reset an entry's counters. This hasn't been > mentioned in this thread at all; there has been no discussion on whether > this is something we want to have, nor on whether this i

Re: [HACKERS] Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers

On 2014-04-07 15:58:31 -0400, Tom Lane wrote: > Andres Freund writes: > > I've the need to persist a the result of an index_getnext() in a tuple > > slot. I don't want to unneccessarily duplicate the tuple data itself, so > > I'd like to use ExecStoreTuple(buffer = real_buffer) notion. But since >

Re: [HACKERS] Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers

Andres Freund writes: > I've the need to persist a the result of an index_getnext() in a tuple > slot. I don't want to unneccessarily duplicate the tuple data itself, so > I'd like to use ExecStoreTuple(buffer = real_buffer) notion. But since > the next index_getnext()/index_endscan() will overwri

Re: [HACKERS] "Transaction local" statistics are incorrect at speed

* Tom Lane (t...@sss.pgh.pa.us) wrote: > This seems like a pretty clear bug to me; does anyone want to argue > that it isn't? I'd agree that it's a bug. > In the case of pg_stat_get_xact_tuples_inserted and a couple of other > routines, it would be entirely trivial to fix: just ignore > tabentry-

[HACKERS] Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers

Hi, I've the need to persist a the result of an index_getnext() in a tuple slot. I don't want to unneccessarily duplicate the tuple data itself, so I'd like to use ExecStoreTuple(buffer = real_buffer) notion. But since the next index_getnext()/index_endscan() will overwrite/release the heaptuple I

[HACKERS] "Transaction local" statistics are incorrect at speed

My Salesforce colleague Teja Mupparti found an interesting bug. Consider the following example: drop table if exists test; create table test(i int); insert into test values(1); select pg_sleep(1); begin; insert into test values(2); insert into test values(3); select pg_stat_get_xact_tuples_inse

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

* Peter Geoghegan (p...@heroku.com) wrote: > Actually, contrary to the original subject of this thread, that isn't > the case. I have not added a support function 3, which I ultimately > concluded was a bad idea. This is all sort support. Well, as apparently no one is objecting to Greg reviewing i

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 2:56 PM, Greg Stark wrote: > On Mon, Apr 7, 2014 at 11:37 AM, Robert Haas wrote: >> You're >> essentially leveraging a commit bit that you haven't used in more than >> three years to try to push a patch that was submitted months too late > > I'm not leveraging anything any

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 11:56 AM, Greg Stark wrote: > On Mon, Apr 7, 2014 at 11:37 AM, Robert Haas wrote: >> You're >> essentially leveraging a commit bit that you haven't used in more than >> three years to try to push a patch that was submitted months too late > > > I'm not leveraging anything a

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 11:59 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> There are patches that are trivial enough >> that it's fine for someone to commit them without a public review >> first, but this isn't remotely close to being in that category. If >> nothing e

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 11:37 AM, Robert Haas wrote: > You're > essentially leveraging a commit bit that you haven't used in more than > three years to try to push a patch that was submitted months too late I'm not leveraging anything any I'm not going to push something unless people are on board

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

* Robert Haas (robertmh...@gmail.com) wrote: > There are patches that are trivial enough > that it's fine for someone to commit them without a public review > first, but this isn't remotely close to being in that category. If > nothing else, the fact that it extends the definition of the btree > o

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 2:35 PM, Andres Freund wrote: > On 2014-04-07 14:35:23 -0400, Stephen Frost wrote: >> That said, for my part, I don't like telling Greg that >> he either has to review something else which was submitted but that he's >> got no interest in (or which would take much longer), o

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

* Andres Freund (and...@2ndquadrant.com) wrote: > On 2014-04-07 14:35:23 -0400, Stephen Frost wrote: > > That said, for my part, I don't like telling Greg that > > he either has to review something else which was submitted but that he's > > got no interest in (or which would take much longer), or n

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 2:19 PM, Peter Geoghegan wrote: > On Mon, Apr 7, 2014 at 10:47 AM, Robert Haas wrote: >> To throw out one more point that I think is problematic, Peter's >> original email on this thread gives a bunch of examples of strxfrm() >> normalization that all different in the first

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On 2014-04-07 14:35:23 -0400, Stephen Frost wrote: > That said, for my part, I don't like telling Greg that > he either has to review something else which was submitted but that he's > got no interest in (or which would take much longer), or not do > anything. Reviewing and committing are two very

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > That's why we have this rule that CF4 should only receive patches that > were already reviewed in previous commitfests. I, at least, always understood that rule to be 'large' patches, which this didn't strike me as. > I, too, find the > fast-tr

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Apr 7, 2014 at 1:58 PM, Stephen Frost wrote: > > The issue on it being called "poorman"? That doesn't exactly strike me > > as needing a particularly long discussion, nor that it would be > > difficult to change later. I agree that there may

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 2:12 PM, Stephen Frost wrote: >> I think it'd be a different discussion if this where CF-1 or so. But >> we're nearly *2* months after the the *end* of the last CF. > > There wouldn't be any discussion if it was CF-1 as I doubt anyone would > object to it going in (or at lea

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

Stephen Frost wrote: > * Andres Freund (and...@2ndquadrant.com) wrote: > > I think it'd be a different discussion if this where CF-1 or so. But > > we're nearly *2* months after the the *end* of the last CF. > > There wouldn't be any discussion if it was CF-1 as I doubt anyone would > object to i

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On 2014-04-07 14:12:09 -0400, Stephen Frost wrote: > I can take a look at that (if no one else wants to speak up about it). > > > * Problem with displaying "wide" tables in psql > > That's not without controvery, as I understand it, but I admit that I > haven't been following it terribly closely.

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 10:47 AM, Robert Haas wrote: > To throw out one more point that I think is problematic, Peter's > original email on this thread gives a bunch of examples of strxfrm() > normalization that all different in the first few bytes - but so do > the underlying strings. I *think* (

[HACKERS] WAL replay bugs

I've been playing with a little hack that records a before and after image of every page modification that is WAL-logged, and writes the images to a file along with the LSN of the corresponding WAL record. I set up a master-standby replication with that hack in place in both servers, and ran

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

* Robert Haas (robertmh...@gmail.com) wrote: > To throw out one more point that I think is problematic, Peter's > original email on this thread gives a bunch of examples of strxfrm() > normalization that all different in the first few bytes - but so do > the underlying strings. I *think* (but don'

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 1:58 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> If it's only going to take you an hour to address this patch (or 8 to >> address those other ones) then you spend a heck of a lot less time on >> review for a patch of a given complexity level th

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

* Andres Freund (and...@2ndquadrant.com) wrote: > On 2014-04-07 13:01:52 -0400, Stephen Frost wrote: > > I haven't got any either (except for my little one), which frustrates > > me greatly. Not because I'm looking for credit on the time that I've > > spent in discussions, doing reviews, and I cou

Re: [HACKERS] Firing trigger if only

On Thu, Apr 3, 2014 at 8:50 AM, Gabriel wrote: > Good afternoon all.I have some problem with triggers on PostgreSQL 8.4.I > have > a trigger on specific table(articles) that fires on update statement: > > CREATE OR REPLACE FUNCTION trigger_articles_update() > RETURNS trigger AS > $BODY$BEGIN >

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

* Robert Haas (robertmh...@gmail.com) wrote: > If it's only going to take you an hour to address this patch (or 8 to > address those other ones) then you spend a heck of a lot less time on > review for a patch of a given complexity level than I do. Eh, I don't really time it and I'm probably com

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On 2014-04-07 13:01:52 -0400, Stephen Frost wrote: > I haven't got any either (except for my little one), which frustrates > me greatly. Not because I'm looking for credit on the time that I've > spent in discussions, doing reviews, and I could have sworn there was > some patch that I did commit,

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On 2014-04-07 10:29:53 -0700, Peter Geoghegan wrote: > On Mon, Apr 7, 2014 at 10:23 AM, Robert Haas wrote: > > As an utterly trivial point, I > > find the naming to be less than ideal: "poorman" is not a term I want > > to enshrine in our code. That's not very descriptive of what the > > patch is

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 1:23 PM, Robert Haas wrote: > As an utterly trivial point, I > find the naming to be less than ideal: "poorman" is not a term I want > to enshrine in our code. That's not very descriptive of what the > patch is actually doing even if you know what the idiom means, and > peo

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 10:42 AM, Andres Freund wrote: >> I didn't come up with the idea, or the name. > > Doesn't mean it needs to be enshrined everywhere. I don't think Robert's > against putting it in some comments. That seems reasonable. If someone wants to call what I have here semi-reliable

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

KONDO Mitsumasa wrote: > Hi all, > > I think this patch is completely forgotten, and feel very unfortunate:( > > Min, max, and stdev is basic statistics in general monitoring tools, > So I'd like to push it. I just noticed that this patch not only adds min,max,stddev, but it also adds the abilit

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 10:23 AM, Robert Haas wrote: > As an utterly trivial point, I > find the naming to be less than ideal: "poorman" is not a term I want > to enshrine in our code. That's not very descriptive of what the > patch is actually doing even if you know what the idiom means, and > pe

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Mon, Apr 7, 2014 at 1:01 PM, Stephen Frost wrote: > All that said, I don't have any particularly good idea of how to "fix" > any of this- it's not fair to tell the committers who have more time (or > larger blocks of time, etc) "you must work the hard problems only" > either. I don't feel Greg

Re: Fwd: [HACKERS] Proposal: variant of regclass

On 2014-04-07 12:59:36 -0400, Tom Lane wrote: > Andres Freund writes: > > There's actually another good reason to not copy regclass's behaviour: > > > postgres=# CREATE TABLE "123"(); > > CREATE TABLE > > postgres=# SELECT '123'::regclass; > > regclass > > -- > > 123 > > (1 row) >

Re: Fwd: [HACKERS] Proposal: variant of regclass

Andres Freund writes: > There's actually another good reason to not copy regclass's behaviour: > postgres=# CREATE TABLE "123"(); > CREATE TABLE > postgres=# SELECT '123'::regclass; > regclass > -- > 123 > (1 row) > I don't think that's fixable for ::regclass, but we shouldn't copy

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

* Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Apr 4, 2014 at 4:29 PM, Greg Stark wrote: > > I've been meaning to do more review for a while and just took a skim through > > the queue. There are only a couple I feel I can contribute with so I'm going > > to work on those and then if it's s

Re: [HACKERS] Including replication slot data in base backups

Em segunda-feira, 7 de abril de 2014, Robert Haas escreveu: > On Mon, Apr 7, 2014 at 3:04 AM, Michael Paquier > > wrote: > > On Fri, Apr 4, 2014 at 9:57 PM, Michael Paquier > > > wrote: > >> For 9.4, clearly yes, this would change the semantic of recovery and > >> this is not something wise to do

Re: Fwd: [HACKERS] Proposal: variant of regclass

On 2014-04-04 11:18:10 -0400, Robert Haas wrote: > On Wed, Apr 2, 2014 at 11:27 PM, Amit Kapila wrote: > > Right, it will get reset in error. However still we need to free for > > missing_ok > > case and when it is successful in getting typeid. So don't you think it is > > better to just free onc

Re: Fwd: [HACKERS] Proposal: variant of regclass

Robert Haas writes: > In other words, let's revert the whole refactoring of this file to > create reg*_guts functions, and instead just copy the relevant logic > for the name lookups into the new functions. The main discomfort I'd had with this patch was the amount of refactoring it did; that mad

Re: [HACKERS] Including replication slot data in base backups

On Mon, Apr 7, 2014 at 3:04 AM, Michael Paquier wrote: > On Fri, Apr 4, 2014 at 9:57 PM, Michael Paquier > wrote: >> For 9.4, clearly yes, this would change the semantic of recovery and >> this is not something wise to do at the end of a development cycle. >> For 9.5 though, this is a different s

Re: [HACKERS] Useless "Replica Identity: NOTHING" noise from psql \d

On Sat, Apr 5, 2014 at 7:12 AM, Andres Freund wrote: > On 2014-04-03 14:49:54 -0400, Andrew Dunstan wrote: >> I've been kind of hoping that someone would step up on both these items, but >> the trail seems to have gone cold. >> >> I'm going to put out the new buildfarm release with the new module

Re: Fwd: [HACKERS] Proposal: variant of regclass

On Sat, Apr 5, 2014 at 1:10 AM, Amit Kapila wrote: > The reason of this behavior is that in out functions (regclassout), we return > the OID as it is incase it doesn't exist. One way to fix this is incase of > OID input parameters, we check if the passed OID exists in to_* functions > and return

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

On 7 April 2014 14:09, Florian Pflug wrote: > On Apr5, 2014, at 09:55 , Dean Rasheed wrote: >> On 5 April 2014 08:38, Dean Rasheed wrote: >>> [snip] releasing it in this state feels a little half-baked >>> to me. >>> >> >> I regret writing that almost as soon as I sent it. The last of those >> q

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Fri, Apr 4, 2014 at 4:29 PM, Greg Stark wrote: > On Fri, Apr 4, 2014 at 12:15 PM, Robert Haas wrote: >> >> Perhaps I shouldn't lay my own guilt trip on other committers --- but >> >> I think it would be a bad precedent to not deal with the existing patch >> >> queue first. >> > >> > +1 >> >> +

Re: [HACKERS] FastPathStrongRelationLocks still has an issue in HEAD

On Mon, Apr 7, 2014 at 10:54 AM, Tom Lane wrote: >> [ LockRefindAndRelease ] lacks an >> Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0). I think >> we should add one. > > Absolutely. Turns out there were two places missing such an assertion: the 2PC path, and the abort-strong-lock-

Re: [HACKERS] GSoC 2014: Implementing clustering algorithms in MADlib

Hi Maxence, This is really really good. Hopefully we will have a fruitful summer, and make MADlib a better product. Thanks Hai -- *Pivotal * A new platform for a new era On Sat, Apr 5, 2014 at 7:14 AM, Maxence Ahlouche wrote: > Hi all, > > 2014-04-03 9:04 GMT+02:0

Re: [HACKERS] FastPathStrongRelationLocks still has an issue in HEAD

Robert Haas writes: > On Sun, Apr 6, 2014 at 1:23 PM, Tom Lane wrote: >> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rover_firefly&dt=2014-04-06%2017%3A04%3A00 > Uggh. That's unfortunate, but not terribly surprising: I didn't think > that missing volatile was very likely to be the ca

Re: [HACKERS] gsoc knn spgist

On Fri, Apr 4, 2014 at 11:56 AM, Костя Кузнецов wrote: > I want to implement knn for spgist. I dont have question with knn, but have > questions with implementation of interface. > > i modify pg_am.h (set amcanorderbyop to true in spgist index).Also i modify > pg_amop.h(add > > DATA(insert (4

Re: [HACKERS] FastPathStrongRelationLocks still has an issue in HEAD

On 2014-04-07 10:45:51 -0400, Robert Haas wrote: > On Mon, Apr 7, 2014 at 10:20 AM, Andres Freund wrote: > > Hm. It generally might be interesting to get a few !X86 buildfarms > > running builds with LTO enabled. That might expose some dangerous > > assumptions more easily. > > I strongly suspect

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

On Sat, Apr 5, 2014 at 10:54 AM, Tom Lane wrote: > So basically, I think having pg_ctl try to do what this patch proposes > is a bad idea. I'm not a Windows person either, but I tend to agree. I can't think that this is going to be very robust ... and if it's not going to be robust, what's the p

Re: [HACKERS] FastPathStrongRelationLocks still has an issue in HEAD

On Mon, Apr 7, 2014 at 10:20 AM, Andres Freund wrote: > On 2014-04-07 10:06:07 -0400, Robert Haas wrote: >> I'm a bit suspicious of the patches to >> static-ify stuff, since that might cause the compiler to think it >> could move things across function calls that it hadn't thought >> move-able bef

Re: [HACKERS] ipc_test

On Fri, Apr 4, 2014 at 10:11 AM, Tom Lane wrote: > Andres Freund writes: >> On 2014-04-04 09:31:01 -0400, Robert Haas wrote: >>> Does anybody care about being able to compile ipc_test as a standalone >>> binary any more? > >> I don't. > > I can't remember the last time I had use for it either. +

Re: [HACKERS] Windows exit code 128 ... it's baaack

On 2014-04-05 11:05:09 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-02-27 19:14:13 -0500, Tom Lane wrote: > >> I looked at the postmaster log for the ongoing issue on narwhal > >> (to wit, that the contrib/dblink test dies the moment it tries > >> to do anything dblink-y), and looky

Re: [HACKERS] FastPathStrongRelationLocks still has an issue in HEAD

On 2014-04-07 10:06:07 -0400, Robert Haas wrote: > I'm a bit suspicious of the patches to > static-ify stuff, since that might cause the compiler to think it > could move things across function calls that it hadn't thought > move-able before, but FastPathStrongLocks references would seem to be > th

Re: [HACKERS] tds_fdw for Sybase and MS SQL Server

Excellent! I have an application for this. I'll give it a look. Thanks! Mike __ *Mike Blackwell | Technical Analyst, Distribution Services/Rollout Management | RR Donnelley* 1750 Wallace Ave | St Charles, IL 60174-3

Re: [HACKERS] FastPathStrongRelationLocks still has an issue in HEAD

On Sun, Apr 6, 2014 at 1:23 PM, Tom Lane wrote: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rover_firefly&dt=2014-04-06%2017%3A04%3A00 > > TRAP: FailedAssertion("!(FastPathStrongRelationLocks->count[fasthashcode] > > 0)", File: "lock.c", Line: 1240) > [53418a51.6a08:2] LOG: server p

Re: [HACKERS] Pending 9.4 patches

Craig Ringer writes: > On 04/05/2014 03:57 AM, Andres Freund wrote: >> r04) Row-security based on Updatable security barrier views >> This one's fate seems to be hard to judge without c07. > Open issues remain with this patch, and resources for working on it in > 9.4 have run out. > It is not re

Re: [HACKERS] PQputCopyData dont signal error

Martijn van Oosterhout writes: > To move the conversation along: > https://github.com/postgres/postgres/blob/master/src/bin/psql/copy.c#L664 > Seems possibly even more robust than most people will code, but it's > had a lot of real world testing. Note that the looping behavior there is actually

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

Amit Kapila writes: > On Sat, Apr 5, 2014 at 8:24 PM, Tom Lane wrote: >> How's that going to work during pg_ctl stop? There's no -o switch >> provided. > As there's no -o switch, so there won't be problem of getting wrong event > source name from server due to command line options which you men

Re: [HACKERS] Proposal: COUNT(*) (and related) speedup

On 04 April 2014 18:09, Joshua Yanovski Wrote: > The counter would be updated only by VACUUM, which would perform the > same computation performed by the COUNT operation but add it > permanently to counter just before it set the visible_map bit to 1 (I > am not certain whether this would requir

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

On Apr5, 2014, at 09:55 , Dean Rasheed wrote: > On 5 April 2014 08:38, Dean Rasheed wrote: >> [snip] releasing it in this state feels a little half-baked >> to me. >> > > I regret writing that almost as soon as I sent it. The last of those > queries is now over 10 times faster than HEAD, which

Re: [HACKERS] automatically updating security barrier views

* Drew Crawford (d...@sealedabstract.com) wrote: > I am willing to take on some tasks in support of solving this problem in 9.4, > but my unfamiliarity with the codebase means that realistically I’m not of > much help. Certainly, if there is something I could be doing, please let me > know. Do

Re: [HACKERS] Autonomous Transaction (WIP)

2014-04-07 12:16 GMT+02:00 Atri Sharma : > > > > On Mon, Apr 7, 2014 at 3:41 PM, Pavel Stehule wrote: > >> >> >> >> 2014-04-07 11:59 GMT+02:00 Rajeev rastogi : >> >> On 07 April 2014 12:12, Pavel Stehule wrote: >>> >>> >+1 for feature >>> >>> Thanks >>> >>> >>> >>> >-1 for Oracle syntax - it is

Re: [HACKERS] Autonomous Transaction (WIP)

On 2014-04-07 15:46:42 +0530, Atri Sharma wrote: > On Mon, Apr 7, 2014 at 3:41 PM, Pavel Stehule wrote: > I am missing something here, but how does making it a subtransaction break > consistency? Isnt that what should actually be happening so that the > autonomous transaction's changes are actually

Re: [HACKERS] Autonomous Transaction (WIP)

On Mon, Apr 7, 2014 at 3:41 PM, Pavel Stehule wrote: > > > > 2014-04-07 11:59 GMT+02:00 Rajeev rastogi : > > On 07 April 2014 12:12, Pavel Stehule wrote: >> >> >+1 for feature >> >> Thanks >> >> >> >> >-1 for Oracle syntax - it is hardly inconsistent with Postgres >> >> We can discuss and come

Re: [HACKERS] Autonomous Transaction (WIP)

2014-04-07 11:59 GMT+02:00 Rajeev rastogi : > On 07 April 2014 12:12, Pavel Stehule wrote: > > >+1 for feature > > Thanks > > > > >-1 for Oracle syntax - it is hardly inconsistent with Postgres > > We can discuss and come out with the syntax based on everyone agreement. > > >Autonomous transacti

Re: [HACKERS] Autonomous Transaction (WIP)

On 07 April 2014 12:12, Pavel Stehule wrote: >+1 for feature Thanks >-1 for Oracle syntax - it is hardly inconsistent with Postgres We can discuss and come out with the syntax based on everyone agreement. >Autonomous transactions should be used everywhere - not only in plpgsql Yes you are right.

Re: [HACKERS] Autonomous Transaction (WIP)

On 07 April 2014 12:20, Craig Ringer > > > Syntax to create autonomous transaction can be as: > > > > */PRAGMA AUTONOMOUS TRANSACTION;/* > > Wouldn't you want to use SET TRANSACTION for this? > > Or a suffix on BEGIN, like BEGIN AUTONOMOUS TRANSACTION ? > > What's the lo

Re: [HACKERS] PQputCopyData dont signal error

On Tue, Apr 01, 2014 at 01:53:13PM -0400, Robert Haas wrote: > > One of the things you mentioned is "I often find it necessary to refer to > > existing examples of code when trying to figure out how to do things > > correctly". I couldn't agree more. Haven't seen one yet, but found plenty > > of

Re: [HACKERS] Get more from indices.

Hi Horiguchi-san, Sorry for not reviewing this patch in the last CF. (2014/03/10 16:21), Kyotaro HORIGUCHI wrote: Oops! I found a bug in this patch. The previous v8 patch missed the case that build_index_pathkeys() could build a partial pathkeys from the index tlist. This causes the situation

Re: [HACKERS] polymorphic SQL functions has a problem with domains

2014-04-02 17:19 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > I was informed about impossibility to use a polymorphic functions > together > > with domain types > > > see > > > create domain xx as numeric(15); > > > create or replace function g(anyelement, anyelement) > > returns anyelement

Re: [HACKERS] Including replication slot data in base backups

On Fri, Apr 4, 2014 at 9:57 PM, Michael Paquier wrote: > For 9.4, clearly yes, this would change the semantic of recovery and > this is not something wise to do at the end of a development cycle. > For 9.5 though, this is a different story. It clearly depends on if > this is though as useful enoug

Re: [HACKERS] Autonomous Transaction (WIP)

On 07/04/14 15:50, Craig Ringer wrote: On 04/07/2014 12:06 PM, Rajeev rastogi wrote: Syntax to create autonomous transaction can be as: */PRAGMA AUTONOMOUS TRANSACTION;/* Wouldn't you want to use SET TRANSACTION for this? Or a suffix on BEGIN, like BEGIN AUTONOMOUS

Re: [HACKERS] Pending 9.4 patches

On 04/05/2014 03:57 AM, Andres Freund wrote: > c07) Updatable security barrier views. > This needs a serious look by a committer. I've been exercising it via row security and it's been looking pretty solid. It isn't a huge or intrusive patch, and it's seen several rounds of discussion durin