Re: [HACKERS] Commitfest problems

On 12/16/2014 03:08 AM, Robert Haas wrote: > On Sun, Dec 14, 2014 at 2:24 PM, Mark Cave-Ayland > wrote: >> However if it were posted as part of patchset with a subject of "[PATCH] >> gram.y: add EXCLUDED pseudo-alias to bison grammar" then this may pique >> my interest enough to review the changes

Re: [HACKERS] TABLESAMPLE patch

On Wed, Dec 10, 2014 at 6:24 PM, Petr Jelinek wrote: > Hello, > > Attached is a basic implementation of TABLESAMPLE clause. It's SQL standard > clause and couple of people tried to submit it before so I think I don't > need to explain in length what it does - basically returns "random" sample > of

Re: [HACKERS] Commitfest problems

On 16 December 2014 at 18:18, Josh Berkus 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 more reviewers. > > During that thread a couple people said that novice rev

Re: [HACKERS] pg_basebackup vs. Windows and tablespaces

On Sun, Dec 14, 2014 at 11:54 AM, Amit Kapila wrote: > On Sat, Dec 13, 2014 at 10:48 PM, Tom Lane wrote: > > Andrew Dunstan writes: > > > On 11/20/2014 02:27 AM, Amit Kapila wrote: > > >> Now the part where I would like to receive feedback before revising the > > >> patch is on the coding style.

Re: [HACKERS] moving Orafce from pgFoundry - pgFoundry management

2014-12-16 6:15 GMT+01:00 Marc Fournier : > > > Project disabled on pgfoundry … do you want me to remove the mailing lists > and all those archives? Or leave them there … ? > please, drop it - there is almost spam only Pavel > > > > On Dec 13, 2014, at 9:18 AM, David Fetter wrote: > > > > On

Re: [HACKERS] moving from contrib to bin

On Mon, Dec 15, 2014 at 11:53 AM, Michael Paquier wrote: > On Mon, Dec 15, 2014 at 11:45 AM, Peter Eisentraut wrote: >> On 12/14/14 9:08 PM, Michael Paquier wrote: - no Windows build system support yet >>> Do you need some help here? >> Sure. Peter, Attached is a patch that can be applied o

[HACKERS] NUMERIC private methods?

Folks, While noodling with some weighted statistics , I noticed I was having to jump through a lot of hoops because of all the private methods in numeric.c, especially NumericVar. Would there be some major objection to exposing NumericVar as an opaqu

[HACKERS] analyze_new_cluster.bat and delete_old_cluster.bat not ignored with vcregress upgradecheck

Hi all, As mentioned in $subject, I noticed that those automatically-generated files are not ignored in the tree when running vcregress on Windows, we do ignore their .sh version though. I think that it would be good to back-patch the patch attached to prevent the inclusion of those files in the f

Re: [HACKERS] Commitfest problems

On 16 Dec 2014 7:43 am, Andres Freund wrote: > > On 2014-12-15 21:18:40 -0800, Josh Berkus wrote: > > On 12/15/2014 07:34 PM, Andres Freund wrote: > > > On 2014-12-15 16:14:30 -0800, Josh Berkus wrote: > > >> Read the thread on this list where I suggested crediting reviewers in > > >> the rel

[HACKERS] Some modes of vcregress not mentioned in MSVC scripts

Hi all, While looking at the Windows docs and the MSVC scripts, I noticed that the following run modes of vcregress.pl are either not mentioned in the WIndows installation docs or in the help output of vcregress.pl: - ecpgcheck - isolationcheck - upgradecheck Attached is a patch fixing that. Regar

Re: [HACKERS] Postgres TR for missing chunk

Hello Friends, Can you please tell me the how can I track the which bugs are fixed in which release and when they will be fixed, If I want to track the analysis and status of the bug raised on Postgres. Can I get this information. >From last few days we are struggling with following issue: 1.

Re: [HACKERS] Commitfest problems

On 2014-12-15 21:18:40 -0800, Josh Berkus wrote: > On 12/15/2014 07:34 PM, Andres Freund wrote: > > On 2014-12-15 16:14:30 -0800, Josh Berkus wrote: > >> Read the thread on this list where I suggested crediting reviewers in > >> the release notes. > > > > Man. You're equating stuff that's not the

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

