Re: [HACKERS] Extensions makefiles - coverage

On Sunday 22 September 2013 01:34:53 Peter Eisentraut wrote: > On Thu, 2013-07-25 at 17:07 +0200, Ronan Dunklau wrote: > > I am using approximatively the layout that was proposed here: > > http://www.postgresql.org/message-id/51bb1b6e.2070...@dunslane.net > > It looks like everything is hard-coded

Re: [HACKERS] 9.3 Json & Array's

> On 23 September 2013 at 23:37 Adam Jelinek wrote: > > I am sure I am doing something wrong here, or this is an unsupported feature, > but I wanted to double check. I was hoping that if I did a json_agg(x) and > then copied that output of that and passed it into a json_populate_recordset > t

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

On Mon, Sep 23, 2013 at 7:06 PM, Alvaro Herrera wrote: > I think the idea that we should consider a different way of handling > tabular configuration data has merit. In fact, how much sense does it > make to have these options (the ones for which this patch is being > written) be GUCs in the firs

Re: [HACKERS] Completing PL support for Event Triggers

On Fri, 2013-09-13 at 22:40 +0200, Dimitri Fontaine wrote: > Please find attached to this email three patches covering the missing PL > support for Event Triggers: pltcl, plperl and plpython. You introduced some new compiler warnings, please fix those. http://pgci.eisentraut.org/jenkins/view/Post

Re: [HACKERS] logical changeset generation v6

On Mon, Sep 23, 2013 at 8:12 PM, Robert Haas wrote: > The existence of a tool like > pg_receivellog seems to presuppose that the goal is spit out logical > change records as text, but I'm not sure that's actually going to be a > very common thing to want to do... Sure, but I think it's still wort

Re: [HACKERS] dynamic shared memory

On Tue, Sep 24, 2013 at 12:32 AM, Noah Misch wrote: > On Mon, Sep 23, 2013 at 10:43:33AM +0530, Amit Kapila wrote: >> On Mon, Sep 23, 2013 at 12:34 AM, Noah Misch wrote: >> > On Sun, Sep 22, 2013 at 01:17:52PM +0530, Amit Kapila wrote: >> >> #ifdef WIN32 >> >> /* use CRLF line endings on Windows

Re: [HACKERS] logical changeset generation v6

On Mon, Sep 23, 2013 at 1:11 PM, Alvaro Herrera wrote: > Andres Freund escribió: >> On 2013-09-23 13:47:05 -0300, Alvaro Herrera wrote: > >> > I had proposed pg_recvlogical >> >> I still find it wierd/inconsistent to have: >> * pg_receivexlog >> * pg_recvlogical >> binaries, even from the same sou

Re: [HACKERS] record identical operator

On Mon, Sep 23, 2013 at 9:21 PM, Stephen Frost wrote: > Here's an example to illustrate what I'm talking about when it comes > down to "you can't claim that you'll produce exactly what the query > will always, with these types:" Your example demonstrates that if a given query can generate two dif

Re: [HACKERS] record identical operator

* Kevin Grittner (kgri...@ymail.com) wrote: > I'm trying to figure out what situation you think we're in. > Seriously, if you could apply the patch and show one example that > demonstrates what you see to be a problem, that would be great. Here's an example to illustrate what I'm talking about whe

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

On Mon, Sep 23, 2013 at 12:49 PM, Robert Haas wrote: >> and you cannot throw a serialization failure at read committed. > > Not sure that's true, but at least it might not be the most desirable > behavior. I'm pretty sure that that's totally true. "You don't have to worry about serialization fai

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

On Mon, Sep 23, 2013 at 12:49 PM, Robert Haas wrote: >> Right, but what about XactLockTableWait() itself? It only acquires a >> ShareLock on the xid of the got-there-first inserter that potentially >> hasn't yet committed/aborted. > > That's an interesting point. As you pointed out in later email

Re: [HACKERS] UTF8 national character data type support WIP patch and list of open issues.

From: "Robert Haas" Sure, it's EnterpriseDB's policy to add features that facilitate migrations from other databases - particularly Oracle - to our product, Advanced Server, even if those features don't otherwise add any value. However, the community is usually reluctant to add such features to

