Re: Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

2014-01-16 22:13 keltezéssel, Alvaro Herrera írta: Alvaro Herrera escribió: Boszormenyi Zoltan escribió: All patches are attached again for completeness. Thanks. I pushed a commit comprising patches 09 through 14. Now also pushed 15 to 17. Thanks very much. -- Sent via pgsql-hackers ma

Re: [HACKERS] ECPG FETCH readahead, was: Re: ECPG fixes

2014-01-16 23:42 keltezéssel, Alvaro Herrera írta: Boszormenyi Zoltan escribió: Rebased patches after the regression test and other details were fixed in the infrastructure part. This thread started in 2010, and various pieces have been applied already and some others have changed in nature. W

[HACKERS] Funny representation in pg_stat_statements.query.

Hello, I noticed that pg_stat_statements.query can have funny values. | =# select pg_stat_statements_reset(); | =# select current_timestamp(0); | | =# select query from pg_stat_statements; |query | | select ?(0); | select pg_s

[HACKERS] improve the help message about psql -F

in the offical doc,-F say： > Use separator as the field separator for unaligned output. but in the psql --help,-F say: > set field separator (default: "|") if user don't read the offical doc carefully,he can use: psql -F , -c 'select ...' But can't get what he want. It is a bad user Experie

Re: [HACKERS] plpgsql.warn_shadow

Hello After some thinking I don't think so this design is not good. It changing a working with exception (error) levels - and it is not consistent with other PostgreSQL parts. A benefit is less than not clean configuration. Better to solve similar issues via specialized plpgsql extensions or try

Re: [HACKERS] plpgsql.warn_shadow

On 1/17/14 11:26 AM, Pavel Stehule wrote: After some thinking I don't think so this design is not good. It changing a working with exception (error) levels - and it is not consistent with other PostgreSQL parts. A benefit is less than not clean configuration. Better to solve similar issues via

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

On Wed, Jan 15, 2014 at 10:47 AM, Alexander Korotkov wrote: > On Wed, Jan 15, 2014 at 5:17 AM, Tomas Vondra wrote: > >> On 14.1.2014 00:38, Tomas Vondra wrote: >> > On 13.1.2014 18:07, Alexander Korotkov wrote: >> >> On Sat, Jan 11, 2014 at 6:15 AM, Tomas Vondra > >> > wrote

Re: [HACKERS] [PATCH] pgcrypto: implement gen_random_uuid

2014/1/9 Oskari Saarenmaa : > The only useful feature of the uuid-ossp module in my opinion is the > uuid_generate_v4 function and as uuid-ossp is more or less abandonware > people have had trouble building and installing it. This patch implements > an alternative uuid v4 generation function in pg

Re: [HACKERS] [PATCH] Fix double-inclusion of pg_config_os.h when building extensions with Visual Studio

On Sat, Jan 11, 2014 at 8:57 AM, Craig Ringer wrote: > Hi all > > Related to the earlier comments about building extensions on Windows, I > just noticed that we don't treat "WINDLL" as equivalent to "WIN32", and > "WIN32" isn't set in a Visual Studio DLL project. > > We should actually be testing

Re: [HACKERS] Feature request: Logging SSL connections

On Sun, Dec 8, 2013 at 10:27 AM, Marko Kreen wrote: > On Fri, Dec 06, 2013 at 02:53:27PM +0100, Dr. Andreas Kunert wrote: > > >>Anything else missing? > > > > > >Functionally it's fine now, but I see few style problems: > > > > > >- "if (port->ssl > 0)" is wrong, ->ssl is pointer. So use just >

Re: [HACKERS] patch: option --if-exists for pg_dump

Hello 2014/1/16 Jeevan Chalke > Hi Pavel, > > I have reviewed the patch and here are my concerns and notes: > > POSITIVES: > --- > 1. Patch applies with some white-space errors. > 2. make / make install / make check is smooth. No issues as such. > 3. Feature looks good as well. > 4. NO concern

[HACKERS] wal_buffers = -1

Is there any real use-case for not setting wal_buffers to -1 these days? Or should we just remove it and use the -1 behaviour at all times? IIRC we discussed not keeping it at all when the autotune behavior was introduced, but said we wanted to keep it "just in case". If we're not ready to remove