Hello, I have a favor for you committers. I confirmed that this issue the another have been fixed in the repository, thank you. Then, could you please give me when the next release of 9.2.10 is to come? The bugs are found in some system under developing, which is to make use of PG9.2 and it want

Re: [HACKERS] Commitfest problems

On 12/15/2014 07:34 PM, Andres Freund wrote: > On 2014-12-15 16:14:30 -0800, Josh Berkus wrote: >> Read the thread on this list where I suggested crediting reviewers in >> the release notes. > > Man. You're equating stuff that's not the same. You didn't get your way > (and I'm tentatively on your

Re: [HACKERS] Commitfest problems

On Mon, Dec 15, 2014 at 03:29:19PM -0500, Andrew Dunstan wrote: > On 12/15/2014 03:16 PM, Andres Freund wrote: > >On 2014-12-15 11:52:35 -0800, Josh Berkus wrote: > >>On 12/15/2014 11:27 AM, Robert Haas wrote: > >>>I feel like we used to be better at encouraging people to participate > >>>in the CF

Re: [HACKERS] tracking commit timestamps

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 the > > problem, so your assumption was right, Petr. > > Committed, after

Re: [HACKERS] PATCH: decreasing memory needlessly consumed by array_agg

2014-12-16 10:47 GMT+07:00 Ali Akbar : > > > 2014-12-16 6:27 GMT+07:00 Tomas Vondra : >> >> On 15.12.2014 22:35, Jeff Janes wrote: >> > On Sat, Nov 29, 2014 at 8:57 AM, Tomas Vondra > > > wrote: >> > >> > Hi, >> > >> > Attached is v2 of the patch lowering array_agg mem

Re: [HACKERS] PATCH: decreasing memory needlessly consumed by array_agg

2014-12-16 6:27 GMT+07:00 Tomas Vondra : > > On 15.12.2014 22:35, Jeff Janes wrote: > > On Sat, Nov 29, 2014 at 8:57 AM, Tomas Vondra > > wrote: > > > > Hi, > > > > Attached is v2 of the patch lowering array_agg memory requirements. > > Hopefully it addresses the

Re: [HACKERS] Commitfest problems

On 2014-12-15 16:14:30 -0800, Josh Berkus wrote: > Read the thread on this list where I suggested crediting reviewers in > the release notes. 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 w

Re: [HACKERS] Join push-down support for foreign tables

Hanada-san, One other question from my side: How postgres_fdw tries to solve the varno/varattno mapping when it replaces relations join by foreign-scan? Let me explain the issue using an example. If SELECT has a target- list that references 2nd-column of the inner relation and 2nd-column of the o

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

(2014/12/16 2:59), Tom Lane wrote: > Etsuro Fujita writes: >> (2014/12/13 1:17), Tom Lane wrote: >>> We should >>> probably also think about allowing FDWs to change these settings if >>> they want to. > >> This is not clear to me. Maybe I'm missing something, but I think that >> the FDW only nee

Re: [HACKERS] tracking commit timestamps

On Mon, Dec 15, 2014 at 12:12:10AM -0800, Michael Paquier wrote: > On Wed, Dec 10, 2014 at 6:50 PM, Noah Misch wrote: > > On Mon, Dec 08, 2014 at 02:23:39AM +0100, Petr Jelinek wrote: > >> On 08/12/14 00:56, Noah Misch wrote: > >> >The commit_ts test suite gives me the attached diff on a 32-bit Mi

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

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 people from contributing anything to the project, > including reviewi

Re: [HACKERS] pg_rewind in contrib

On Tue, Dec 16, 2014 at 10:26 AM, Michael Paquier wrote: > In any case, I have a couple of comments about this patch as-is: > - If the move to src/bin is done, let's update the MSVC scripts accordingly > - contrib/pg_rewind/.gitignore should be cleaned up from its unnecessary > entries > - README

Re: [HACKERS] pg_rewind in contrib

On Tue, Dec 16, 2014 at 9:32 AM, Michael Paquier wrote: > On Sat, Dec 13, 2014 at 12:01 AM, Heikki Linnakangas > wrote: >> On 12/12/2014 04:20 PM, Andres Freund wrote: >>> >>> Not sure if the copyright notices in the current form are actually ok? >> >> >> Hmm. We do have such copyright notices in

Re: [HACKERS] Fractions in GUC variables

