Re: [HACKERS] Sending out a request for more buildfarm animals?

On 05/04/2014 11:13 PM, Magnus Hagander wrote: On Sun, May 4, 2014 at 9:35 PM, Josh Berkus wrote: Architecture wise there's no coverage for: * some ARM architecture varians I could run a buildfarm animal on a Raspberry Pi if the Postgres community will replace my flash cards as they burn out

Re: [HACKERS] Per table autovacuum vacuum cost limit behaviour strange

On 05/05/14 15:22, Amit Kapila wrote: Here what I could understand is that sum of cost_limit for all autovacuum workers should never exceed the value of autovacuum_vacuum_cost_limit which seems to be always the case in current code but same is not true for proposed patch. Right, but have a lo

Re: [HACKERS] 9.4 release notes

On 05/04/2014 03:46 PM, Bruce Momjian wrote: Auto-resize the catalog cache (Heikki Linnakangas) This reduces memory consumption for backends accessing only a few tables, and improves performance for backend accessing many tables. Move this to "General performance" section. Improve spinlock s

Re: [HACKERS] 9.4 release notes

On 05/04/2014 03:46 PM, Bruce Momjian wrote: I have completed the initial version of the 9.4 release notes. Thanks! You can view them here: http://www.postgresql.org/docs/devel/static/release-9-4.html I will be adding additional markup in the next few days. Feedback expected and we

Re: [HACKERS] Per table autovacuum vacuum cost limit behaviour strange

On Mon, May 5, 2014 at 6:35 AM, Haribabu Kommi wrote: > On Mon, May 5, 2014 at 1:09 AM, Amit Kapila wrote: >> On Mon, Feb 17, 2014 at 7:38 AM, Haribabu Kommi >> wrote: >>> I modified the "autovac_balance_cost" function to balance the costs using >>> the number of running workers, instead >>> of

Re: [HACKERS] EXPIRE as a statement

On Sun, May 4, 2014 at 10:06 PM, Tom Lane-2 [via PostgreSQL] < ml-node+s1045698n5802390...@n5.nabble.com> wrote: > David G Johnston <[hidden > email]> > writes: > > Blagoj Petrushev wrote > >> I know for example that redis has this feature, th

Re: [HACKERS] EXPIRE as a statement

David G Johnston writes: > Blagoj Petrushev wrote >> I know for example that redis has this feature, the EXPIRE / EXPIREAT >> / TTL commands. >> http://redis.io/commands/expire One thought here is that recent versions of the SQL standard contain some temporal-data features, which might well be us

Re: [HACKERS] Per table autovacuum vacuum cost limit behaviour strange

On Mon, May 5, 2014 at 1:09 AM, Amit Kapila wrote: > On Mon, Feb 17, 2014 at 7:38 AM, Haribabu Kommi > wrote: >> I modified the "autovac_balance_cost" function to balance the costs using >> the number of running workers, instead >> of default vacuum cost parameters. >> >> Lets assume there are 4

Re: [HACKERS] EXPIRE as a statement

Blagoj Petrushev wrote > I know for example that redis has this feature, the EXPIRE / EXPIREAT > / TTL commands. > http://redis.io/commands/expire Redis seems to have decided that limiting the extent to which EXPIRE works is necessary in order to maintain performance; I'd be very worried about a s

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

* Neil Tiffin (ne...@neiltiffin.com) wrote: > On May 4, 2014, at 3:17 PM, Stephen Frost wrote: > > Any system where there exists a role similar to 'superuser' in the PG > > sense (a user who is equivilant to the Unix UID under which the rest of > > the system is run) would be hard-pressed to provi

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On May 4, 2014, at 3:17 PM, Stephen Frost wrote: > Neil, > > Thanks for sharing- sounds very similar to what I've heard also. Your > input and experience with this is very much sought and appreciated- > please continue to help us understand, so we're able to provide > something concrete and us

Re: [HACKERS] EXPIRE as a statement

Blagoj, * Blagoj Petrushev (b.petrus...@gmail.com) wrote: > The rows that match the `my_condition` will be deleted when the > current timestamp reaches my_timestamp or, in the second case, exactly > my_interval time after the execution. An in-PG version of cron has been discussed before and seems

[HACKERS] EXPIRE as a statement

Hello, This is my first time posting on the list. Also, I was trying to find something on the list's history on this topic but without results. My idea is new statement with roughly the following format (similar to update): EXPIRE FROM my_table AT my_timestamp WHERE my_condition or EXP