[HACKERS] 9.3 Json & Array's

I am sure I am doing something wrong here, or this is an unsupported feature, but I wanted to double check. I was hoping that if I did a json_agg(x) and then copied that output of that and passed it into a json_populate_recordset that I would get the record back. I know I can make things work usin

Re: [HACKERS] GIN improvements part 1: additional information

On Mon, Sep 23, 2013 at 12:47 AM, Alexander Korotkov wrote: > It's probably an option to select 64 entries instead of 32. > There is still some regression in update speed. However, there is also > room for improvement patch. It searches item index entries 2 times on > insert: in dataLocateLeafItem

Re: [HACKERS] record identical operator

* Robert Haas (robertmh...@gmail.com) wrote: > In this case even something > like AVG() could produce the same result as it did before the update. > And you'd surely want to avoid updating the matview if the new value > was the same as what was already stored in the matview (but not if it > was equ

Re: [HACKERS] UTF8 national character data type support WIP patch and list of open issues.

On 9/23/13 2:53 AM, MauMau wrote: > Yes, I believe you are right. Regardless of whether we support multiple > encodings in one database or not, a single client encoding will be > sufficient for one session. When receiving the "Q" message, the whole > SQL text is converted from the client encoding

Re: [HACKERS] SSL renegotiation

Here's an updated version; this mainly simplifies code, per comments from Andres (things were a bit too baroque in places due to the way the code had evolved, and I hadn't gone over it to simplify it). The only behavior change is that the renegotiation is requested 1kB before the limit is hit: the

Re: [HACKERS] logical changeset generation v6

On 9/23/13 12:54 PM, Andres Freund wrote: > I still find it wierd/inconsistent to have: > * pg_receivexlog > * pg_recvlogical > binaries, even from the same source directory. Why once "pg_recv" and > once "pg_receive"? It's consistent because they are the same length! (Obviously, this would sever

Re: [HACKERS] pgbench progress report improvements - split 2

On Sun, Sep 22, 2013 at 08:46:55PM +0200, Fabien wrote: > pgbench: reduce and compensate throttling underestimation bias. > > This is a consequence of relying on an integer random generator, > which allow to ensure that delays inserted stay reasonably in > range of the target average delay. > > The

Re: [HACKERS] record identical operator

* Kevin Grittner (kgri...@ymail.com) wrote: > The only thing the paper says on the topic is that any incremental > maintenance scheme is a heuristic.  There will always be cases when > it would be faster and less resource-intensive to regenerate the > data from the defining query.  There is at leas

Re: [HACKERS] record identical operator

* Robert Haas (robertmh...@gmail.com) wrote: > I don't know why there shouldn't be a question about that. Because anything else would be an internal optimization which must be proven to be correct, imv, also.. > Suppose > that the MAX() aggregate is in use. If 4 or 5 or 6 is updated so as > to

Re: [HACKERS] Improving avg performance for numeric

On 23 Září 2013, 18:18, Pavel Stehule wrote: > Hello > > > 2013/9/22 Tomas Vondra > >> Hi, >> >> I've reviewed the v6 of the "numeric optimize" patch >> (http://www.postgresql.org/**message-id/**CAFj8pRDQhG7Pqmf8XqXY0PnHfakkP** >> QLPHnoRLJ_=EKFSbOAWeA@mail.**gmail.com

[HACKERS] Reasoning behind LWLOCK_PADDED_SIZE/increase it to a full cacheline