Re: [HACKERS] wal_buffers = -1

On 17 January 2014 13:01, Magnus Hagander wrote: > Is there any real use-case for not setting wal_buffers to -1 these days? > > Or should we just remove it and use the -1 behaviour at all times? > > IIRC we discussed not keeping it at all when the autotune behavior was > introduced, but said we wa

Re: [HACKERS] wal_buffers = -1

Hi, On 2014-01-17 14:01:56 +0100, Magnus Hagander wrote: > Is there any real use-case for not setting wal_buffers to -1 these days? > > Or should we just remove it and use the -1 behaviour at all times? I have seen improvements by setting it larger than the max -1 one value. Also, for some workl

Re: [HACKERS] wal_buffers = -1

On Fri, Jan 17, 2014 at 2:07 PM, Thom Brown wrote: > On 17 January 2014 13:01, Magnus Hagander wrote: > > Is there any real use-case for not setting wal_buffers to -1 these days? > > > > Or should we just remove it and use the -1 behaviour at all times? > > > > IIRC we discussed not keeping it a

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Thu, Jan 16, 2014 at 03:58:56PM -0800, Jeff Janes wrote: > On Thu, Jan 16, 2014 at 3:23 PM, Dave Chinner wrote: > > > On Wed, Jan 15, 2014 at 06:14:18PM -0600, Jim Nasby wrote: > > > On 1/15/14, 12:00 AM, Claudio Freire wrote: > > > >My completely unproven theory is that swapping is overwhelme

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Wed, Jan 15, 2014 at 06:14:18PM -0600, Jim Nasby wrote: > On 1/15/14, 12:00 AM, Claudio Freire wrote: > >My completely unproven theory is that swapping is overwhelmed by > >near-misses. Ie: a process touches a page, and before it's > >actually swapped in, another process touches it too, blocking

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Thu, Jan 16, 2014 at 08:48:24PM -0500, Robert Haas wrote: > On Thu, Jan 16, 2014 at 7:31 PM, Dave Chinner wrote: > > But there's something here that I'm not getting - you're talking > > about a data set that you want ot keep cache resident that is at > > least an order of magnitude larger than

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Thu, 16 Jan 2014 20:48:24 -0500 Robert Haas wrote: > On Thu, Jan 16, 2014 at 7:31 PM, Dave Chinner wrote: > > But there's something here that I'm not getting - you're talking > > about a data set that you want ot keep cache resident that is at > > least an order of magnitude larger than the c

Re: [HACKERS] wal_buffers = -1

On 17 January 2014 13:20, Magnus Hagander wrote: > On Fri, Jan 17, 2014 at 2:07 PM, Thom Brown wrote: >> >> On 17 January 2014 13:01, Magnus Hagander wrote: >> > Is there any real use-case for not setting wal_buffers to -1 these days? >> > >> > Or should we just remove it and use the -1 behaviou

Re: [HACKERS] plpgsql.consistent_into

On Wed, Jan 15, 2014 at 8:23 AM, Jim Nasby wrote: > Do we actually support = right now? We already support > > v_field := field FROM table ... ; > > and I think it's a bad idea to have different meaning for = and :=. That was already discussed before. Yes, we support both = and := and they have e

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Fri, Jan 17, 2014 at 7:34 AM, Jeff Layton wrote: > So this says to me that the WAL is a place where DIO should really be > reconsidered. It's mostly sequential writes that need to hit the disk > ASAP, and you need to know that they have hit the disk before you can > proceed with other operation

Re: [HACKERS] WAL Rate Limiting

On Thu, Jan 16, 2014 at 10:56 AM, Andres Freund wrote: > That'd be most places doing XLogInsert() if you want to be > consistent. Each needing to be analyzed whether we're blocking important > resources, determining where in the callstack we can do the > CHECK_FOR_WAL_BUDGET(). And doing that pro

Re: [HACKERS] WAL Rate Limiting

On 2014-01-17 09:04:54 -0500, Robert Haas wrote: > That having been said, I bet it could be done at the tail of > XLogInsert(). if there are cases where that's not desirable, then add > macros HOLDOFF_WAL_THROTTLING() and RESUME_WAL_THROTTLING() that bump > a counter up and down. When the counter

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