On 12/7/14, 1:48 PM, John Gorman wrote: This patch implements the first wiki/Todo Configuration Files item "Consider normalizing fractions in postgresql.conf, perhaps using '%'". FWIW, I've reviewed this (should have read the thread first :/). It looks clean, passes make check and works as ad

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

On Mon, Dec 15, 2014 at 4:33 PM, Tom Lane wrote: > Jeff Janes writes: >> It seems like IGNORE is getting replaced by the preprocessor with something >> else, but I don't know how to get my hands on the intermediate file after >> the preprocessor has done its thing. > > Maybe IGNORE is defined as

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

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 at fixing this bitrot soon. I'll follow Tom's advice about macro collisions on MinGW while I'm at it, since his explanation seems plausible

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

Jeff Janes writes: > It seems like IGNORE is getting replaced by the preprocessor with something > else, but I don't know how to get my hands on the intermediate file after > the preprocessor has done its thing. Maybe IGNORE is defined as a macro in MinGW? Try s/IGNORE/IGNORE_P/g throughout the p

Re: [HACKERS] pg_rewind in contrib

On Sat, Dec 13, 2014 at 12:01 AM, Heikki Linnakangas wrote: > On 12/12/2014 04:20 PM, Andres Freund wrote: >> >> Not sure if the copyright notices in the current form are actually ok? > > > Hmm. We do have such copyright notices in the source tree, but I know that > we're trying to avoid it in new

[HACKERS] REVIEW: Track TRUNCATE via pgstat

https://commitfest.postgresql.org/action/patch_view?id=1661 (apologies for not replying to the thread; I can't find it in my inbox) Patch applies and passes make check. Code formatting looks good. The regression test partially tests this. It does not cover 2PC, nor does it test rolling back a

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

On Mon, Dec 8, 2014 at 8:16 PM, Peter Geoghegan wrote: > > Attached revision, v1.6, slightly tweaks the ordering of per-statement > trigger execution. The ordering is now explicitly documented (the html > mirror has been updated: > > http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/on

Re: [HACKERS] Commitfest problems

On 12/15/2014 12:05 PM, Peter Geoghegan wrote: > On Mon, Dec 15, 2014 at 11:52 AM, Josh Berkus wrote: >> On 12/15/2014 11:27 AM, Robert Haas wrote: >>> I feel like we used to be better at encouraging people to participate >>> in the CF even if they were not experts, and to do the best they can >>>

Re: [HACKERS] On partitioning

Robert wrote: > On Sun, Dec 14, 2014 at 9:12 PM, Amit Langote > wrote: > > This means if a user puts arbitrary expressions in a partition definition, > > say, > > > > ... FOR VALUES extract(month from current_date) TO extract(month from > current_date + interval '3 months'), > > > > we make sur

Re: [HACKERS] Join push-down support for foreign tables

Hanada-san, Thanks for proposing this great functionality people waited for. > On Mon, Dec 15, 2014 at 3:40 AM, Shigeru Hanada > wrote: > > I'm working on $SUBJECT and would like to get comments about the > > design. Attached patch is for the design below. > > I'm glad you are working on this.

Re: [HACKERS] Status of CF 2014-10 and upcoming 2014-12

On Tue, Dec 16, 2014 at 2:22 AM, Robert Haas wrote: > On Sun, Dec 14, 2014 at 10:58 PM, Michael Paquier > wrote: >> PS: Could someone close CF 2014-10 btw?) > > Done, and I marked 2014-12 in progress. I would give you access, but > I can't seem to ssh into commitfest.postgresql.org any more. Tha

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

On Tue, Dec 16, 2014 at 5:14 AM, Merlin Moncure wrote: > OTOH, Our built in compressor as we all know is a complete dog in > terms of cpu when stacked up against some more modern implementations. > All that said, as long as there is a clean path to migrating to > another compression alg should one

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

On Tue, Dec 16, 2014 at 3:46 AM, Robert Haas wrote: > On Sat, Dec 13, 2014 at 9:36 AM, Michael Paquier > wrote: >> Something to be aware of btw is that this patch introduces an >> additional 8 bytes per block image in WAL as it contains additional >> information to control the compression. In thi

Re: [HACKERS] PATCH: decreasing memory needlessly consumed by array_agg