Hi, Currently LWLOCK_PADDED_SIZE is defined as: /* * All the LWLock structs are allocated as an array in shared memory. * (LWLockIds are indexes into the array.) We force the array stride to * be a power of 2, which saves a few cycles in indexing, but more * importantly also ensures that indi

Re: [HACKERS] UTF8 national character data type support WIP patch and list of open issues.

On Fri, Sep 20, 2013 at 8:32 PM, MauMau wrote: >> I don't think that you'll be able to >> get consensus around that path on this mailing list. >> I agree that the fact we have both varchar and text feels like a wart. > > Is that right? I don't feel varchar/text case is a wart. I think text was >

[HACKERS] Re: output/security_label.source referring to abs_builddir instead of libdir

On Tue, Sep 17, 2013 at 07:04:14PM +0500, Hamid Quddus Akhtar wrote: > In make check, there are 4 shared libraries that are loaded for test cases > from the src/test/regress folder. Whereas, output of other libraries > contain @libdir@ tag, the output file for security_label (dumm_seclabel) > conta

Re: [HACKERS] pgbench progress report improvements - split 1

On Sun, Sep 22, 2013 at 08:44:08PM +0200, Fabien COELHO wrote: > pgbench: minor update of documentation & help message. > > Use NUM in help message for homogeneity with other options. The target > *start* time of the transaction is set by the stochastic process which is > doing the throttling (-

Re: [HACKERS] record identical operator

On Mon, Sep 23, 2013 at 3:45 PM, Stephen Frost wrote: > Robert, all, > > Skipping out on much of the side-discussion to try and drive at the > heart of this.. > > * Robert Haas (robertmh...@gmail.com) wrote: >> I would suggest that you read the referenced papers for details as to >> how the algori

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

On Fri, Sep 20, 2013 at 8:48 PM, Peter Geoghegan wrote: > On Tue, Sep 17, 2013 at 9:29 AM, Robert Haas wrote: >> On Sat, Sep 14, 2013 at 6:27 PM, Peter Geoghegan wrote: >>> Note that today there is no guarantee that the original waiter for a >>> duplicate-inserting xact to complete will be the f

Re: [HACKERS] record identical operator

Stephen Frost wrote: > I'm trying to explain that using that methodology is what landed > us in this situation to begin with. I'm trying to figure out what situation you think we're in. Seriously, if you could apply the patch and show one example that demonstrates what you see to be a problem, t

Re: [HACKERS] record identical operator

Robert, all, Skipping out on much of the side-discussion to try and drive at the heart of this.. * Robert Haas (robertmh...@gmail.com) wrote: > I would suggest that you read the referenced papers for details as to > how the algorithm works. To make a long story short, they do need to > keep trac

Re: [HACKERS] pgbench progress report improvements

On Sat, Sep 21, 2013 at 4:55 AM, Fabien COELHO wrote: >>> - Use progress option both under init & bench. >>> >>>Activate progress report by default, every 5 seconds. >>>When initializing, --quiet reverts to the old every 100,000 insertions >>>behavior... >> >> Patch (1): Change the d

Re: [HACKERS] gaussian distribution pgbench

> However this pattern induces stronger cache effects which are maybe not too realistic, > because neighboring keys in the middle are more likely to be chosen. I think that your opinion is right. However, in effect, it is a paseudo-benchmark, so that I think that such a simple mechanism is also n

Re: [HACKERS] gaussian distribution pgbench

> You had accidentally added to the CF In Progress. Oh, I had completely mistook this CF schedule :-) Maybe, Horiguchi-san is same situation... However, because of your moving, I become first submitter in next CF. Thank you for moving :-) -- Mitsumasa KONDO

Re: [HACKERS] record identical operator

On Mon, Sep 23, 2013 at 2:46 PM, Robert Haas wrote: > Anyway, that is exactly what Kevin is proposing to do here and, to be > clear, he's NOT proposing to use the binary-identical semantics to > identify the row to be updated. That will happen using the semantics > of whatever index the user choo

Re: [HACKERS] record identical operator

* Kevin Grittner (kgri...@ymail.com) wrote: > Unless we can tell whether there are any differences between two > versions of a row, we can't accurately generate the delta to drive > the incremental maintenance. This is predicated on the assumption that you simply generate the new view and then try

Re: [HACKERS] File_fdw documentation patch to clarify OPTIONS clause

On Mon, Sep 23, 2013 at 2:24 PM, Mike Blackwell wrote: > Thanks for the reply. I have no objections to clarifying the note. > Attached is a patch with the text you suggested. Committed, thanks. Per relatively-usual practice for doc clarifications, I back-patched this one release but not further

Re: [HACKERS] dynamic shared memory

On Mon, Sep 23, 2013 at 10:43:33AM +0530, Amit Kapila wrote: > On Mon, Sep 23, 2013 at 12:34 AM, Noah Misch wrote: > > On Sun, Sep 22, 2013 at 01:17:52PM +0530, Amit Kapila wrote: > >> #ifdef WIN32 > >> /* use CRLF line endings on Windows */ > >> _setmode(_fileno(fh), _O_TEXT); > >> #endif > > > >