On Fri, Jan 17, 2014 at 3:05 PM, Florian Pflug wrote: > I had some more fun with this, the result is v2.5 of the patch (attached). > Changes are explained below. > > Looks like you've been busy on this! Thank you for implementing all the changes you talked about. I've now started working the 2.5

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

On Jan17, 2014, at 15:14 , David Rowley wrote: > If you make any more changes would it be possible for you to base them on the > attached patch instead of the last one you sent? Sure! The only reason I didn't rebase my last patch onto yours was that having the numeric stuff in there meant poten

Re: [HACKERS] WAL Rate Limiting

Andres Freund writes: > On 2014-01-17 09:04:54 -0500, Robert Haas wrote: >> That having been said, I bet it could be done at the tail of >> XLogInsert(). > I don't think there are many locations where this would be ok. Sleeping > while holding exclusive buffer locks? Quite possibly inside a criti

Re: [HACKERS] WAL Rate Limiting

On 16 January 2014 17:20, Simon Riggs wrote: > Thank you everyone for responding so positively to this proposal. It > is something many users have complained about. > > In time, I think we might want both WAL Rate Limiting and I/O Rate > Limiting. IMHO I/O rate limiting is harder and so this prop

Re: [HACKERS] WAL Rate Limiting

On 01/17/2014 05:20 PM, Simon Riggs wrote: + if (RelationNeedsWAL(indexrel)) + CHECK_FOR_WAL_BUDGET(); I don't think we need the RelationNeedsWAL tests. If the relation is not WAL-logged, you won't write much WAL, so you should easily stay under the limit. And CHECK_FOR_WA

Re: [HACKERS] WAL Rate Limiting

It occurs to me that this is very similar to the method I proposed in June to enforce a hard limit on WAL usage, to avoid PANIC caused by running out of disk space when writing WAL: http://www.postgresql.org/message-id/51b095fe.6050...@vmware.com Enforcing a global limit needs more book-keepin

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Thu, Jan 16, 2014 at 04:30:59PM -0800, Jeff Janes wrote: > On Wed, Jan 15, 2014 at 2:08 AM, Mel Gorman wrote: > > > On Tue, Jan 14, 2014 at 09:30:19AM -0800, Jeff Janes wrote: > > > > > > > > That could be something we look at. There are cases buried deep in the > > > > VM where pages get shuf

Re: [HACKERS] Funny representation in pg_stat_statements.query.

Kyotaro HORIGUCHI writes: > Hello, I noticed that pg_stat_statements.query can have funny values. I don't think that's an acceptable reason for lobotomizing the parser's ability to print error cursors, which is what your first patch does (and without even any documentation that would keep someone

Re: [HACKERS] Feature request: Logging SSL connections

Magnus Hagander writes: > Applied, thanks! Minor bikeshedding: the messages would read better, to my eye, as "user=%s database=%s SSL enabled (protocol=%s, cipher=%s)" Putting "enabled" where it is requires extra mental gymnastics on the part of the reader. And why the random change between "=

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On 01/17/2014 06:40 AM, Dave Chinner wrote: > On Thu, Jan 16, 2014 at 08:48:24PM -0500, Robert Haas wrote: >> On Thu, Jan 16, 2014 at 7:31 PM, Dave Chinner wrote: >>> But there's something here that I'm not getting - you're talking >>> about a data set that you want ot keep cache resident that is

[HACKERS] currawong is not a happy animal

I've not been able to build master for a few days now on visual studios due some problems in the new test_shm_mq contrib module. I'm not too familiar with how the visual studio project files are generated so I've not yet managed to come up with a fix just yet. However I have attached a fix for the

[HACKERS] Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17)

On Wed, Jan 15, 2014 at 02:14:08PM +, Mel Gorman wrote: > > One assumption would be that Postgres is perfectly happy with the current > > kernel behaviour in which case our discussion here is done. > > It has been demonstrated that this statement was farcical. The thread is > massive just fro

Re: [HACKERS] currawong is not a happy animal

On 01/17/2014 11:26 AM, David Rowley wrote: I've not been able to build master for a few days now on visual studios due some problems in the new test_shm_mq contrib module. I'm not too familiar with how the visual studio project files are generated so I've not yet managed to come up with a fix

Re: [HACKERS] [PATCH] Filter error log statements by sqlstate

