Re: [HACKERS] PostgreSQL Auditing

On Tue, Feb 2, 2016 at 8:25 PM, Curtis Ruck wrote: > Additionally Robert, given your professional status, you are by no means an > unbiased contributor in this discussion. Your stance on this matter shows > that you don't necessarily want the open source solution to succeed in the > commercial/co

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Tue, Feb 2, 2016 at 10:09 PM, Robert Haas wrote: > > On Mon, Feb 1, 2016 at 8:40 AM, Alexander Korotkov wrote: > > I wonder if we can use 4-byte wait_event_info more efficiently. > > LWLock number in the tranche would be also useful information to expose. > > Using lwlock number user can deter

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Tue, Feb 2, 2016 at 10:27 PM, Amit Kapila wrote: > So, let's leave adding any additional column, but Alexander has brought up > a good point about storing the wait_type and actual wait_event > information into four bytes. Currently I have stored wait_type (aka > classId) > in first byte and th

Re: [HACKERS] Raising the checkpoint_timeout limit

On Tue, Feb 2, 2016 at 8:09 PM, Noah Misch wrote: > On Tue, Feb 02, 2016 at 12:24:50PM +0100, Andres Freund wrote: >> On 2016-02-01 23:16:16 -0500, Noah Misch wrote: >> > On Tue, Feb 02, 2016 at 01:13:20AM +0100, Andres Freund wrote: >> > > I'm not sure what'd actually be a good upper limit. I'd b

Re: [HACKERS] pglogical - logical replication contrib module

On 01/26/2016 10:43 AM, Craig Ringer wrote: On 23 January 2016 at 11:17, Steve Singer > wrote: ** Schema changes involving rewriting big tables Sometimes you have a DDL change on a large table that will involve a table rewrite and the best way of deploy

Re: [HACKERS] [POC] FETCH limited by bytes.

> > > I don't see how. There really is no declaration in there for a > variable called server. > Absolutely correct. My only guess is that it was from failing to make clean after a checkout/re-checkout. A good reason to have even boring regression tests. Regression tests added. diff --git a/cont

Re: [HACKERS] Minor code improvements to create_foreignscan_plan/ExecInitForeignScan

On 2016/02/03 3:31, Alvaro Herrera wrote: Etsuro Fujita wrote: Done. Attached is an updated version of the patch. Pushed, thanks. Thank you! I kinda wonder why this struct member has a name that doesn't match the naming convention in the rest of the struct, and also why isn't it document

[HACKERS] Incorrect formula for SysV IPC parameters

Hello, I found that the formulas to calculate SEMMNI and SEMMNS are incorrect in 9.2 and later. http://www.postgresql.org/docs/9.5/static/kernel-resources.html All of them say that the same thing as following, | SEMMNI Maximum number of semaphore identifiers (i.e., sets) | | at least ceil((m

Re: [HACKERS] Raising the checkpoint_timeout limit

Noah Misch writes: > On Tue, Feb 02, 2016 at 12:24:50PM +0100, Andres Freund wrote: >> On 2016-02-01 23:16:16 -0500, Noah Misch wrote: >>> In general, I favor having limits reflect fundamental system limitations >>> rather than paternalism. Therefore, I would allow INT_MAX (68 years). >> I gener

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On Mon, Feb 1, 2016 at 7:24 PM, David Steele wrote: > On 2/1/16 5:25 PM, Alvaro Herrera wrote: >> David Steele wrote: > >>> 2) There would be two different ways to suppress client messages but I was >>> hoping to only have one. >> >> I think they are two different things actually. > > Fair enough

Re: [HACKERS] Raising the checkpoint_timeout limit

On Tue, Feb 2, 2016 at 10:58 PM, Tom Lane wrote: > I've gotta go with the "paternalism" side of the argument here. Suppose > you configure your system to checkpoint once a year --- what is going to > happen when the year is up? Or when you try to shut it down? You *will* > regret such a setting

Re: [HACKERS] WAL Re-Writes

On Mon, Feb 1, 2016 at 8:05 PM, Jim Nasby wrote: > On 1/31/16 3:26 PM, Jan Wieck wrote: > >> On 01/27/2016 08:30 AM, Amit Kapila wrote: >> >>> operation. Now why OS couldn't find the corresponding block in >>> memory is that, while closing the WAL file, we use >>> POSIX_FADV_DONTNEED if wal_leve

Re: [HACKERS] Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system

On Mon, Feb 01, 2016 at 07:03:45PM +0100, Tomas Vondra wrote: > On 12/22/2015 03:49 PM, Noah Misch wrote: > >On Mon, Feb 18, 2013 at 06:19:12PM -0300, Alvaro Herrera wrote: > >>I have pushed it now. Further testing, of course, is always welcome. > > > >While investigating stats.sql buildfarm failu

Re: [HACKERS] PATCH: index-only scans with partial indexes

I have applied this patch to our working branch and during several weeks we ran various tests and benchmarks. We have not noticed any problems or performance degradation. And at some queries this patch cause very significant increase of performance - ten times: With this patch: postgres=# ex

Re: [HACKERS] Add links to commit fests to patch summary page

Magnus Hagander wrote: > On Tue, Feb 2, 2016 at 4:43 PM, Alvaro Herrera > wrote: > > > Magnus Hagander wrote: > > > > > So from https://commitfest.postgresql.org/9/353/, you'd want links to > > > /8/353/, /7/353/, /6/353/? > > > > Right. > I'm not entirely sure what I'd use that for myself, but

<    1   2