Re: [HACKERS] record identical operator

Stephen Frost wrote: > Robert Haas (robertmh...@gmail.com) wrote: >> Now, the next project Kevin's going to work on, and that he was >> working on when he discovered this problem, is incremental >> maintenance: that is, allowing us to update the view *without* >> needing to rerun the entire query

Re: [HACKERS] record identical operator

On Mon, Sep 23, 2013 at 1:19 PM, Stephen Frost wrote: > So I've gathered and I'm not terribly surprised that it's broken. It > was unfortunate that we committed it as such, imv. I'm *not* convinced > that means we should build on that in a direction that doesn't appear to > be getting us any clo

Re: [HACKERS] File_fdw documentation patch to clarify OPTIONS clause

Robert, Thanks for the reply. I have no objections to clarifying the note. Attached is a patch with the text you suggested. Mike​ __ *Mike Blackwell | Technical Analyst, Distribution Services/Rollout Management | R

Re: [HACKERS] record identical operator

* Robert Haas (robertmh...@gmail.com) wrote: > It seems odd to me that you have such strong opinions about what is > and is not acceptable here given that you don't seem to familiar with > the current state of this work. That'd be because the arguments that I've been trying to make around this h

Re: [HACKERS] logical changeset generation v6

Andres Freund escribió: > On 2013-09-23 13:47:05 -0300, Alvaro Herrera wrote: > > I had proposed pg_recvlogical > > I still find it wierd/inconsistent to have: > * pg_receivexlog > * pg_recvlogical > binaries, even from the same source directory. Why once "pg_recv" and > once "pg_receive"? Well.

Re: [HACKERS] File_fdw documentation patch to clarify OPTIONS clause

On Fri, Sep 20, 2013 at 4:26 PM, Mike Blackwell wrote: > The file_fdw documentation for the OPTIONS clause references the COPY > command's documentation. In the case of COPY, the value for some options > (e.g. HEADER, OIDS, ...) is optional. While the file_fdw documentation > makes no mention of

Re: [HACKERS] FW: REVIEW: Allow formatting in log_line_prefix

On Fri, Sep 20, 2013 at 11:28 PM, David Rowley wrote:\ > I put the above results into the attached spreadsheet. On my intel i5 laptop > I'm seeing a slow down of about 1 second per million queries for the longer > log_line_prefix and about 1 second per 5 million queries with the shorter > log_line

Re: [HACKERS] record identical operator

On Fri, Sep 20, 2013 at 11:23 AM, Stephen Frost wrote: > Perhaps I'm assuming things are farther along than they are.. I was > assumed that 'incremental mat view' updates were actuallly 'partial'- > iow, that it keeps track of the rows in the mat view which are > impacted by the set of rows in th

Re: [HACKERS] logical changeset generation v6

On Mon, Sep 23, 2013 at 9:54 AM, Andres Freund wrote: > I still find it wierd/inconsistent to have: > * pg_receivexlog > * pg_recvlogical > binaries, even from the same source directory. Why once "pg_recv" and > once "pg_receive"? +1 -- Peter Geoghegan -- Sent via pgsql-hackers mailing list

Re: [HACKERS] logical changeset generation v6

Andres Freund escribió: > On 2013-09-20 14:15:23 -0700, Peter Geoghegan wrote: > > I have a little bit of feedback that I forgot to mention in my earlier > > reviews, because I thought it was too trivial then: something about > > the name pg_receivellog annoys me in a way that the name > > pg_recei

Re: [HACKERS] Freezing without write I/O