Oskari Saarenmaa writes: > 17.01.2014 00:13, Tom Lane kirjoitti: >> I find it hard to follow exactly what the use-case for this is; could >> you make a defense of why we should carry a feature like this? > I usually run PG with log_min_messages = warning and > log_min_error_statement = error to

Re: [HACKERS] Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17)

Hi Mel, On 2014-01-17 16:31:48 +, Mel Gorman wrote: > Direct IO, buffered IO, double buffering and wishlists > -- >3. Hint that a page should be dropped immediately when IO completes. > There is already something like this buried in

Re: [HACKERS] currawong is not a happy animal

On Fri, Jan 17, 2014 at 5:51 PM, Andrew Dunstan wrote: > > On 01/17/2014 11:26 AM, David Rowley wrote: > >> I've not been able to build master for a few days now on visual studios >> due some problems in the new test_shm_mq contrib module. >> I'm not too familiar with how the visual studio projec

Re: [HACKERS] currawong is not a happy animal

On 01/17/2014 11:51 AM, Andrew Dunstan wrote: On 01/17/2014 11:26 AM, David Rowley wrote: I've not been able to build master for a few days now on visual studios due some problems in the new test_shm_mq contrib module. I'm not too familiar with how the visual studio project files are generate

Re: [HACKERS] currawong is not a happy animal

Andrew Dunstan writes: > It looks like what we need to fix the immediate problem is to mark > set_latch_on_sigusr1 with PGDLLIMPORT. Is that the only one of these > symbols we might need to make visible? We've generally relied on the buildfarm to cue us to add PGDLLIMPORT. Add that one and see

[HACKERS] Minor improvements to sslinfo contrib module

Please find attached the patch that fixes a couple of comments, and adds 'static' qualifier to functions that are not used anywhere else in the code base. Best regards, -- Gurjeet Singh http://gurjeet.singh.im/ EDB www.EnterpriseDB.com diff --git a/contrib/sslinfo/s

Re: [HACKERS] currawong is not a happy animal

On 01/17/2014 12:43 PM, Tom Lane wrote: Andrew Dunstan writes: It looks like what we need to fix the immediate problem is to mark set_latch_on_sigusr1 with PGDLLIMPORT. Is that the only one of these symbols we might need to make visible? We've generally relied on the buildfarm to cue us to ad

Re: [HACKERS] currawong is not a happy animal

On Sat, Jan 18, 2014 at 6:50 AM, Andrew Dunstan wrote: > > On 01/17/2014 12:43 PM, Tom Lane wrote: > >> Andrew Dunstan writes: >> >>> It looks like what we need to fix the immediate problem is to mark >>> set_latch_on_sigusr1 with PGDLLIMPORT. Is that the only one of these >>> symbols we might n

Re: [Lsf-pc] [HACKERS] Re: Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17)

On Fri, Jan 17, 2014 at 06:14:37PM +0100, Andres Freund wrote: > Hi Mel, > > On 2014-01-17 16:31:48 +, Mel Gorman wrote: > > Direct IO, buffered IO, double buffering and wishlists > > -- > >3. Hint that a page should be dropped immediatel

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

On 01/17/2014 01:05 PM, Alexander Korotkov wrote: Seems to be fixed in the attached version of patch. Another improvement in this version: only left-most segments and further are re-encoded. Left part of page are left untouched. I'm looking into this now. A few quick notes: * Even when you don

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

On Fri, Jan 17, 2014 at 10:38 PM, Heikki Linnakangas < hlinnakan...@vmware.com> wrote: > On 01/17/2014 01:05 PM, Alexander Korotkov wrote: > >> Seems to be fixed in the attached version of patch. >> Another improvement in this version: only left-most segments and further >> are re-encoded. Left pa

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

Andres Freund writes: > [ 0001-Add-support-for-printing-Size-arguments-to-elog-erep.patch ] I think this approach is fundamentally broken, because it can't reasonably cope with any case more complicated than "%zu" or "%zd". While it's arguable that we can get along without the ability to specify

Re: [HACKERS] currawong is not a happy animal

On 01/17/2014 12:55 PM, David Rowley wrote: On Sat, Jan 18, 2014 at 6:50 AM, Andrew Dunstan > wrote: On 01/17/2014 12:43 PM, Tom Lane wrote: Andrew Dunstan mailto:and...@dunslane.net>> writes: It looks like what we need to fix the immediate

