Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 2014-12-18 16:05:23 -0600, Jim Nasby wrote: > On 12/18/14, 3:02 PM, Alvaro Herrera wrote: > >Andres Freund wrote: > >>On 2014-12-18 16:41:04 -0300, Alvaro Herrera wrote: > >>>+ if (scan_all) > >>>+ appendStringInfo(&buf, _("waited for %d buffer > >>>pin

Re: [HACKERS] Commitfest problems

On 2014-12-18 10:02:25 -0800, Joshua D. Drake wrote: > I think a lot of hackers forget exactly how tender their egos are. Now I say > this knowing that a lot of them will go, "Oh give me a break" but as someone > who employs hackers, deals with open source AND normal people :P every > single day, I

Re: [HACKERS] tracking commit timestamps

On Tue, Dec 16, 2014 at 01:05:31AM -0300, Alvaro Herrera wrote: > Noah Misch wrote: > > On Mon, Dec 15, 2014 at 12:12:10AM -0800, Michael Paquier wrote: > > > > FWIW, I just tried that with MinGW-32 and I can see the error on Win7. > > > I also checked that changing "< now()" to "<= now()" fixed t

Re: [HACKERS] NUMERIC private methods?

Robert Haas writes: > On Thu, Dec 18, 2014 at 10:21 AM, Tom Lane wrote: >> As the guy who last fooled with the numeric calculation algorithms in any >> major way, I'm painfully aware that numeric is not necessarily more >> accurate than double for anything more complicated than >> addition/subtra

Re: [HACKERS] Role Attribute Bitmask Catalog Representation

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > FWIW I've been giving this patch a look and and adjusting some coding > details here and there. Do you intend to commit it yourself? You're > not listed as reviewer or committer for it in the commitfest app, FWIW. Oh, great, thanks!

Re: [HACKERS] Role Attribute Bitmask Catalog Representation

FWIW I've been giving this patch a look and and adjusting some coding details here and there. Do you intend to commit it yourself? You're not listed as reviewer or committer for it in the commitfest app, FWIW. One thing I don't very much like is that check_role_attribute() receives a RoleAttr bu

Re: [HACKERS] Role Attribute Bitmask Catalog Representation

Adam, * Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote: > I have attached an updated patch with initial documentation changes for > review. Awesome, thanks. I'm going to continue looking at this in more detail, but wanted to mention a few things I noticed in the documentation c

Re: [HACKERS] Commit fest 2014-12, let's begin!

On Mon, Dec 15, 2014 at 03:58:39PM +0200, Heikki Linnakangas wrote: > >WITH closest_candidates AS ( > > SELECT > > streets.gid, > > streets.name, > > streets.geom > > FROM > > nyc_streets streets > > ORDER BY > > streets.geom <-> > > 'SRID=26918;POINT(583571.905921312

Re: [HACKERS] NUMERIC private methods?

Robert Haas wrote: > I think that's ridiculous. You're basically arguing that numeric > doesn't offer meaningful advantages over float8, which flies in the > face of the fact that essentially every database application I've ever > seen uses numeric and I'm not sure I've ever seen one using float8

Re: [HACKERS] NUMERIC private methods?

On Thu, Dec 18, 2014 at 10:21 AM, Tom Lane wrote: > Andrew Gierth writes: >> "Tom" == Tom Lane writes: >> Tom> If you're concerned about arithmetic performance, there is a >> Tom> very obvious fix here: use double. > >> Independently of this specific example, the obvious issue there is that >>

Re: [HACKERS] [Bug] Inconsistent result for inheritance and FOR UPDATE.

On Tue, Dec 16, 2014 at 11:57:54AM -0500, Tom Lane wrote: > > We seem not to have had a new release of 9.2 since July, which is an > > awfully long time ago. So, hopefully soon? > > Nothing's likely to happen during the holidays, so probably mid-January > is the earliest feasible target. > > I a

Re: [HACKERS] Commitfest problems

* Jim Nasby (jim.na...@bluetreble.com) wrote: > On 12/18/14, 12:08 PM, Joshua D. Drake wrote: > >>> > >>>It does feel good to be acknowledged for our work especially when > >>>there is a policy to acknowledge this in our community. > >>> > > > >I like this idea but who is going to code our new soci

Re: [HACKERS] Commitfest problems

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Josh Berkus wrote: > > So, then, I have a proposal for criteria for getting on the contributors > > list via patch review: > > > > - substantial, deep review of at least one patch (including detailed > > code review and possible corrections) > >

Re: [HACKERS] Commitfest problems

* Andrew Dunstan (and...@dunslane.net) wrote: > >On Wed, Dec 17, 2014 at 5:00 PM, Stephen Frost >> wrote: > >> contributors.postgresql.org/sfrost > > > >> - Recent commits > >> - Recent commit mention

Re: [HACKERS] pg_regress writes into source tree

On 12/18/2014 03:02 AM, Michael Paquier wrote: On Fri, Dec 12, 2014 at 10:45 PM, Alvaro Herrera wrote: Another thing in that patch was that I had to add the sql/ directory to the source tree, but other than that .gitignore file it was empty. Maybe pg_regress should create the sql/ directory i

Re: hash_create API changes (was Re: [HACKERS] speedup tidbitmap patch: hash BlockNumber)

On 12/18/14, 12:48 PM, Tom Lane wrote: I wrote: Here's a proposed patch along this line. I left in oid_hash (in the form of a macro) so that this does not cause any API break for existing third-party modules. However, no callers in our own code directly refer to tag_hash or oid_hash anymore.

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 12/18/14, 3:02 PM, Alvaro Herrera wrote: Andres Freund wrote: On 2014-12-18 16:41:04 -0300, Alvaro Herrera wrote: + if (scan_all) + appendStringInfo(&buf, _("waited for %d buffer pins\n"), +

Re: [HACKERS] Commitfest problems

On 12/18/14, 12:08 PM, Joshua D. Drake wrote: It does feel good to be acknowledged for our work especially when there is a policy to acknowledge this in our community. I like this idea but who is going to code our new social network? +1. I do like the idea; but I don't like it enough to do

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

Andres Freund wrote: > On 2014-12-18 16:41:04 -0300, Alvaro Herrera wrote: > > + if (scan_all) > > + appendStringInfo(&buf, _("waited for %d buffer > > pins\n"), > > + > > vacrelstats->pinned_pa

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 2014-12-18 16:41:04 -0300, Alvaro Herrera wrote: > + if (scan_all) > + appendStringInfo(&buf, _("waited for %d buffer > pins\n"), > + > vacrelstats->pinned_pages); > +

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

Alvaro Herrera writes: > Great, thanks, pushed. I tweaked it a bit more, so that it would say > either "skipped N pages" or "waited N pins" in both autovacuum and > vacuum verbose cases, but only if N > 0. Not directly relevant but ... I think probably all those BlockNumber counters should be pr

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

Heikki Linnakangas wrote: > On 12/18/2014 09:41 PM, Alvaro Herrera wrote: > >Here's my proposal. Instead of punting, I split the message in > >separately translatable units, and emit only the ones that apply. The > >code is messier this way, but I think we can live with that. > > Works for me.

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 12/18/2014 09:41 PM, Alvaro Herrera wrote: Jim Nasby wrote: We have to decide on a tradeoff here. Either we end up with two different log messages (depending on scan_all) that require two different translations, or we end up with a generic message that isn't as clear. The best option I can

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

Jim Nasby wrote: > We have to decide on a tradeoff here. Either we end up with two > different log messages (depending on scan_all) that require two > different translations, or we end up with a generic message that isn't > as clear. > > The best option I can think of for the later is something l

Re: [HACKERS] Commitfest problems

On 12/18/2014 11:03 AM, Gavin Flower wrote: Hey Joshua, what does a 'Normal" person look like??? :-) Hahhhahahah, you have to get out of your basement to see them. Usually, they are at the latest and newest coffee hub, talking about hating hipsters while wearing skinny jeans and a new

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Thu, Dec 18, 2014 at 7:51 AM, Heikki Linnakangas wrote: > On 12/18/2014 05:46 PM, Kevin Grittner wrote: >> >> I don't think either point was ever really settled beyond Robert >> and I preferring ON DUPLICATE versus Peter preferring ON CONFLICT. > > > I also prefer ON CONFLICT, because that make

Re: [HACKERS] Commitfest problems

On 19/12/14 07:02, Joshua D. Drake wrote: On 12/18/2014 04:53 AM, Torsten Zuehlsdorff wrote: Having your name in a list of other names at the bottom of the release notes page, without any indication of what you helped with, would work better? Perhaps it would but I tend to doubt it. Out of

Re: hash_create API changes (was Re: [HACKERS] speedup tidbitmap patch: hash BlockNumber)

I wrote: > Here's a proposed patch along this line. I left in oid_hash (in the > form of a macro) so that this does not cause any API break for existing > third-party modules. However, no callers in our own code directly > refer to tag_hash or oid_hash anymore. Committed that version after some

Re: [HACKERS] Commitfest problems

On 12/18/2014 10:37 AM, Alvaro Herrera wrote: The problem with complicated rules (which these, I think, already are) is how to keep track of people that helps to which level. I make a point of crediting reviewers and code contributors in my commit messages, but can you tell which ones of the f

Re: [HACKERS] Commitfest problems

Josh Berkus wrote: > So, then, I have a proposal for criteria for getting on the contributors > list via patch review: > > - substantial, deep review of at least one patch (including detailed > code review and possible corrections) > > - "functionality" reviews of at least 3 patches, including f

Re: [HACKERS] Commitfest problems

All, It's sounding like folks would prefer keeing the master contributors list up to date, to adding a bunch of names to the release notes. So, then, I have a proposal for criteria for getting on the contributors list via patch review: - substantial, deep review of at least one patch (including

Re: [HACKERS] Commitfest problems

On 12/18/2014 07:31 AM, Andrew Dunstan wrote: +1 It does feel good to be acknowledged for our work especially when there is a policy to acknowledge this in our community. I like this idea but who is going to code our new social network? Frankly, this coin is going to become so debased a

Re: [HACKERS] Commitfest problems

On 12/18/2014 04:53 AM, Torsten Zuehlsdorff wrote: Having your name in a list of other names at the bottom of the release notes page, without any indication of what you helped with, would work better? Perhaps it would but I tend to doubt it. Out of my personal experience in Germany: yes, it

Re: [HACKERS] NUMERIC private methods?

On 12/18/14, 9:21 AM, Tom Lane wrote: As it stands, no extension can use the numeric type in any non-trivial >way without paying a large penalty for repeated pallocs and data copies. >Given that the ability to write C extensions easily is one of pg's great >strengths, this is a defect that should

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 12/18/14, 7:56 AM, Robert Haas wrote: On Wed, Dec 17, 2014 at 11:20 AM, Heikki Linnakangas wrote: LOG: automatic vacuum of table "postgres.public.foo": index scans: 0 pages: 0 removed, 7256 remain, 0 pinned tuples: 79415 removed, 513156 remain, 0 are dead but not yet remov

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Thu, Dec 18, 2014 at 9:20 AM, Jeff Janes wrote: > After actually reading the documentation more closely, I decided this should > be an error because "foo" is not a valid table alias in the "update set" > expression. Instead of being a parsing/planning error, this executes and > the foo.count o

Re: [HACKERS] exitArchiveRecovery woes

On Thu, Dec 18, 2014 at 10:49 AM, Heikki Linnakangas wrote: > On 12/18/2014 03:53 PM, Robert Haas wrote: >> On Wed, Dec 17, 2014 at 8:40 AM, Heikki Linnakangas >> wrote: >>> >>> At the end of archive recovery, we copy the last segment from the old >>> timeline, to initialize the first segment on

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Dec 15, 2014 at 11:06 PM, Peter Geoghegan wrote: > > On Mon, Dec 15, 2014 at 4:59 PM, Peter Geoghegan wrote: > > On Mon, Dec 15, 2014 at 4:22 PM, Jeff Janes > wrote: > >> Also, in both Linux and MinGW under option 1 patch I get an OID > conflict on > >> OID 3261. > > > > I'll take a pass

Re: [HACKERS] Minor binary-search int overflow in timezone code

Re: Tom Lane 2014-12-16 <14615.1418694...@sss.pgh.pa.us> > Jim Nasby writes: > > On 12/15/14, 1:39 PM, Christoph Berg wrote: > >> Well, if it's not interesting, let's just forget it. Sorry. > > > At the risk of sticking my head in the lions mouth... this is the kind of > > response that deters p

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

Heikki Linnakangas wrote: > On 12/18/2014 05:46 PM, Kevin Grittner wrote: >> I don't think either point was ever really settled beyond Robert >> and I preferring ON DUPLICATE versus Peter preferring ON CONFLICT. > > I also prefer ON CONFLICT, because that makes more sense when you > consider exclu

Re: [HACKERS] Parallel Seq Scan

On Thu, Dec 18, 2014 at 9:22 PM, Amit Kapila wrote: > > On Mon, Dec 8, 2014 at 10:40 AM, Amit Kapila wrote: > > > > On Sat, Dec 6, 2014 at 5:37 PM, Stephen Frost wrote: > > > > > > > So to summarize my understanding, below are the set of things > > which I should work on and in the order they ar

Re: [HACKERS] Parallel Seq Scan

On Mon, Dec 8, 2014 at 10:40 AM, Amit Kapila wrote: > > On Sat, Dec 6, 2014 at 5:37 PM, Stephen Frost wrote: > > > > So to summarize my understanding, below are the set of things > which I should work on and in the order they are listed. > > 1. Push down qualification > 2. Performance Data > 3. I

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 12/18/2014 05:46 PM, Kevin Grittner wrote: I don't think either point was ever really settled beyond Robert and I preferring ON DUPLICATE versus Peter preferring ON CONFLICT. I also prefer ON CONFLICT, because that makes more sense when you consider exclusion constraints, which I'm still ho

Re: [HACKERS] exitArchiveRecovery woes

On 12/18/2014 03:53 PM, Robert Haas wrote: On Wed, Dec 17, 2014 at 8:40 AM, Heikki Linnakangas wrote: At the end of archive recovery, we copy the last segment from the old timeline, to initialize the first segment on the new timeline. For example, if the timeline switch happens in the middle of

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

Heikki Linnakangas wrote: > INSERT INTO persons (username, real_name, data) > VALUES('foobar', 'foo bar') > ON CONFLICT (username), (real_name) IGNORE; > INSERT INTO persons (username, real_name, data) > VALUES('foobar', 'foo bar') > ON CONFLICT (username) IGNORE > ON CONFLICT (real_name) UPDATE

Re: [HACKERS] Commitfest problems

On 12/18/2014 10:19 AM, Atri Sharma wrote: On Thu, Dec 18, 2014 at 8:44 PM, Fabrízio de Royes Mello mailto:fabriziome...@gmail.com>> wrote: On Wed, Dec 17, 2014 at 5:00 PM, Stephen Frost mailto:sfr...@snowman.net>> wrote: > > > Another thought I had was to suggest we consid

Re: [HACKERS] NUMERIC private methods?

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> If you're concerned about arithmetic performance, there is a > Tom> very obvious fix here: use double. > Independently of this specific example, the obvious issue there is that > there are applications for which double is simply not acce

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Thu, Dec 18, 2014 at 5:27 PM, Fujii Masao wrote: > Thanks! Thanks for your input. > +else > +memcpy(compression_scratch, page, page_len); > > I don't think the block image needs to be copied to scratch buffer here. > We can try to compress the "page" directl

Re: [HACKERS] Commitfest problems

On Thu, Dec 18, 2014 at 8:44 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > On Wed, Dec 17, 2014 at 5:00 PM, Stephen Frost wrote: > > > > > > Another thought I had was to suggest we consider *everyone* to be a > > contributor and implement a way to tie together the mailing lis

Re: [HACKERS] Commitfest problems

On Wed, Dec 17, 2014 at 5:00 PM, Stephen Frost wrote: > > > Another thought I had was to suggest we consider *everyone* to be a > contributor and implement a way to tie together the mailing list > archives with the commit history and perhaps the commitfest app and make > it searchable and indexed

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 12/18/2014 01:02 AM, Peter Geoghegan wrote: On Wed, Dec 17, 2014 at 1:12 PM, Heikki Linnakangas wrote: Now, let's imagine a table like this: CREATE TABLE persons ( username text unique, real_name text unique, data text ); Is there any way to specify both of those constraints, so t

Re: [HACKERS] Table-level log_autovacuum_min_duration

Michael Paquier wrote: > Hi all, > > Today I spent a bit of time looking at the activity of autovacuum for > one table particularly bloated. log_autovacuum_min_duration was > enabled and set to a high value but even with that I had to deal with > some spam from the jobs of other tables. It would b

Re: [HACKERS] Function to know last log write timestamp

On Fri, Nov 28, 2014 at 9:07 PM, Fujii Masao wrote: > On Wed, Nov 26, 2014 at 4:05 PM, Michael Paquier > wrote: >> On Fri, Aug 15, 2014 at 8:17 PM, Fujii Masao wrote: >>> On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund >>> wrote: On 2014-08-14 14:37:22 -0400, Robert Haas wrote: > On Th

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

Abhijit, * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > At 2014-12-16 13:28:07 -0500, sfr...@snowman.net wrote: > > > > The magic "audit" role has SELECT rights on a given table. When any > > user does a SELECT against that table, ExecCheckRTPerms is called and > > there's a hook there which

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On Wed, Dec 17, 2014 at 11:20 AM, Heikki Linnakangas wrote: > LOG: automatic vacuum of table "postgres.public.foo": index scans: 0 > pages: 0 removed, 7256 remain, 0 pinned > tuples: 79415 removed, 513156 remain, 0 are dead but not yet > removable > buffer usage: 14532 hit

Re: [HACKERS] exitArchiveRecovery woes

On Wed, Dec 17, 2014 at 8:40 AM, Heikki Linnakangas wrote: > At the end of archive recovery, we copy the last segment from the old > timeline, to initialize the first segment on the new timeline. For example, > if the timeline switch happens in the middle of WAL segment > 00010005,

[HACKERS] Table-level log_autovacuum_min_duration

Hi all, Today I spent a bit of time looking at the activity of autovacuum for one table particularly bloated. log_autovacuum_min_duration was enabled and set to a high value but even with that I had to deal with some spam from the jobs of other tables. It would be cool to have the possibility to d

Re: [HACKERS] WIP patch for Oid formatting in printf/elog strings

Mark Dilger wrote: > I've been going through a copy of the code and replacing int32 and uint32 > with the appropriate type such as Oid, TransactionId, and such, and have > created my own typedef for TypeModType, in order to help chase through > the code and figure out what functions handle what ki

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

At 2014-12-16 13:28:07 -0500, sfr...@snowman.net wrote: > > The magic "audit" role has SELECT rights on a given table. When any > user does a SELECT against that table, ExecCheckRTPerms is called and > there's a hook there which the module can use to say "ok, does the > audit role have any permiss

Re: [HACKERS] Commitfest problems

On 17.12.2014 20:00, Stephen Frost wrote: * Jaime Casanova (ja...@2ndquadrant.com) wrote: On Tue, Dec 16, 2014 at 11:32 AM, Robert Haas wrote: It has been proposed that we do a general list of people at the bottom of the release notes who helped review during that cycle. That would be less

Re: [HACKERS] no test programs in contrib

Michael Paquier wrote: > It would be good to be consistent on Windows with what is now done on other > platforms: those modules should not be installed by default, but it would > be good to make install.pm a bit smarter with for example an option "full", > aka install server + client + test module

Re: [HACKERS] Add generate_series(numeric, numeric)

On Mon, Dec 15, 2014 at 2:38 PM, Andrew Gierth wrote: >> "Ali" == Ali Akbar writes: > > Ali> I think yes, it will be good. The alternative is restructuring > Ali> this paragraph in the SRF docs: > > >> The memory context that is current when the SRF is called is a > >> transient context

Re: [HACKERS] Add generate_series(numeric, numeric)

On Mon, Dec 15, 2014 at 12:25 PM, Andrew Gierth wrote: >> "Fujii" == Fujii Masao writes: > > Fujii> Pushed. > > Bug found: > > regression=# select count(*) from generate_series(1::numeric,10) v, > generate_series(1,v) w; > count > --- > 0 > (1 row) > > regression=# select count(*)

Re: [HACKERS] TABLESAMPLE patch

Hi, v2 version of this patch is attached. On 16/12/14 09:31, Petr Jelinek wrote: On 16/12/14 08:43, Jaime Casanova wrote: Sadly when the jsonb functions patch was committed a few oids where used, so you should update the ones you are using. at least to make the patch easier for testing. Wi

Re: [HACKERS] pgbench -f and vacuum

On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii wrote: >> If we care enough about that case to attempt the vacuum anyway then we >> need to do something about the error message; either squelch it or >> check for the existence of the tables before attempting to >> vacuum. Since there's no way to squ

Re: [HACKERS] .gitignore config.cache and comment about regression.(out|diff)

On Tue, Dec 16, 2014 at 9:47 AM, Jim Nasby wrote: > config.cache is created when you pass -C to configure, which speeds it up > considerably (3.5s vs 16.5 on my laptop). It would be nice to just ignore > the cache file it generates. > > Originally this patch also ignored the regression output file

Re: [HACKERS] speedup tidbitmap patch: cache page

On 18 December 2014 at 04:56, Teodor Sigaev wrote: > > You could well be right, but it would be good to compare the numbers just >> so we >> know this for sure. >> > I wasn't right :( > > # set work_mem='64kB'; > # set enable_seqscan = off; > Patched: 1194.094 ms > Master: 1765.338 ms > > > Are

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Thu, Dec 18, 2014 at 7:31 PM, Rahila Syed wrote: >>Isn't it better to allocate the memory for compression_scratch in >>InitXLogInsert() >>like hdr_scratch? > > I think making compression_scratch a statically allocated global variable > is the result of following discussion earlier, > http://ww

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Thu, Dec 18, 2014 at 7:31 PM, Rahila Syed wrote: >>Isn't it better to allocate the memory for compression_scratch in >>InitXLogInsert() >>like hdr_scratch? > > I think making compression_scratch a statically allocated global variable > is the result of following discussion earlier, > > http://

Re: [HACKERS] Streaming replication and WAL archive interactions

On Wed, Dec 17, 2014 at 4:11 AM, Heikki Linnakangas wrote: > On 12/16/2014 10:24 AM, Borodin Vladimir wrote: >> >> 12 дек. 2014 г., в 16:46, Heikki Linnakangas >> написал(а): >> >>> There have been a few threads on the behavior of WAL archiving, >>> after a standby server is promoted [1] [2]. In

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

>Isn't it better to allocate the memory for compression_scratch in >InitXLogInsert() >like hdr_scratch? I think making compression_scratch a statically allocated global variable is the result of following discussion earlier, http://www.postgresql.org/message-id/ca+tgmoaznbuwnls4bpwyqgqteeznoavy

Re: [HACKERS] Commitfest problems

On 16.12.2014 08:33, David Rowley wrote: On 16 December 2014 at 18:18, Josh Berkus mailto:j...@agliodbs.com>> wrote: > Man. You're equating stuff that's not the same. You didn't get your way > (and I'm tentatively on your side onthat one) and take that to imply > that we don't want

Re: [HACKERS] WALWriter active during recovery

On Tue, Dec 16, 2014 at 3:51 AM, Simon Riggs wrote: > Currently, WALReceiver writes and fsyncs data it receives. Clearly, > while we are waiting for an fsync we aren't doing any other useful > work. > > Following patch starts WALWriter during recovery and makes it > responsible for fsyncing data,

Re: [HACKERS] Minor improvement to explain.c

(2014/12/18 17:34), Fujii Masao wrote: On Thu, Dec 18, 2014 at 12:52 PM, Etsuro Fujita wrote: The attached patch just removes one bad-looking blank line in the comments at the top of a function in explain.c. Applied. Thanks! Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing l

Re: [HACKERS] Minor improvement to explain.c

On Thu, Dec 18, 2014 at 12:52 PM, Etsuro Fujita wrote: > Hi, > > The attached patch just removes one bad-looking blank line in the > comments at the top of a function in explain.c. Applied. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Too strict check when starting from a basebackup taken off a standby

On 2014-12-16 18:37:48 +0200, Heikki Linnakangas wrote: > On 12/11/2014 04:21 PM, Marco Nenciarini wrote: > >Il 11/12/14 12:38, Andres Freund ha scritto: > >>On December 11, 2014 9:56:09 AM CET, Heikki Linnakangas > >> wrote: > >>>On 12/11/2014 05:45 AM, Andres Freund wrote: > >>> > >>>Yeah. I was

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Thu, Dec 18, 2014 at 2:21 PM, Michael Paquier wrote: > > > On Wed, Dec 17, 2014 at 11:33 PM, Rahila Syed > wrote: >> >> I had a look at code. I have few minor points, > > Thanks! > >> + bkpb.fork_flags |= BKPBLOCK_HAS_IMAGE; >> + >> + if (is_compressed) >> { >>

Re: [HACKERS] pg_regress writes into source tree

On Fri, Dec 12, 2014 at 10:45 PM, Alvaro Herrera wrote: > Another thing in that patch was that I had to add the sql/ directory to > the source tree, but other than that .gitignore file it was empty. > Maybe pg_regress should create the sql/ directory in the build dir if it > doesn't exist. This