Just some notes, before I forget them again. On 2013-09-23 11:50:05 -0400, Robert Haas wrote: > On Fri, Sep 20, 2013 at 11:11 AM, Andres Freund > wrote: > > On 2013-09-20 16:47:24 +0200, Andres Freund wrote: > >> I think we should go through the various implementations and make sure > >> they ar

Re: [HACKERS] logical changeset generation v6

On 2013-09-23 13:47:05 -0300, Alvaro Herrera wrote: > Andres Freund escribió: > > On 2013-09-20 14:15:23 -0700, Peter Geoghegan wrote: > > > I have a little bit of feedback that I forgot to mention in my earlier > > > reviews, because I thought it was too trivial then: something about > > > the nam

Re: [HACKERS] PostgreSQL 9.3 beta breaks some extensions "make install"

Le lundi 23 septembre 2013 11:43:13 Andrew Dunstan a écrit : > On 09/23/2013 11:31 AM, Alvaro Herrera wrote: > > Marti Raudsepp wrote: > >> On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp wrote: > >>> Oh I see, indeed commit 6697aa2bc25c83b88d6165340348a31328c35de6 > >>> "Improve support for buil

Re: [HACKERS] logical changeset generation v6

On Mon, Sep 23, 2013 at 1:46 AM, Andres Freund wrote: > pg_receivelogical? Protest now or forever hold your peace. I was thinking pg_receiveloglog, but that works just as well. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your s

Re: [HACKERS] Freezing without write I/O

On 2013-09-23 11:50:05 -0400, Robert Haas wrote: > On Fri, Sep 20, 2013 at 11:11 AM, Andres Freund > wrote: > > On 2013-09-20 16:47:24 +0200, Andres Freund wrote: > >> I think we should go through the various implementations and make sure > >> they are actual compiler barriers and then change the

Re: [HACKERS] Freezing without write I/O

On Fri, Sep 20, 2013 at 11:11 AM, Andres Freund wrote: > On 2013-09-20 16:47:24 +0200, Andres Freund wrote: >> I think we should go through the various implementations and make sure >> they are actual compiler barriers and then change the documented policy. > > From a quick look > * S_UNLOCK for P

Re: [HACKERS] PostgreSQL 9.3 beta breaks some extensions "make install"

On 09/23/2013 11:31 AM, Alvaro Herrera wrote: Marti Raudsepp wrote: On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp wrote: Oh I see, indeed commit 6697aa2bc25c83b88d6165340348a31328c35de6 "Improve support for building PGXS modules with VPATH" fixes the problem and I see it's not present in RE

Re: [HACKERS] GIN improvements part 1: additional information

On Sun, Sep 15, 2013 at 01:14:45PM +0400, Alexander Korotkov wrote: > On Sat, Jun 29, 2013 at 12:56 PM, Heikki Linnakangas > wrote: > > There's a few open questions: > > 1. How are we going to handle pg_upgrade? It would be nice to be able to > read the old page format, or convert on

Re: [HACKERS] PostgreSQL 9.3 beta breaks some extensions "make install"

Marti Raudsepp wrote: > On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp wrote: > > Oh I see, indeed commit 6697aa2bc25c83b88d6165340348a31328c35de6 > > "Improve support for building PGXS modules with VPATH" fixes the > > problem and I see it's not present in REL9_3_0. > > > > Andrew and others, d

Re: [HACKERS] PostgreSQL 9.3 beta breaks some extensions "make install"

On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp wrote: > On Fri, Sep 13, 2013 at 6:42 PM, Cédric Villemain > wrote: >> Andrew is about to commit (well...I hope) a doc patch about that and also a >> little fix. >> Imho this is a bugfix so I hope it will be applyed in older branches. > > Oh I see

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

Daniel Farina escribió: > On Fri, Sep 20, 2013 at 1:11 AM, Daniel Farina wrote: > > I think the n-call underestimation propagation may not be quite precise for > > various detailed reasons (having to do with 'sticky' queries) and to make it > > precise is probably more work than it's worth. And,

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

I think the idea that we should consider a different way of handling tabular configuration data has merit. In fact, how much sense does it make to have these options (the ones for which this patch is being written) be GUCs in the first place? ALTER USER/DATABASE don't work for them, they can't be