Re: [Lsf-pc] [HACKERS] Re: Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17)

Mel, So we have a few interested parties. What do we need to do to set up the Collab session? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mai

Re: [HACKERS] currawong is not a happy animal

Andrew Dunstan writes: > Not quite out of the woods yet. We're getting this regression failure on > Windows/MSVC (see > ): >SELECT test_shm_mq(32768, (select string_agg(chr(32+(random()*96)::int), > '

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

I wrote: > Meh. This isn't needed if we do what I suggest above, but in any case > I don't approve of removing the existing [U]INT64_FORMAT macros. > That breaks code that doesn't need to get broken, probably including > third-party modules. After looking more closely I see you didn't actually *r

Re: [HACKERS] wal_buffers = -1

On Fri, Jan 17, 2014 at 8:20 AM, Magnus Hagander wrote: >> Robert Haas reported that setting it to 32MB can yield a considerable >> performance benefit: >> >> http://www.postgresql.org/message-id/CA+TgmobgMv_aaakLoasBt=5iYfi=kdcOUz0X9TdYe0c2SZ=2...@mail.gmail.com > > In that case, sholdn't the aut

Re: [HACKERS] proposal, patch: allow multiple plpgsql plugins

2014/1/16 Marko Tiikkaja > Hi Pavel, > > First of all, thanks for working on this! > > > On 1/12/14, 8:58 PM, Pavel Stehule wrote: > >> I still not happy with plugin_info - it is only per plugin now and should >> be per plugin and per function. >> > > I'm not sure I understand the point of plugin

Re: [HACKERS] [v9.4] row level security

On 12/13/13 11:40 PM, Craig Ringer wrote: You may want to check out the updated writable security-barrier views patch. http://www.postgresql.org/message-id/52ab112b.6020...@2ndquadrant.com It may offer a path forward for the CF submission for RLS, letting us get rid of the var/attr fiddling tha

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

On Fri, Jan 17, 2014 at 3:05 PM, Florian Pflug wrote: > > I've now shuffled things around so that we can use inverse transition > functions > even if only some aggregates provide them, and to allow inverse transition > functions to force a restart by returning NULL. The rules regarding NULL > han

Re: [HACKERS] [BUGS] surprising to_timestamp behavior

Jeevan Chalke writes: > Attached patch which fixes this issue. > I have just tweaked the code around ignoring spaces in DCH_from_char() > function. > Adding to CommitFest 2014-01 (Open). I went to review this, and found that there's not actually a patch attached ... reg

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On Wed, Jan 15, 2014 at 5:14 PM, Simon Riggs wrote: > We already know that HOT is ineffective in areas of high contention > (previous thread by me). Prior experience was that smaller tables > didn't show much apparent benefit from using HOT either; its > effectiveness was limited to medium and lar

Re: [HACKERS] currawong is not a happy animal

Tom Lane escribió: > Andrew Dunstan writes: > > Not quite out of the woods yet. We're getting this regression failure on > > Windows/MSVC (see > > ): > > >SELECT test_shm_mq(32768, (select string_agg(c

Re: [HACKERS] currawong is not a happy animal

On 01/17/2014 02:54 PM, Alvaro Herrera wrote: Tom Lane escribió: Andrew Dunstan writes: Not quite out of the woods yet. We're getting this regression failure on Windows/MSVC (see ): SELECT test_shm_m

Re: [HACKERS] currawong is not a happy animal

Alvaro Herrera writes: > Tom Lane escribió: >> I seem to recall that we've previously found that you have to write >> MAXALIGN(offsetof(shm_mq, mq_ring[0])) + MAXIMUM_ALIGNOF; >> to keep MSVC happy with a reference to an array member in offsetof. > Hmm, this seems to contradict what's documented

Re: [HACKERS] currawong is not a happy animal

Andrew Dunstan writes: > On 01/17/2014 02:54 PM, Alvaro Herrera wrote: >> Hmm, this seems to contradict what's documented at the definition of >> FLEXIBLE_ARRAY_MEMBER: > Well, there's a bunch of these in the source: Yeah, I did the same grep and noted the same thing --- but on second look, I th

Re: [HACKERS] currawong is not a happy animal