[HACKERS] Comment patch for index-only scans

If I recall correctly, Tom pointed out a while back that the comment justifying the lockless read of the VM bit was not correct (or at least not complete). I rewrote it, but it was part of a patch that was not accepted. Attached is the comment patch only. Regards, Jeff Davis *** a/src/ba

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

Neil, Thanks for sharing- sounds very similar to what I've heard also. Your input and experience with this is very much sought and appreciated- please continue to help us understand, so we're able to provide something concrete and useful. Further comments inline. * Neil Tiffin (ne...@neiltiffin

Re: [HACKERS] Sending out a request for more buildfarm animals?

On Sun, May 4, 2014 at 9:35 PM, Josh Berkus wrote: > > Architecture wise there's no coverage for: > > * some ARM architecture varians > > I could run a buildfarm animal on a Raspberry Pi if the Postgres > community will replace my flash cards as they burn out. > Heikki already does that - it's c

Re: [HACKERS] Sending out a request for more buildfarm animals?

Andres, > There's pretty little coverage of non mainstream platforms/compilers in > the buildfarm atm. Maybe we should send an email on -announce asking for > new ones? > There's no coverage for OS-wise; > * AIX (at all) > * HP-UX (for master at least) > (* Tru64) > (* UnixWare) Do we want a Smar

Re: [HACKERS] Sending out a request for more buildfarm animals?

On 3.5.2014 19:01, Andrew Dunstan wrote: > > On 05/03/2014 12:42 PM, Tomas Vondra wrote: >> On 3.5.2014 03:07, Noah Misch wrote: >>> More coverage of non-gcc compilers would be an asset to the buildfarm. >> Does that include non-gcc compilers on Linux/x86 platforms? >> >> Magpie is pretty much ded

Re: [HACKERS] 9.4 release notes

I agree, no mongo :) On Sun, May 4, 2014 at 8:47 PM, Magnus Hagander wrote: > > On Sun, May 4, 2014 at 4:06 PM, Oleg Bartunov wrote: >> >> Bruce, >> >> you forgot Alexander Korotkov, who contributed jsonb_hash_ops opclass >> for GIN. Something like >> "Alexander Korotkov introduced an elegant j

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On May 4, 2014, at 10:12 AM, Tom Lane wrote: > Stephen Frost writes: >> * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: >>> 1. I wish it were possible to prevent even the superuser from disabling >>> audit logging once it's enabled, so that if someone gained superuser >>> access without author

Re: [HACKERS] 9.4 release notes

On Sun, May 4, 2014 at 4:06 PM, Oleg Bartunov wrote: > Bruce, > > you forgot Alexander Korotkov, who contributed jsonb_hash_ops opclass > for GIN. Something like > "Alexander Korotkov introduced an elegant jsonb_hash ops for GIN, > which competes with MongoDB performance in contains operator". >

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

At 2014-05-04 11:03:56 -0400, sfr...@snowman.net wrote: > > Another reloption is one option, or an extension on the ACL system > (for that piece of it), or we could make a new catalog for it (ala > pg_seclabel), or perhaps add it on to one (pg_seclabel but rename > it to pg_security..?). I'll look

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

Stephen Frost writes: > * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: >> 1. I wish it were possible to prevent even the superuser from disabling >> audit logging once it's enabled, so that if someone gained superuser >> access without authorisation, their actions would still be logged. >> But

Re: [HACKERS] pg_shmem_allocations view

On 04-05-2014 08:44, Andres Freund wrote: > I've more than once wanted to know what allocated shared memory in > postgres installation is used for. Especially with more an more > extensions around that's quite useful. > A few years ago I had to provide such information an did something similar. Is

Re: [HACKERS] Per table autovacuum vacuum cost limit behaviour strange

On Mon, Feb 17, 2014 at 7:38 AM, Haribabu Kommi wrote: > I modified the "autovac_balance_cost" function to balance the costs using > the number of running workers, instead > of default vacuum cost parameters. > > Lets assume there are 4 workers running currently with default cost values > of limit

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > At 2014-05-04 08:52:42 -0400, sfr...@snowman.net wrote: > > This also addresses things like anonymous DO blocks and functions > > then..? With enough information to be useful for forensics? > > For DML, it addresses anything that goes through In

Re: [HACKERS] need of anonymous record

Craig Ringer writes: > What you appear to want is to access arbitrary fields of a record by name. > The reason this isn't supported directly in PL/PgSQL is, AFAIK, mainly > an issue of data typing. Each field in a record may be of a different > type. So the return type would change based on the f