On 15.12.2014 22:35, Jeff Janes wrote: > On Sat, Nov 29, 2014 at 8:57 AM, Tomas Vondra > wrote: > > Hi, > > Attached is v2 of the patch lowering array_agg memory requirements. > Hopefully it addresses the issues issues mentioned by TL in this thread > (not h

Re: [HACKERS] GiST kNN search queue (Re: KNN-GiST with recheck)

On Mon, Dec 15, 2014 at 5:08 AM, Heikki Linnakangas wrote: Here's a new version of the patch. It now uses the same pairing heap code > that I posted in the other thread ("advance local xmin more aggressivley", > http://www.postgresql.org/message-id/5488acf0.8050...@vmware.com). The > pairingheap_

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

Rodrigo Gonzalez wrote: > I have been reading this list for a long time and I have to say that I > thought about reviewing patches for a long timebut I am really > scared about few things > > 1 - I have no knowledge at all about postgresql code so I can be doing > things incorrectly (sayi

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

On 12/15/14, 1:39 PM, Christoph Berg wrote: Re: Tom Lane 2014-12-15 <21813.1418655...@sss.pgh.pa.us> This is totally silly. The timecnt couldn't be anywhere near INT_MAX (in fact, it is not allowed to exceed TZ_MAX_TIMES, which is currently just 1200). And there are bunches of other instances

Re: [HACKERS] PATCH: decreasing memory needlessly consumed by array_agg

On Sat, Nov 29, 2014 at 8:57 AM, Tomas Vondra wrote: > > Hi, > > Attached is v2 of the patch lowering array_agg memory requirements. > Hopefully it addresses the issues issues mentioned by TL in this thread > (not handling some of the callers appropriately etc.). > Hi Tomas, When configured --wi

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

On 12/15/2014 02:37 AM, Michael Paquier wrote: > Hi all, > > Let's begin the commit fest of December: > https://commitfest.postgresql.org/action/commitfest_view?id=25 I have been reading this list for a long time and I have to say that I thought about reviewing patches for a long timebut I am

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

On 12/15/2014 08:32 PM, Alexander Korotkov wrote: On Mon, Dec 15, 2014 at 7:47 PM, Heikki Linnakangas wrote: On 12/15/2014 05:22 PM, Alexander Korotkov wrote: On Mon, Dec 15, 2014 at 6:20 PM, Tom Lane wrote: Alexander Korotkov writes: On Mon, Dec 15, 2014 at 4:12 PM, Heikki Linnakangas

Re: [HACKERS] Commitfest problems

Andres Freund writes: > On 2014-12-15 11:52:35 -0800, Josh Berkus wrote: >> On 12/15/2014 11:27 AM, Robert Haas wrote: >>> I feel like we used to be better at encouraging people to participate >>> in the CF even if they were not experts, and to do the best they can >>> based on what they did know.

Re: [HACKERS] Commitfest problems

On 12/15/2014 03:16 PM, Andres Freund wrote: On 2014-12-15 11:52:35 -0800, Josh Berkus wrote: On 12/15/2014 11:27 AM, Robert Haas wrote: I feel like we used to be better at encouraging people to participate in the CF even if they were not experts, and to do the best they can based on what they

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On Thu, Dec 11, 2014 at 7:24 PM, Simon Riggs wrote: > > On 17 November 2014 at 22:08, Simon Riggs wrote: > > On 17 November 2014 21:09, Alvaro Herrera > wrote: > >> What happened to this patch? I'm going over something that could use > >> the concept of "clean some stuff up when reading this pa

Re: [HACKERS] Commitfest problems

On 2014-12-15 11:52:35 -0800, Josh Berkus wrote: > On 12/15/2014 11:27 AM, Robert Haas wrote: > > I feel like we used to be better at encouraging people to participate > > in the CF even if they were not experts, and to do the best they can > > based on what they did know. That was a helpful dynam

Re: [HACKERS] pgbench -f and vacuum

On 2014-12-15 10:55:30 -0800, Jeff Janes wrote: > On Sat, Dec 13, 2014 at 7:39 AM, Tom Lane wrote: > > > > Tatsuo Ishii writes: > > > Currently pgbench -f (run custom script) executes vacuum against > > > pgbench_* tables before stating bench marking if -n (or --no-vacuum) > > > is not specified.

Re: [HACKERS] WALWriter active during recovery

Hi, On 2014-12-15 18:51:44 +, 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. Well, it can still buffer data on the network level, but there's definitely limits to that. So I

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

On Fri, Dec 12, 2014 at 8:27 AM, Andres Freund wrote: > On 2014-12-12 09:24:27 -0500, Bruce Momjian wrote: >> On Fri, Dec 12, 2014 at 03:22:24PM +0100, Andres Freund wrote: >> > > Well, the larger question is why wouldn't we just have the user compress >> > > the entire WAL file before archiving -

Re: [HACKERS] Commitfest problems

On Mon, Dec 15, 2014 at 11:52 AM, Josh Berkus wrote: > On 12/15/2014 11:27 AM, Robert Haas wrote: >> I feel like we used to be better at encouraging people to participate >> in the CF even if they were not experts, and to do the best they can >> based on what they did know. That was a helpful dyn

Re: [HACKERS] Commitfest problems

On 12/15/2014 11:27 AM, Robert Haas wrote: > I feel like we used to be better at encouraging people to participate > in the CF even if they were not experts, and to do the best they can > based on what they did know. That was a helpful dynamic. Sure, the > reviews weren't perfect, but more people

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

Re: Tom Lane 2014-12-15 <21813.1418655...@sss.pgh.pa.us> > This is totally silly. The timecnt couldn't be anywhere near INT_MAX (in > fact, it is not allowed to exceed TZ_MAX_TIMES, which is currently just > 1200). And there are bunches of other instances of similar code in PG; > shall we put equ

Re: [HACKERS] Commitfest problems

On Sun, Dec 14, 2014 at 4:53 PM, Mark Cave-Ayland wrote: > What I find frustrating is that I've come back from a workflow where > I've been reviewing/testing patches within months of joining a project > because the barrier for entry has been so low, and yet even with much > longer experience of th

Re: [HACKERS] Commitfest problems

On 12/15/2014 02:08 PM, Robert Haas wrote: On Sun, Dec 14, 2014 at 2:24 PM, Mark Cave-Ayland wrote: However if it were posted as part of patchset with a subject of "[PATCH] gram.y: add EXCLUDED pseudo-alias to bison grammar" then this may pique my interest enough to review the changes to the g

Re: [HACKERS] Commitfest problems

Robert Haas writes: > On Sun, Dec 14, 2014 at 2:24 PM, Mark Cave-Ayland > wrote: >> However if it were posted as part of patchset with a subject of "[PATCH] >> gram.y: add EXCLUDED pseudo-alias to bison grammar" then this may pique >> my interest enough to review the changes to the grammar rules,

Re: [HACKERS] Commitfest problems

On Sun, Dec 14, 2014 at 2:24 PM, Mark Cave-Ayland wrote: > However if it were posted as part of patchset with a subject of "[PATCH] > gram.y: add EXCLUDED pseudo-alias to bison grammar" then this may pique > my interest enough to review the changes to the grammar rules, with the > barrier for entr

Re: [HACKERS] pgbench -f and vacuum

On Sat, Dec 13, 2014 at 7:39 AM, Tom Lane wrote: > > Tatsuo Ishii writes: > > Currently pgbench -f (run custom script) executes vacuum against > > pgbench_* tables before stating bench marking if -n (or --no-vacuum) > > is not specified. If those tables do not exist, pgbench fails. To > > prevent

Re: [HACKERS] On partitioning

On Sun, Dec 14, 2014 at 9:12 PM, Amit Langote wrote: > This means if a user puts arbitrary expressions in a partition definition, > say, > > ... FOR VALUES extract(month from current_date) TO extract(month from > current_date + interval '3 months'), > > we make sure that those expressions are p

[HACKERS] Logical Decoding follows timelines

Currently, it doesn't. This patch is a WIP version of doing that, but only currently attempts to do this in the WALSender. Objective is to allow cascaded logical replication. Very WIP, but here for comments. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development,

[HACKERS] WALWriter active during recovery

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, allowing WALReceiver to progress other useful actions. At prese

Re: [HACKERS] Commitfest problems

On Sat, Dec 13, 2014 at 1:37 AM, Craig Ringer wrote: > > On 12/12/2014 06:02 AM, Josh Berkus wrote: > > > > Speaking as the originator of commitfests, they were *always* intended > > to be a temporary measure, a step on the way to something else like > > continuous integration. > > I'd really like

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

On Sat, Dec 13, 2014 at 9:36 AM, Michael Paquier wrote: > Something to be aware of btw is that this patch introduces an > additional 8 bytes per block image in WAL as it contains additional > information to control the compression. In this case this is the > uint16 compress_len present in XLogReco

Re: [HACKERS] Logical Replication Helpers WIP for discussion

On Mon, Dec 15, 2014 at 12:57 AM, Petr Jelinek wrote: > we've made few helper functions for making logical replication easier, I > bundled it into contrib module as this is mainly for discussion at this time > (I don't expect this to get committed any time soon, but it is good way to > iron out pr

Re: [HACKERS] WIP: dynahash replacement for buffer table

On Sun, Nov 9, 2014 at 3:58 PM, Andres Freund wrote: >> > * There's several cases where it's noticeable that chash creates more >> > cacheline misses - that's imo a good part of why the single threaded >> > performance regresses. There's good reasons for the current design >> > without a inl

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

On Mon, Dec 15, 2014 at 7:47 PM, Heikki Linnakangas wrote: > > On 12/15/2014 05:22 PM, Alexander Korotkov wrote: > >> On Mon, Dec 15, 2014 at 6:20 PM, Tom Lane wrote: >> >>> >>> Alexander Korotkov writes: >>> On Mon, Dec 15, 2014 at 4:12 PM, Heikki Linnakangas < >>> hlinnakan...@vmware

Re: [HACKERS] Commitfest problems

On 15/12/14 16:28, Andres Freund wrote: > I don't believe this really is a question of the type of project. I > think it's more that especially the kernel has had to deal with similar > problems at a much larger scale. And the granular approach somewhat > works for them. Correct. My argument was

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

Etsuro Fujita writes: > (2014/12/13 1:17), Tom Lane wrote: >> We should >> probably also think about allowing FDWs to change these settings if >> they want to. > This is not clear to me. Maybe I'm missing something, but I think that > the FDW only needs to look at the original locking strength i

Re: [HACKERS] Status of CF 2014-10 and upcoming 2014-12

On Sun, Dec 14, 2014 at 10:58 PM, Michael Paquier wrote: > PS: Could someone close CF 2014-10 btw?) Done, and I marked 2014-12 in progress. I would give you access, but I can't seem to ssh into commitfest.postgresql.org any more. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Ent

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

Robert Haas writes: > On Sun, Dec 14, 2014 at 8:24 PM, Michael Paquier > wrote: >> Moving this patch to CF 2014-12 as work is still going on, note that >> it is currently marked with Robert as reviewer and that its current >> status is "Needs review". > The status here is more like "waiting arou

Re: [HACKERS] Something is broken in logical decoding with CLOBBER_CACHE_ALWAYS

On 2014-12-15 11:30:40 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2014-12-15 10:15:30 -0500, Tom Lane wrote: > >> The CLOBBER_CACHE_ALWAYS buildfarm members occasionally fail in > >> contrib/test_decoding with > >> TRAP: FailedAssertion("!(((bool)((relation)->rd_refcnt == 0)))", File:

Re: [HACKERS] [PATCH] explain sortorder

Initial review: Patch applies cleanly to current head, although it appears to have soft/hard tab and trailing space issues. make check fails with the output below. The expected collation clause is not present. -- -- Test explain feature: sort order -- CREATE TABLE sortordertest (n1 char(1), n2

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

On 12/15/2014 05:22 PM, Alexander Korotkov wrote: On Mon, Dec 15, 2014 at 6:20 PM, Tom Lane wrote: Alexander Korotkov writes: On Mon, Dec 15, 2014 at 4:12 PM, Heikki Linnakangas < hlinnakan...@vmware.com wrote: Right. I also looked at it briefly, but I wasn't sure if we really want it. AFA

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

On Sun, Dec 14, 2014 at 8:24 PM, Michael Paquier wrote: > On Tue, Dec 9, 2014 at 2:52 AM, Peter Geoghegan wrote: >> On Mon, Dec 8, 2014 at 9:43 AM, Peter Geoghegan wrote: >>> I think it's very possible that the wrong alias may be provided by the >>> user, and that we should consider that when pr

Re: [HACKERS] Role Attribute Bitmask Catalog Representation

All, Overall, I'm pretty happy with the patch and would suggest moving on to > writing up the documentation changes to go along with the code changes. > I'll continue to play around with it but it all seems pretty clean to > me and will allow us to easily add the additiaonl role attributes being >

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

Peter Eisentraut writes: > On 10/16/14 11:34 PM, Craig Ringer wrote: >> psql: FATAL: Peer authentication failed for user "fred" >> HINT: See the server error log for additional information. > > I think this is wrong for many reasons. > > I have never seen an authentication system that responds

Re: [HACKERS] Making BackgroundWorkerHandle a complete type or offering a worker enumeration API?

On 12/16/2014 12:31 AM, Robert Haas wrote: > On Mon, Dec 15, 2014 at 11:28 AM, Craig Ringer wrote: >>> >> If that's not good for some reason, my second choice is adding a >>> >> BGWORKER_UNREGISTER_AFTER_CRASH flag. That seems much simpler and >>> >> less cumbersome than your other proposal. >> >

Re: [HACKERS] Making BackgroundWorkerHandle a complete type or offering a worker enumeration API?

On Mon, Dec 15, 2014 at 11:28 AM, Craig Ringer wrote: >> If that's not good for some reason, my second choice is adding a >> BGWORKER_UNREGISTER_AFTER_CRASH flag. That seems much simpler and >> less cumbersome than your other proposal. > > That'd be my preference. OK, let's do that, then. -- R

Re: [HACKERS] Something is broken in logical decoding with CLOBBER_CACHE_ALWAYS

Andres Freund writes: > On 2014-12-15 10:15:30 -0500, Tom Lane wrote: >> The CLOBBER_CACHE_ALWAYS buildfarm members occasionally fail in >> contrib/test_decoding with >> TRAP: FailedAssertion("!(((bool)((relation)->rd_refcnt == 0)))", File: >> "relcache.c", Line: 1981) > Without catchup invalida

Re: [HACKERS] pgbench -f and vacuum

On Sat, Dec 13, 2014 at 10:39 AM, Tom Lane wrote: > Tatsuo Ishii writes: >> Currently pgbench -f (run custom script) executes vacuum against >> pgbench_* tables before stating bench marking if -n (or --no-vacuum) >> is not specified. If those tables do not exist, pgbench fails. To >> prevent this

Re: [HACKERS] Making BackgroundWorkerHandle a complete type or offering a worker enumeration API?

On 12/16/2014 12:12 AM, Robert Haas wrote: > On Sat, Dec 13, 2014 at 4:13 AM, Craig Ringer wrote: >> While working on BDR, I've run into a situation that I think highlights >> a limitation of the dynamic bgworker API that should be fixed. >> Specifically, when the postmaster crashes and restarts s

Re: [HACKERS] Commitfest problems

On 2014-12-15 11:21:03 -0500, Bruce Momjian wrote: > On Sun, Dec 14, 2014 at 05:21:06PM +, Mark Cave-Ayland wrote: > > I should add here that the QEMU folk do tend to go to great lengths to > > preserve bisectability; often intermediate compatibility APIs are > > introduced early in the patchse

Re: [HACKERS] PATCH: Reducing lock strength of trigger and foreign key DDL

I'm not sure about the rest of this but... On Sat, Dec 13, 2014 at 3:45 PM, Andreas Karlsson wrote: > Is this patch > worthwhile even without reducing the lock levels of the drop commands? Yes! It certainly makes more sense to reduce the lock levels where we can do that relatively easily, and p

Re: [HACKERS] Join push-down support for foreign tables

On Mon, Dec 15, 2014 at 3:40 AM, Shigeru Hanada wrote: > I'm working on $SUBJECT and would like to get comments about the > design. Attached patch is for the design below. I'm glad you are working on this. > 1. Join source relations > As described above, postgres_fdw (and most of SQL-based FDWs

Re: [HACKERS] Commitfest problems

On Sun, Dec 14, 2014 at 05:21:06PM +, Mark Cave-Ayland wrote: > I should add here that the QEMU folk do tend to go to great lengths to > preserve bisectability; often intermediate compatibility APIs are > introduced early in the patchset and then removed at the very end when > the final feature

Re: [HACKERS] Making BackgroundWorkerHandle a complete type or offering a worker enumeration API?

On Sat, Dec 13, 2014 at 4:13 AM, Craig Ringer wrote: > While working on BDR, I've run into a situation that I think highlights > a limitation of the dynamic bgworker API that should be fixed. > Specifically, when the postmaster crashes and restarts shared memory > gets cleared but dynamic bgworker

Re: [HACKERS] Fractions in GUC variables

On Mon, Dec 15, 2014 at 10:19:19AM -0500, Peter Eisentraut wrote: > > Overall, I feel that this isn't really worth the trouble. We use > > fractions consistently now, so there isn't much room for confusion over > > what the current values mean. Using a percentage might be more familiar > > for some

Re: [HACKERS] Something is broken in logical decoding with CLOBBER_CACHE_ALWAYS

Hi, On 2014-12-15 10:15:30 -0500, Tom Lane wrote: > The CLOBBER_CACHE_ALWAYS buildfarm members occasionally fail in > contrib/test_decoding with > > TRAP: FailedAssertion("!(((bool)((relation)->rd_refcnt == 0)))", File: > "relcache.c", Line: 1981) > > for example here: > http://buildfarm.postgres

Re: [HACKERS] Join push-down support for foreign tables

Shigeru Hanada writes: > I'm working on $SUBJECT and would like to get comments about the > design. Attached patch is for the design below. Note that the patch > requires Kaigai-san's custom foriegn join patch[1] For the record, I'm not particularly on-board with custom scan, and even less so w

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

On Mon, Dec 15, 2014 at 6:20 PM, Tom Lane wrote: > > Alexander Korotkov writes: > > On Mon, Dec 15, 2014 at 4:12 PM, Heikki Linnakangas < > hlinnakan...@vmware.com > >> wrote: > >> Right. I also looked at it briefly, but I wasn't sure if we really want > >> it. AFAICT, no-one has actually asked f

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

Alexander Korotkov writes: > On Mon, Dec 15, 2014 at 4:12 PM, Heikki Linnakangas > wrote: >> Right. I also looked at it briefly, but I wasn't sure if we really want >> it. AFAICT, no-one has actually asked for that operator, it was written >> only to be an example of an operator that would benefit

Re: [HACKERS] Fractions in GUC variables

On 12/15/14 8:56 AM, Heikki Linnakangas wrote: >> show cursor_tuple_fraction; --> 10% >> set cursor_tuple_fraction = .15; --> 15% >> set cursor_tuple_fraction = '33%'; --> 33% >> >> I tagged four configuration variables to display as percents. > > I'm not sure I agree that percentages are better t

Re: [HACKERS] KNN-GiST with recheck

On 08/03/2014 04:48 PM, Emre Hasegeli wrote: 1. This patch introduces a new "polygon <-> point" operator. That seems useful on its own, with or without this patch. Yeah, but exact-knn cant come with no one implementation. But it would better come in a separate patch. I tried to split them. S

[HACKERS] Something is broken in logical decoding with CLOBBER_CACHE_ALWAYS

The CLOBBER_CACHE_ALWAYS buildfarm members occasionally fail in contrib/test_decoding with TRAP: FailedAssertion("!(((bool)((relation)->rd_refcnt == 0)))", File: "relcache.c", Line: 1981) for example here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=markhor&dt=2014-12-14%2005%3A50%3A0

Re: [HACKERS] speedup tidbitmap patch: hash BlockNumber

Heikki Linnakangas writes: > On 10/22/2014 04:14 PM, Teodor Sigaev wrote: >> Just replace tag_hash in tidbitmap which uses hash_any to direct call of >> hash_uint32, it saves ~5% of execution time. > I'd suggest putting the new function in hashfn.c, where we already have > similar functions, str

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

Christoph Berg writes: > a fellow Debian Developer found a minor glitch in > src/timezone/localtime.c, where binary search is used. Now I don't > think there is an actual problem (unless there's > 2^30 timezones), > but it would at least make sense to mark the code as okayish so that > people runn

Re: [HACKERS] Custom timestamp format in logs

On 12/14/2014 06:36 PM, Magnus Hagander wrote: A separate GUC seems kind of weird. Wouldn't it be better with something like %(format)t or such in the log_line_prefix itself in that case? That could also be expanded to other parameters, should we need them? %t isn't the only thing that prints t

Re: [HACKERS] [PATCH] add ssl_protocols configuration option

Michael Paquier writes: >>> >>> Perhaps ssloptions.[ch], unless you plan to add non-option-related code >>> there later? >> >> I don't think anything else than common options-related code fits in >> there, so ssloptions.c makes sense to me. >> >>> BTW, there is no Regent code in your openssl.c, so

  1   2   >