Andrew Dunstan escribió: > > On 01/17/2014 02:54 PM, Alvaro Herrera wrote: > >Hmm, this seems to contradict what's documented at the definition of > >FLEXIBLE_ARRAY_MEMBER: > Well, there's a bunch of these in the source: AFAICT these are all defined with non-zero, non-empty array sizes, not FLE

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On 1/17/14 10:37 AM, Mel Gorman wrote: There is not an easy way to tell. To be 100%, it would require an instrumentation patch or a systemtap script to detect when a particular page is being written back and track the context. There are approximations though. Monitor nr_dirty pages over time.

Re: [HACKERS] [PATCH] pgcrypto: implement gen_random_uuid

Emre Hasegeli writes: > 2014/1/9 Oskari Saarenmaa : >> The only useful feature of the uuid-ossp module in my opinion is the >> uuid_generate_v4 function and as uuid-ossp is more or less abandonware >> people have had trouble building and installing it. This patch implements >> an alternative uuid

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

On Jan17, 2014, at 20:34 , David Rowley wrote: > On Fri, Jan 17, 2014 at 3:05 PM, Florian Pflug wrote: > >> I've now shuffled things around so that we can use inverse transition >> functions >> even if only some aggregates provide them, and to allow inverse transition >> functions to force a re

Re: [HACKERS] currawong is not a happy animal

On 01/17/2014 03:15 PM, Tom Lane wrote: The other possibility I was contemplating is that "export a const variable" doesn't actually work for some reason. We're not in the habit of doing that elsewhere, so I don't find that theory outlandish. Perhaps it could be fixed by adding PGDLLIMPORT to

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

On Sat, Jan 18, 2014 at 10:17 AM, Florian Pflug wrote: > On Jan17, 2014, at 20:34 , David Rowley wrote: > > On Fri, Jan 17, 2014 at 3:05 PM, Florian Pflug wrote: > > > >> I've now shuffled things around so that we can use inverse transition > functions > >> even if only some aggregates provide

Re: [HACKERS] Triggers on foreign tables

On Tue, Jan 07, 2014 at 12:11:28PM +0100, Ronan Dunklau wrote: > Since the last discussion about it > (http://www.postgresql.org/message-id/cadyhksugp6ojb1pybtimop3s5fg_yokguto-7rbcltnvaj5...@mail.gmail.com), > I > finally managed to implement row triggers for foreign tables. > For statement-lev

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

On Sat, Jan 18, 2014 at 10:42 AM, David Rowley wrote: > >> You could do better than that - the numeric problem amounts to tracking >> the maximum >> scale AFAICS, so it'd be sufficient to restart if we remove a value whose >> scale equals >> the current maximum. But if we do SUM(numeric) at all,

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

David Rowley writes: > I just thought that my idea was good enough and very cheap too, won't all > numerics that are actually stored in a column have the same scale anyway? No; unconstrained numeric columns (ie, if you just say "numeric") don't force their contents to any particular scale. It mi

[HACKERS] Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17)

On Fri, Jan 17, 2014 at 9:14 AM, Andres Freund wrote: > The scheme that'd allow us is the following: > When postgres reads a data page, it will continue to first look up the > page in its shared buffers, if it's not there, it will perform a page > cache backed read, but instruct that read to immed

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

Hi, On 2014-01-17 13:50:08 -0500, Tom Lane wrote: > I think a better solution approach is to teach our src/port/snprintf.c > about the z flag, then extend configure's checking to force use of our > snprintf if the platform's version doesn't handle z. While it might be > objected that this creates

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

On 2014-01-17 14:18:55 -0500, Tom Lane wrote: > I wrote: > > Meh. This isn't needed if we do what I suggest above, but in any case > > I don't approve of removing the existing [U]INT64_FORMAT macros. > > That breaks code that doesn't need to get broken, probably including > > third-party modules.

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

On 2014-01-17 13:50:08 -0500, Tom Lane wrote: > Andres Freund writes: > > [ 0001-Add-support-for-printing-Size-arguments-to-elog-erep.patch ] > > I think this approach is fundamentally broken, because it can't reasonably > cope with any case more complicated than "%zu" or "%zd". While it's > arg

[HACKERS] Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (summary v2 2014-1-17)