Re: [HACKERS] 9.4 release notes

On 05/04/2014 10:12 AM, Petr Jelinek wrote: On 04/05/14 14:46, Bruce Momjian wrote: I have completed the initial version of the 9.4 release notes. You can view them here: http://www.postgresql.org/docs/devel/static/release-9-4.html I will be adding additional markup in the next few days.

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

At 2014-05-04 08:52:42 -0400, sfr...@snowman.net wrote: > > This also addresses things like anonymous DO blocks and functions > then..? With enough information to be useful for forensics? For DML, it addresses anything that goes through InitPlan (which, via ExecCheckRTPerms, calls the ExecutorChe

Re: [HACKERS] missing RelationCloseSmgr in FreeFakeRelcacheEntry?

On 2014-03-07 13:50:27 +0200, Heikki Linnakangas wrote: > Thanks Andres. I tried to reproduce the valgrind message you reported, but > couldn't. How did you do it? Did this commit fix it? I previously could reproduce the issue by either forcing a server into recovery or using a replica. That seems

Re: [HACKERS] 9.4 release notes

On 04/05/14 14:46, Bruce Momjian wrote: I have completed the initial version of the 9.4 release notes. You can view them here: http://www.postgresql.org/docs/devel/static/release-9-4.html I will be adding additional markup in the next few days. Feedback expected and welcomed. I expec

Re: [HACKERS] 9.4 release notes

Bruce, you forgot Alexander Korotkov, who contributed jsonb_hash_ops opclass for GIN. Something like "Alexander Korotkov introduced an elegant jsonb_hash ops for GIN, which competes with MongoDB performance in contains operator". Here is a link to discussion - http://www.postgresql.org/message-i

Re: [HACKERS] bgworker crashed or not?

On 30/04/14 23:35, Robert Haas wrote: On Mon, Apr 28, 2014 at 4:19 PM, Petr Jelinek wrote: On 28/04/14 16:27, Robert Haas wrote: It seems we have consensus on what to do about this, but what we haven't got is a patch. If you mean the consensus that exit status 0 should mean permanent stop t

Re: [HACKERS] 9.4 release notes

Hi, On 2014-05-04 08:46:07 -0400, Bruce Momjian wrote: > Feedback expected and welcomed. I expect to be modifying this until we > release 9.4 final. I have marked items where I need help with question > marks. Thanks for doing that work. Some comments inline: + + + Remove system

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > At 2014-05-02 14:22:23 -0400, sfr...@snowman.net wrote: > > I'm aware and I really am not convinced that pushing all of this to > > contrib modules using the hooks is the right approach- for one thing, > > it certainly doesn't seem to me that we'v

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

Abhijit, * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > 3. We steered clear of implementing different log targets. We know that >ereport() doesn't cut it, but decided that doing anything else would >be better after some feedback and wider discussion. Any suggestions >in this regar

[HACKERS] 9.4 release notes

I have completed the initial version of the 9.4 release notes. You can view them here: http://www.postgresql.org/docs/devel/static/release-9-4.html I will be adding additional markup in the next few days. Feedback expected and welcomed. I expect to be modifying this until we release 9.

Re: [HACKERS] pg_shmem_allocations view

Hi, On 2014-05-04 13:44:17 +0200, Andres Freund wrote: > postgres=# SELECT * FROM pg_shmem_allocations ORDER BY size DESC; > key | off |size | allocated > -+-+-+--- > Buffer Blocks

Re: [HACKERS] pg_shmem_allocations view

Hi, On 2014-05-04 13:44:17 +0200, Andres Freund wrote: > postgres=# SELECT * FROM pg_shmem_allocations ORDER BY size DESC; > key | off |size | allocated > -+-+-+--- > Buffer Blocks

[HACKERS] pg_shmem_allocations view

Hi, I've more than once wanted to know what allocated shared memory in postgres installation is used for. Especially with more an more extensions around that's quite useful. Thus I've written a patch to add a new SRF/VIEW pg_get_shmem_allocations/pg_shmem_allocations that shows the contents of th

Re: [HACKERS] need of anonymous record

On 05/03/2014 09:55 PM, Peter Krauss wrote: > If "yes", the /record/ datatype is somewhat outdated? No, it isn't. `RETURNS TABLE` is functionally the same as `RETURNS SETOF RECORD` with `OUT` parameters. However, `RETURNS SETOF RECORD` can return arbitrary records of no fixed structure too, and