Re: [HACKERS] Dump/Reload broken with relocatable extensions

On 09/19/2013 11:40 PM, Dimitri Fontaine wrote: > Vik Fearing writes: >> I don't know if this has been discussed before, a cursory search of the >> archives didn't turn up anything interesting. I perhaps didn't put in >> the right keywords. > For others not to spend too much time on this: it seem

Re: [HACKERS] Strange hanging bug in a simple milter

Vesa-Matti J Kari, I've now committed a fix for this issue. If you have opportunity to, it'd be great to pull down the latest git (for whichever supported branch you'd like) and give it a try. Otherwise, the fix should be out with our next round of point releases (which I expect will be

Re: [HACKERS] pgbench progress report improvements - split 3

Dear Peter, Split 3 of the initial submission, which actually deal with data measured and reported on stderr under various options. It seems this patch doesn't apply. Does it need the first two applied first? Oops. Indeed. The patch is fully independent of the two others. It was generated

Re: [HACKERS] all_visible replay aborting due to uninitialized pages

Andres Freund wrote: >On 2013-09-23 14:41:16 +0300, Heikki Linnakangas wrote: >> (spotted this while working on a patch, and ran into the assertion on >crash >> recovery) > >You got the assertion failure about CritSectionCount during recovery? >If so, I do not understand, that code shouldn't be ex

Re: [HACKERS] all_visible replay aborting due to uninitialized pages

On 2013-09-23 14:41:16 +0300, Heikki Linnakangas wrote: > On 06.06.2013 17:22, Robert Haas wrote: > >On Thu, May 30, 2013 at 2:29 AM, Andres Freund > >wrote: > >>>Yeah, I think it's fine. The patch also looks fine, although I think > >>>the comments could use a bit of tidying. I guess we need t

Re: [HACKERS] pgbench progress report improvements - split 3

On 9/22/13 2:58 PM, Fabien wrote: > Split 3 of the initial submission, which actually deal with data > measured and reported on stderr under various options. It seems this patch doesn't apply. Does it need the first two applied first? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postg

Re: [HACKERS] all_visible replay aborting due to uninitialized pages

On 06.06.2013 17:22, Robert Haas wrote: On Thu, May 30, 2013 at 2:29 AM, Andres Freund wrote: Yeah, I think it's fine. The patch also looks fine, although I think the comments could use a bit of tidying. I guess we need to back-patch this all the way back to 8.4? It will require some adjustm

Re: [HACKERS] Assertions in PL/PgSQL

On 23 September 2013 14:33, Pavel Stehule wrote: > > > > 2013/9/23 Amit Khandekar > >> >> >> >> On 23 September 2013 10:10, Pavel Stehule wrote: >> >>> >>> >>> >>> 2013/9/22 Jaime Casanova >>> El 21/09/2013 17:16, "Jaime Casanova" escribió: > > On Fri, Sep 20, 2013 at

Re: [HACKERS] Assertions in PL/PgSQL

2013/9/23 Marko Tiikkaja > On 9/23/13 11:12 AM, I wrote: > >> On 9/23/13 11:01 AM, Amit Khandekar wrote: >> >>> The assert levels sound a bit like a user might be confused by these >>> levels >>> being present at both places: In the RAISE syntax itself, and the assert >>> GUC level. But I like t

Re: [HACKERS] Assertions in PL/PgSQL

On 9/23/13 11:12 AM, I wrote: On 9/23/13 11:01 AM, Amit Khandekar wrote: The assert levels sound a bit like a user might be confused by these levels being present at both places: In the RAISE syntax itself, and the assert GUC level. But I like the syntax. How about keeping the ASSERT keyword op

Re: [HACKERS] Assertions in PL/PgSQL

On 9/23/13 11:01 AM, Amit Khandekar wrote: The assert levels sound a bit like a user might be confused by these levels being present at both places: In the RAISE syntax itself, and the assert GUC level. But I like the syntax. How about keeping the ASSERT keyword optional ? When we have WHEN, we

Re: [HACKERS] Assertions in PL/PgSQL

2013/9/23 Andres Freund > On 2013-09-23 11:00:50 +0200, Marko Tiikkaja wrote: > > On 9/23/13 10:50 AM, I wrote: > > >On 9/23/13 6:40 AM, Pavel Stehule wrote: > > >>After days I am thinking so it can be a good solution > > >> > > >>syntax - enhanced current RAISE > > >> > > >>RAISE ASSERT WHEN boo

Re: [HACKERS] Assertions in PL/PgSQL

2013/9/23 Marko Tiikkaja > On 9/23/13 10:50 AM, I wrote: > >> On 9/23/13 6:40 AM, Pavel Stehule wrote: >> >>> After days I am thinking so it can be a good solution >>> >>> syntax - enhanced current RAISE >>> >>> RAISE ASSERT WHEN boolean expression >>> >>> RAISE ASSERT 'some message' WHEN express

Re: [HACKERS] Assertions in PL/PgSQL

2013/9/23 Amit Khandekar > > > > On 23 September 2013 10:10, Pavel Stehule wrote: > >> >> >> >> 2013/9/22 Jaime Casanova >> >>> >>> El 21/09/2013 17:16, "Jaime Casanova" escribió: >>> >>> > >>> > On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja wrote: >>> > > On 9/20/13 12:09 PM, Amit Khandeka

Re: [HACKERS] Assertions in PL/PgSQL

On 2013-09-23 11:00:50 +0200, Marko Tiikkaja wrote: > On 9/23/13 10:50 AM, I wrote: > >On 9/23/13 6:40 AM, Pavel Stehule wrote: > >>After days I am thinking so it can be a good solution > >> > >>syntax - enhanced current RAISE > >> > >>RAISE ASSERT WHEN boolean expression > >> > >>RAISE ASSERT 'som

Re: [HACKERS] Assertions in PL/PgSQL

On 23 September 2013 10:10, Pavel Stehule wrote: > > > > 2013/9/22 Jaime Casanova > >> >> El 21/09/2013 17:16, "Jaime Casanova" escribió: >> >> > >> > On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja wrote: >> > > On 9/20/13 12:09 PM, Amit Khandekar wrote: >> > >> >> > >> On 16 September 2013 0

Re: [HACKERS] Assertions in PL/PgSQL

On 9/23/13 10:50 AM, I wrote: On 9/23/13 6:40 AM, Pavel Stehule wrote: After days I am thinking so it can be a good solution syntax - enhanced current RAISE RAISE ASSERT WHEN boolean expression RAISE ASSERT 'some message' WHEN expression It looks like I'm losing this battle, but this syntax

Re: [HACKERS] Assertions in PL/PgSQL

2013/9/23 Marko Tiikkaja > On 9/23/13 6:40 AM, Pavel Stehule wrote: > >> After days I am thinking so it can be a good solution >> >> syntax - enhanced current RAISE >> >> RAISE ASSERT WHEN boolean expression >> >> RAISE ASSERT 'some message' WHEN expression >> > > It looks like I'm losing this ba

Re: [HACKERS] Assertions in PL/PgSQL

On 9/23/13 6:40 AM, Pavel Stehule wrote: After days I am thinking so it can be a good solution syntax - enhanced current RAISE RAISE ASSERT WHEN boolean expression RAISE ASSERT 'some message' WHEN expression It looks like I'm losing this battle, but this syntax isn't too bad. and we can ha

Re: [HACKERS] logical changeset generation v6

On 2013-09-20 14:15:23 -0700, Peter Geoghegan wrote: > I have a little bit of feedback that I forgot to mention in my earlier > reviews, because I thought it was too trivial then: something about > the name pg_receivellog annoys me in a way that the name > pg_receivexlog does not. Specifically, it

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

> > I forgot about removal of the relevant SGML, amended here in v6. Thank you for this! i did a quick test with following steps: 1. Applied v6 patch 2. make and make install on pg_stat_statements; 3. Restarted Postgres with pg_stat_statements loaded with pg_stat_statements.max = 4 4. Dropped and