On 2014-01-17 16:18:49 -0800, Greg Stark wrote: > On Fri, Jan 17, 2014 at 9:14 AM, Andres Freund wrote: > > The scheme that'd allow us is the following: > > When postgres reads a data page, it will continue to first look up the > > page in its shared buffers, if it's not there, it will perform a p

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

Andres Freund writes: > On 2014-01-17 13:50:08 -0500, Tom Lane wrote: >> I think a better solution approach is to teach our src/port/snprintf.c >> about the z flag, then extend configure's checking to force use of our >> snprintf if the platform's version doesn't handle z. > Hm. I had thought abo

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

First, I've go the feeling that I should somehow update the commitfest app, but I don't really know in which way. Should I put myself in as a reviewer, or as a second author? Or neither? Suggestions welcome... On Jan17, 2014, at 23:34 , David Rowley wrote: > The test turned out to become: >

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

Andres Freund writes: > On 2014-01-17 13:50:08 -0500, Tom Lane wrote: >> I think this approach is fundamentally broken, because it can't reasonably >> cope with any case more complicated than "%zu" or "%zd". > Am I just too tired, or am I not getting how INT64_FORMAT currently > allows the argume

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

I wrote: > Andres Freund writes: >> On 2014-01-17 13:50:08 -0500, Tom Lane wrote: >>> I think this approach is fundamentally broken, because it can't reasonably >>> cope with any case more complicated than "%zu" or "%zd". >> Am I just too tired, or am I not getting how INT64_FORMAT currently >> a

Re: [HACKERS] Minor improvements to sslinfo contrib module

Gurjeet Singh writes: > Please find attached the patch that fixes a couple of comments, and adds > 'static' qualifier to functions that are not used anywhere else in the code > base. Committed, with the trivial fix that the function definitions have to be marked static too. (gcc doesn't complain

Re: [HACKERS] array_length(anyarray)

On 1/12/14, 5:53 AM, I wrote: On 1/9/14, 2:57 PM, Dean Rasheed wrote: How it should behave for multi-dimensional arrays is less clear, but I'd argue that it should return the total number of elements, i.e. cardinality('{{1,2},{3,4}}'::int[][]) = 4. That would make it consistent with the choices

Re: [HACKERS] [PATCH] Make various variables read-only (const)

Oskari Saarenmaa writes: > On Sun, Dec 22, 2013 at 09:43:57PM -0500, Robert Haas wrote: >> - Why change the API of transformRelOptions()? > The comment was changed to reflect the new API, I modified > transformRelOptions to only accept a single valid namespace to make things > simpler in the call

Re: [HACKERS] 9.3.2 Client-only installation per docs fails creating directory.

On Thu, 2014-01-16 at 15:59 -0600, Mike Blackwell wrote: > Per the docs (15.4 Installation Procedure, Client-only installation), > after running make, the following should work: > > > gmake -C src/bin install > gmake -C src/include install > gmake -C src/interfaces install > gmake -C doc install

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

On Sat, Jan 18, 2014 at 2:20 PM, Florian Pflug wrote: > First, I've go the feeling that I should somehow update the commitfest app, > but I don't really know in which way. Should I put myself in as a reviewer, > or as a second author? Or neither? Suggestions welcome... > > We I guess you're both

Re: [HACKERS] [PATCH] Make various variables read-only (const)

I wrote: > However, I believe this code was Alvaro's to begin with, so I'd be > interested in his opinion on how important it is for transformRelOptions > to allow more than one namespace per call. > Actually, I'm kind of wondering why the code has a concept of namespaces > at all, given the fact

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

On Sat, Jan 18, 2014 at 6:15 PM, David Rowley wrote: > On Sat, Jan 18, 2014 at 2:20 PM, Florian Pflug wrote: > >> * Don't we need to check for volatile function in the filter expression >> too? >> > >> > I did manual testing on this before and the volatility test for the > aggregate arguments se

Re: [HACKERS] currawong is not a happy animal

On Sat, Jan 18, 2014 at 2:48 AM, Andrew Dunstan wrote: > > On 01/17/2014 03:15 PM, Tom Lane wrote: > >> The other possibility I was contemplating is that "export a const >> variable" doesn't actually work for some reason. We're not in the habit >> of doing that elsewhere, so I don't find that the