Re: [HACKERS] Review: query result history in psql

Hello It's look like my bug - wrong compilation I am sorry Pavel 2013/6/28 ian link : > I just applied the patch to a clean branch from the latest master. I > couldn't get a segfault from using the new feature. Could you provide a > little more info to reproduce the segfault? Thanks > > > On Th

Re: [HACKERS] Review: query result history in psql

No worries! :) On Fri, Jun 28, 2013 at 12:20 AM, Pavel Stehule wrote: > Hello > > It's look like my bug - wrong compilation > > I am sorry > > Pavel > > 2013/6/28 ian link : > > I just applied the patch to a clean branch from the latest master. I > > couldn't get a segfault from using the new fe

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 2013-06-27 18:18:50 -0400, Tom Lane wrote: > Alvaro Herrera writes: > > I'm looking at the combined patches 0003-0005, which are essentially all > > about adding a function to obtain relation OID from (tablespace, > > filenode). It takes care to look through the relation mapper, and uses > > a

Re: [HACKERS] checking variadic "any" argument in parser - should be array

Hi Pavel, On Fri, Jun 28, 2013 at 2:53 AM, Pavel Stehule wrote: > Hello > > 2013/6/27 Jeevan Chalke : > > Hi Pavel, > > > > I had a look over your new patch and it looks good to me. > > > > My review comments on patch: > > > > 1. It cleanly applies with patch -p1 command. > > 2. make/make instal

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On 2013-06-28 16:30:16 +0900, Michael Paquier wrote: > > When I ran VACUUM FULL, I got the following error. > > > > ERROR: attempt to apply a mapping to unmapped relation 16404 > > STATEMENT: vacuum full; > This can be reproduced when doing a vacuum full on pg_proc, > pg_shdescription or pg_db_ro

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On Fri, Jun 28, 2013 at 4:52 PM, Andres Freund wrote: > On 2013-06-28 16:30:16 +0900, Michael Paquier wrote: >> > When I ran VACUUM FULL, I got the following error. >> > >> > ERROR: attempt to apply a mapping to unmapped relation 16404 >> > STATEMENT: vacuum full; >> This can be reproduced when

Re: [HACKERS] Review: query result history in psql

Thanks for checking the patch! So what's left to fix? * Moving the escaping-related functions to separate module, * applying your corrections. Did I missed anything? I'll submit corrected patch after the weekend. M

Re: [HACKERS] FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]

On 27 June 2013 15:05, Tom Lane wrote: > Andrew Gierth writes: >> Tom Lane said: >>> Agreed, separating out the function-call-with-trailing-declaration >>> syntaxes so they aren't considered in FROM and index_elem seems like >>> the best compromise. >>> >>> If we do that for window function OVER

Re: [HACKERS] Documentation/help for materialized and recursive views

On Fri, Jun 28, 2013 at 5:54 AM, Kevin Grittner wrote: > Robert Haas wrote: >> Magnus Hagander wrote: > The functionality of materialized views will (over time) totally swamp that of normal views, so mixing all the corresponding documentation with the documentation for normal v

Re: [HACKERS] Spin Lock sleep resolution

On 27.06.2013 17:30, Robert Haas wrote: On Wed, Jun 26, 2013 at 5:49 PM, Jeff Janes wrote: If we think the patch has a risk of introducing subtle errors, then it probably can't be justified based on the small performance gains you saw. But if we think it has little risk, then I think it is jus

Re: [HACKERS] Group Commits Vs WAL Writes

> > There is a spot on the disk to which the current WAL is destined to go. > That spot on the disk is not going to be under the write-head for (say) > another 6 milliseconds. > > Without commit_delay, I try to commit my record, but find that someone else > is already on the lock (and on the fsync

Re: [HACKERS] Group Commits Vs WAL Writes

> > Yep. To take a degenerate case, suppose that you had many small WAL > records, say 64 bytes each, so more than 100 per 8K block. If you > flush those one by one, you're going to rewrite that block 100 times. > If you flush them all at once, you write that block once. > > But even when the ran

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund wrote: > What that means is that for every heap record in the target database in > the WAL we need to query pg_class to turn the relfilenode into a > pg_class.oid. So, we can easily replace syscache.c with some custom > caching code, but I don't think

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 2013-06-28 08:41:46 -0400, Robert Haas wrote: > On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund wrote: > > What that means is that for every heap record in the target database in > > the WAL we need to query pg_class to turn the relfilenode into a > > pg_class.oid. So, we can easily replace sysc

Re: [HACKERS] Improvement of checkpoint IO scheduler for stable transaction responses

(2013/06/28 0:08), Robert Haas wrote: On Tue, Jun 25, 2013 at 4:28 PM, Heikki Linnakangas wrote: I'm pretty sure Greg Smith tried it the fixed-sleep thing before and it didn't work that well. I have also tried it and the resulting behavior was unimpressive. It makes checkpoints take a long tim

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 2013-06-27 21:52:03 -0700, Kevin Grittner wrote: > Tried that, too, and problem persists.  The log shows the last > commit on your branch as 022c2da1873de2fbc93ae524819932719ca41bdb. > I get the same failure, with primary key or unique index column > showing as 0 in results. I have run enough

Re: [HACKERS] Move unused buffers to freelist

On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila wrote: > Currently it wakes up based on bgwriterdelay config parameter which is by > default 200ms, so you means we should > think of waking up bgwriter based on allocations and number of elements left > in freelist? I think that's what Andres and I a

Re: [HACKERS] Move unused buffers to freelist

On Fri, Jun 28, 2013 at 8:50 AM, Robert Haas wrote: > On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila wrote: >> Currently it wakes up based on bgwriterdelay config parameter which is by >> default 200ms, so you means we should >> think of waking up bgwriter based on allocations and number of elemen

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote: > 2013/6/28 Noah Misch : > > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote: > >> cleaned patch is in attachment > > > > Of the five options you're adding to GET STACKED DIAGNOSTICS, four of them > > appear in the SQL sta

Re: [HACKERS] extensible external toast tuple support

On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund wrote: > Please find attached the next version of the extensible toast > support. There basically are two changes: > > * handle indirect toast tuples properly in heap_tuple_fetch_attr > and related places > * minor comment adjustments It looks to

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

Hello 2013/6/28 Noah Misch : > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote: >> 2013/6/28 Noah Misch : >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote: >> >> cleaned patch is in attachment >> > >> > Of the five options you're adding to GET STACKED DIAGNOSTICS, f

Re: [HACKERS] extensible external toast tuple support

On Fri, Jun 28, 2013 at 9:23 AM, Robert Haas wrote: > On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund > wrote: >> Please find attached the next version of the extensible toast >> support. There basically are two changes: >> >> * handle indirect toast tuples properly in heap_tuple_fetch_attr >>

Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division

On Tue, Jun 25, 2013 at 02:54:55PM +0530, Jeevan Chalke wrote: > On Tue, Jun 25, 2013 at 11:11 AM, Jeevan Chalke < > jeevan.cha...@enterprisedb.com> wrote: > > > Hi David, > > > > I hope this is the latest patch to review, right ? > > > > I am going to review it. > > > > I have gone through the di

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 6/28/13 8:46 AM, Andres Freund wrote: > I personally favor making catalog modifications a bit more more > expensive instead of increasing the WAL volume during routine > operations. I don't think index maintenance itself comes close to the > biggest cost for DDL we have atm. That makes sense to

Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division

David Fetter writes: > Please find attached the latest patch. I remain of the opinion that this is simply a bad idea. It is unlike our habits for constructing other types of nodes, and makes it harder not easier to find all the places that need to be updated when adding another field to FuncCall

Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division

On Fri, Jun 28, 2013 at 10:31:16AM -0400, Tom Lane wrote: > David Fetter writes: > > Please find attached the latest patch. > > I remain of the opinion that this is simply a bad idea. It is unlike > our habits for constructing other types of nodes, and makes it harder > not easier to find all th

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

Andres Freund writes: > On 2013-06-28 08:41:46 -0400, Robert Haas wrote: >> The alternative I previously proposed was to make the WAL records >> carry the relation OID. There are a few problems with that: one is >> that it's a waste of space when logical replication is turned off, and >> it might

Re: [HACKERS] Documentation/help for materialized and recursive views

Magnus Hagander escribió: > They are already crosslinked under "see also". But that doesn't really > help the guy doing "\h CREATE VIEW" in psql, which was the case where > it was brought to my attention. Maybe \h should somehow display the "see also" section? -- Álvaro Herrerah

Re: [HACKERS] Documentation/help for materialized and recursive views

On Fri, Jun 28, 2013 at 4:49 PM, Alvaro Herrera wrote: > Magnus Hagander escribió: > >> They are already crosslinked under "see also". But that doesn't really >> help the guy doing "\h CREATE VIEW" in psql, which was the case where >> it was brought to my attention. > > Maybe \h should somehow dis

Re: [HACKERS] extensible external toast tuple support

On 2013-06-28 09:49:53 -0400, Robert Haas wrote: > On Fri, Jun 28, 2013 at 9:23 AM, Robert Haas wrote: > > On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund > > wrote: > >> Please find attached the next version of the extensible toast > >> support. There basically are two changes: > >> > >> * hand

[HACKERS] Re: Department of Redundancy Department: makeNode(FuncCall) division

On Fri, Jun 28, 2013 at 10:31:16AM -0400, Tom Lane wrote: > David Fetter writes: > > Please find attached the latest patch. > > I remain of the opinion that this is simply a bad idea. It is unlike > our habits for constructing other types of nodes, and makes it harder > not easier to find all th

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 2013-06-28 10:49:26 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-06-28 08:41:46 -0400, Robert Haas wrote: > >> The alternative I previously proposed was to make the WAL records > >> carry the relation OID. There are a few problems with that: one is > >> that it's a waste of space

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

On Fri, Jun 28, 2013 at 03:31:00PM +0200, Pavel Stehule wrote: > Hello > > 2013/6/28 Noah Misch : > > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote: > >> 2013/6/28 Noah Misch : > >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote: > >> >> cleaned patch is in attachm

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On Fri, Jun 28, 2013 at 10:49 AM, Tom Lane wrote: > Robert's idea sounds fairly reasonable to me; another 4 bytes per > insert/update/delete WAL entry isn't that big a deal, ... How big a deal is it? This is a serious question, because I don't know. Let's suppose that the average size of an XLO

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

2013/6/28 Noah Misch : > On Fri, Jun 28, 2013 at 03:31:00PM +0200, Pavel Stehule wrote: >> Hello >> >> 2013/6/28 Noah Misch : >> > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote: >> >> 2013/6/28 Noah Misch : >> >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote: >> >>

Re: [HACKERS] extensible external toast tuple support

On Fri, Jun 28, 2013 at 10:53 AM, Andres Freund wrote: >> Why does toast_insert_or_update() need to go through all the >> rigamarole in toast_datum_differs()? I would have thought that it >> could simply treat any external-indirect value as needing to be >> detoasted and retoasted, since the dest

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On Thu, Jun 27, 2013 at 8:52 PM, Nicholas White wrote: >> The result of the current patch using lead > > Actually, I think I agree with you (and, FWIW, so does Oracle: > http://docs.oracle.com/cd/E11882_01/server.112/e25554/analysis.htm#autoId18). > I've refactored the window function's implementa

Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division

On Fri, Jun 28, 2013 at 10:31 AM, Tom Lane wrote: > David Fetter writes: >> Please find attached the latest patch. > > I remain of the opinion that this is simply a bad idea. It is unlike > our habits for constructing other types of nodes, and makes it harder > not easier to find all the places

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

Robert Haas escribió: > On Fri, Jun 28, 2013 at 10:49 AM, Tom Lane wrote: > > Robert's idea sounds fairly reasonable to me; another 4 bytes per > > insert/update/delete WAL entry isn't that big a deal, ... > > How big a deal is it? This is a serious question, because I don't > know. Let's suppo

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

Robert Haas escribió: > On Thu, Jun 27, 2013 at 8:52 PM, Nicholas White wrote: > The documentation you've added reads kind of funny to me: > > + [respect nulls]|[ignore nulls] > > Wouldn't we normally write that as [ [ RESPECT | IGNORE ] NULLS ] ? I think it should be [ { RESPECT | IGN

Re: [HACKERS] Review: query result history in psql

Hello I am not sure, this interface is really user friendly there is not possible "searching" in history, and not every query push to history some interesting content. It require: * simply decision if content should be stored in history or not, * simply remove last entry (table) of history * qu

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

Alvaro Herrera escribió: > An INSERT wal record is: > > typedef struct xl_heap_insert > { > xl_heaptid target; /* inserted tuple id */ > boolall_visible_cleared;/* PD_ALL_VISIBLE was cleared */ > /* xl_heap_header & TUPLE DATA FOLLOWS AT END

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On Fri, Jun 28, 2013 at 11:41 AM, Alvaro Herrera wrote: > Robert Haas escribió: >> On Thu, Jun 27, 2013 at 8:52 PM, Nicholas White wrote: > >> The documentation you've added reads kind of funny to me: >> >> + [respect nulls]|[ignore nulls] >> >> Wouldn't we normally write that as [ [ RESP

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

Robert Haas writes: > I'm just talking out of my rear end here because I don't know what the > real numbers are, but it's far from obvious to me that there's any > free lunch here. That having been said, just because indexing > relfilenode or adding relfilenodes to WAL records is expensive doesn'

Re: [HACKERS] PostgreSQL 9.3 latest dev snapshot

On 06/27/2013 12:22 PM, Magnus Hagander wrote: > On Tue, Jun 25, 2013 at 3:31 PM, Michael Paquier > wrote: >> >> On 2013/06/25, at 22:23, Fujii Masao wrote: >> >>> On Tue, Jun 25, 2013 at 6:33 PM, Michael Paquier >>> wrote: On Tue, Jun 25, 2013 at 5:33 PM, Misa Simic wrote: > Hi, >

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

On Fri, Jun 28, 2013 at 05:21:29PM +0200, Pavel Stehule wrote: > 2013/6/28 Noah Misch : > > Okay. I failed to note the first time through that while the patch uses the > > same option names for RAISE and GET STACKED DIAGNOSTICS, the existing option > > lists for those commands differ: > > > > --RA

Re: [HACKERS] ALTER TABLE ... ALTER CONSTRAINT

On 24 June 2013 22:17, Simon Riggs wrote: > On 24 June 2013 21:42, Jeff Janes wrote: > >> On Sun, Jun 23, 2013 at 8:58 PM, Abhijit Menon-Sen >> wrote: >> >>> At 2013-06-08 21:45:24 +0100, si...@2ndquadrant.com wrote: >>> > >>> > ALTER TABLE foo >>> >ALTER CONSTRAINT fktable_fk_fkey DEFERRED

Re: [HACKERS] Move unused buffers to freelist

On 6/28/13 8:50 AM, Robert Haas wrote: On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila wrote: 4. Separate processes for writing dirty buffers and moving buffers to freelist I think this part might be best pushed to a separate patch, although I agree we probably need it. This might be necessar

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On Fri, Jun 28, 2013 at 11:56 AM, Tom Lane wrote: > Robert Haas writes: >> I'm just talking out of my rear end here because I don't know what the >> real numbers are, but it's far from obvious to me that there's any >> free lunch here. That having been said, just because indexing >> relfilenode

Re: [HACKERS] Move unused buffers to freelist

On Fri, Jun 28, 2013 at 12:10 PM, Greg Smith wrote: > This refactoring idea will make that hard to keep around. I think this is > OK though. Switching to a latch based design should eliminate the > bgwriter_delay, which means you won't have this worst case of a 200ms stall > while heavy activity

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

Robert Haas writes: > On the other hand, I can't entirely shake the feeling that adding the > information into WAL would be more reliable. That feeling has been nagging at me too. I can't demonstrate that there's a problem when an ALTER TABLE is in process of rewriting a table into a new relfile

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

> This patch will need to be rebased over those changes See attached - lead-lag-ignore-nulls.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ALTER TABLE ... ALTER CONSTRAINT

Simon Riggs escribió: > Looks like that really is a deficiency in my tool chain on OSX, rather than > some bug/user error. Even at the very latest, very shiny version. > > Latest versions of gcc trap the error, so I'll have to investigate an > alternative. Funnily enough, on Debian Wheezy with g

Re: [HACKERS] PostgreSQL 9.3 latest dev snapshot

Magnus Hagander escribió: > However, if oyu're looking for a snapshot, please use the one on the > ftpsite. Generating those snapshots on the git server is slow and > expensive... Maybe we should redirect those gitweb snapshot URLs to the FTP site? -- Álvaro Herrerahttp://www.2n

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 28 June 2013 17:10, Robert Haas wrote: > > But to tell the truth, I'm mostly exercised about the non-unique > > syscache. I think that's simply a *bad* idea. > > +1. > > I don't think the extra index on pg_class is going to hurt that much, > even if we create it always, as long as we use a p

Re: [HACKERS] [RFC] Minmax indexes

On 6/17/13 3:38 PM, Josh Berkus wrote: Why? Why can't we just update the affected pages in the index? > >The page range has to be scanned in order to find out the min/max values >for the indexed columns on the range; and then, with these data, update >the index. Seems like you could incrementa

Re: [HACKERS] [RFC] Minmax indexes

On Fri, Jun 28, 2013 at 2:18 PM, Jim Nasby wrote: > On 6/17/13 3:38 PM, Josh Berkus wrote: Why? Why can't we just update the affected pages in the index? >>> >>> > >>> >The page range has to be scanned in order to find out the min/max values >>> >for the indexed columns on the range; an

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On Fri, Jun 28, 2013 at 12:29 PM, Nicholas White wrote: >> This patch will need to be rebased over those changes > > See attached - Thanks. But I see a few issues... + [respect nulls]|[ignore nulls] You fixed one of these but missed the other. default are evaluated wit

Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division

On 6/28/13 11:30 AM, Robert Haas wrote: > On Fri, Jun 28, 2013 at 10:31 AM, Tom Lane wrote: >> David Fetter writes: >>> Please find attached the latest patch. >> >> I remain of the opinion that this is simply a bad idea. It is unlike >> our habits for constructing other types of nodes, and makes

Re: [HACKERS] Documentation/help for materialized and recursive views

On 6/28/13 10:49 AM, Alvaro Herrera wrote: > Magnus Hagander escribió: > >> They are already crosslinked under "see also". But that doesn't really >> help the guy doing "\h CREATE VIEW" in psql, which was the case where >> it was brought to my attention. > > Maybe \h should somehow display the "s

Re: [HACKERS] [RFC] Minmax indexes

On 6/28/13 12:26 PM, Claudio Freire wrote: On Fri, Jun 28, 2013 at 2:18 PM, Jim Nasby wrote: On 6/17/13 3:38 PM, Josh Berkus wrote: Why? Why can't we just update the affected pages in the index? The page range has to be scanned in order to find out the min/max values for the indexed colu

Re: [HACKERS] Documentation/help for materialized and recursive views

Peter Eisentraut escribió: > On 6/28/13 10:49 AM, Alvaro Herrera wrote: > > Magnus Hagander escribió: > > > >> They are already crosslinked under "see also". But that doesn't really > >> help the guy doing "\h CREATE VIEW" in psql, which was the case where > >> it was brought to my attention. > >

Re: [HACKERS] [RFC] Minmax indexes

>> On Fri, Jun 28, 2013 at 2:18 PM, Jim Nasby wrote: >>> If we add a dirty flag it would probably be wise to allow for more >>> than one >>> value so we can do a clock-sweep. That would allow for detecting a range >>> that is getting dirtied repeatedly and not bother to try and >>> re-summarize i

Re: [HACKERS] Documentation/help for materialized and recursive views

On Fri, Jun 28, 2013 at 01:34:17PM -0400, Peter Eisentraut wrote: > On 6/28/13 10:49 AM, Alvaro Herrera wrote: > > Magnus Hagander escribió: > > > >> They are already crosslinked under "see also". But that doesn't > >> really help the guy doing "\h CREATE VIEW" in psql, which was the > >> case whe

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

On 06/20/2013 07:19 PM, Jeff Davis wrote: > On Sun, 2013-06-16 at 23:53 -0500, Jon Nelson wrote: >> Please find attached v5 of the patch, with the above correction in place. >> The only change from the v4 patch is wrapping the if >> (wal_use_fallocate) block in an #ifdef USE_POSIX_FALLOCATE. >> Tha

[HACKERS] [9.3 CF 1] 2 Weeks In & The problem with Performance Patches

Folks, We are starting the 3rd week of the commitfest tommorrow, and here's the update on status. In the last week, we are at the following status levels: - 40 patches still Need Review, including 11 which have no reviewer assigned. - 23 patches are Waiting on Author, most of them be

Re: [HACKERS] [9.3 CF 1] 2 Weeks In & The problem with Performance Patches

On 2013-06-28 12:16:09 -0700, Josh Berkus wrote: > - Remove PD_ALL_VISIBLE** I think this is primarily delayed because people don't agree it's a good idea. > - Use posix_fallocate to build (new) WAL files** I don't think this needs much further testing. We should just remove the enable/disable k

Re: [HACKERS] [9.3 CF 1] 2 Weeks In & The problem with Performance Patches

On Fri, Jun 28, 2013 at 4:16 PM, Josh Berkus wrote: > (2) ideas on how we can speed up/parallelize performance testing efforts > are extremely welcome. An official perf-test script in GIT, even if it only tests general pg-bench-like performance, that can take two builds and compare them, like un

Re: [HACKERS] GIN improvements part2: fast scan

On Tue, Jun 25, 2013 at 2:20 AM, Alexander Korotkov wrote: > 4. If we do go with a new function, I'd like to just call it "consistent" >> (or consistent2 or something, to keep it separate form the old consistent >> function), and pass it a tri-state input for each search term. It might not >> be a

Re: [HACKERS] Add more regression tests for ASYNC

On 05/13/2013 05:37 PM, Robins Tharakan wrote: > Hi, > > Patch to add more regression tests to ASYNC (/src/backend/commands/async). > Take code-coverage from 39% to 75%. This isn't applying for me anymore due to changes in the parallel_schedule file. Where did you mean this to execute in the seq

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 2013-06-28 12:26:52 -0400, Tom Lane wrote: > Robert Haas writes: > > On the other hand, I can't entirely shake the feeling that adding the > > information into WAL would be more reliable. > > That feeling has been nagging at me too. I can't demonstrate that > there's a problem when an ALTER T

Re: [HACKERS] Add more regression tests for ASYNC

On 06/28/2013 12:42 PM, Josh Berkus wrote: > On 05/13/2013 05:37 PM, Robins Tharakan wrote: >> Hi, >> >> Patch to add more regression tests to ASYNC (/src/backend/commands/async). >> Take code-coverage from 39% to 75%. > > This isn't applying for me anymore due to changes in the > parallel_schedul

Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

On 06/27/2013 05:04 AM, Szymon Guz wrote: On 27 June 2013 05:21, Steve Singer > wrote: On 06/26/2013 04:47 PM, Szymon Guz wrote: Hi Steve, thanks for the changes. You're idea about common code for decimal and cdecimal is good, however not good enough. I lik

Re: FILTER for aggregates [was Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division]

On 21 June 2013 06:16, David Fetter wrote: > Please find attached a patch which allows subqueries in the FILTER > clause and adds regression testing for same. > This needs re-basing/merging following Robert's recent commit to make OVER unreserved. Regards, Dean -- Sent via pgsql-hackers maili

Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

On 28 June 2013 22:14, Steve Singer wrote: > > I think the value is more important than the name, I want to the tests to > make sure that the conversion is actually converting properly. With your > method of getting the class name without the module we can have both. > > The attached patch shoul

Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

On Fri, Jun 28, 2013 at 5:14 PM, Steve Singer wrote: > On 06/27/2013 05:04 AM, Szymon Guz wrote: >> >> On 27 June 2013 05:21, Steve Singer > > wrote: >> >> On 06/26/2013 04:47 PM, Szymon Guz wrote: >> >> >> >> >> >> >> Hi Steve, >> thanks for the changes. >> >> You'r

Re: [HACKERS] PostgreSQL 9.3 latest dev snapshot

On 06/28/2013 06:51 PM, Alvaro Herrera wrote: > Magnus Hagander escribió: > >> However, if oyu're looking for a snapshot, please use the one on the >> ftpsite. Generating those snapshots on the git server is slow and >> expensive... > > Maybe we should redirect those gitweb snapshot URLs to the F

Re: [HACKERS] Add some regression tests for SEQUENCE

On 05/07/2013 03:40 PM, Robins Tharakan wrote: > Hi, > > Have provided an updated patch as per Fabien's recent response on > Commitfest site. > Any and all feedback is appreciated. The updated patch is giving a FAILURE for me: parallel group (19 tests): limit temp plancache conversion rowtypes

Re: [HACKERS] Add more regression tests for dbcommands

Hi Andres, Just an aside, your point about CONNECTION LIMIT was something that just didn't come to my mind and is probably a good way to test ALTER DATABASE with CONNECTION LIMIT. Its just that that actually wasn't what I was testing there. That 'CONNECTION LIMIT' test was coupled with CREATE DAT

[HACKERS] New regression test time

Hackers, Per discussion on these tests, I ran "make check" against 9.4 head, applied all of the regression tests other than DISCARD. Time for 3 "make check" runs without new tests: 65.9s Time for 3 "make check runs with new tests: 71.7s So that's an increase of about 10% in test runtime (or 2 s

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

I've fixed the problems you mentioned (see attached) - sorry, I was a bit careless with the docs. > + null_values = (Bitmapset *) WinGetPartitionLocalMemory( > + winobj, > + BITMAPSET_SIZE(words_needed)); > + Assert(null_valu

Re: [HACKERS] Add some regression tests for SEQUENCE

Seems like thats because of a recent (15th May 2013) patch (b14206862278347a379f2bb72d92d16fb9dcea45) that changed the error message that is printed. Its just one line of difference actually. Let me know if this is otherwise good to go. I'll checkout the latest revision and submit this patch again

Re: [HACKERS] Add some regression tests for SEQUENCE

On 06/28/2013 02:15 PM, Robins Tharakan wrote: > Seems like thats because of a recent (15th May 2013) patch > (b14206862278347a379f2bb72d92d16fb9dcea45) that changed the error message > that is printed. Its just one line of difference actually. > > Let me know if this is otherwise good to go. > I'

Re: [HACKERS] Add some regression tests for SEQUENCE

On 06/28/2013 02:15 PM, Robins Tharakan wrote: > Seems like thats because of a recent (15th May 2013) patch > (b14206862278347a379f2bb72d92d16fb9dcea45) that changed the error message > that is printed. Its just one line of difference actually. > > Let me know if this is otherwise good to go. > I'

Re: [HACKERS] New regression test time

On 2013-06-28 14:01:23 -0700, Josh Berkus wrote: > Per discussion on these tests, I ran "make check" against 9.4 head, > applied all of the regression tests other than DISCARD. > > Time for 3 "make check" runs without new tests: 65.9s > > Time for 3 "make check runs with new tests: 71.7s > > So

Re: [HACKERS] New regression test time

> How did you evaluate that coverage increased "greatly"? I am not > generally against these tests but I'd be surprised if the overall test > coverage improved noticeably by this. Which makes 10% runtime overhead > pretty hefty if the goal is to actually achieve a high coverage. I was relying on

Re: backend hangs at immediate shutdown (Re: [HACKERS] Back-branch update releases coming in a couple weeks)

MauMau escribió: Hi, > I did this. Please find attached the revised patch. I modified > HandleChildCrash(). I tested the immediate shutdown, and the child > cleanup succeeded. Thanks, committed. There are two matters pending here: 1. do we want postmaster to exit immediately after sending t

Re: [HACKERS] [GENERAL] pg_upgrade -u

On Tue, May 28, 2013 at 09:08:03PM -0700, Joshua D. Drake wrote: > > On 05/28/2013 07:55 PM, Bruce Momjian wrote: > > >>Perhaps just documenting the behavior is all that is needed, but -U is > >>everywhere and I think that's a good thing. > > > >[ moved to hacker ] > > > >Wow, I never realized ot

Re: [HACKERS] New regression test time

On 2013-06-28 14:46:10 -0700, Josh Berkus wrote: > > > How did you evaluate that coverage increased "greatly"? I am not > > generally against these tests but I'd be surprised if the overall test > > coverage improved noticeably by this. Which makes 10% runtime overhead > > pretty hefty if the goal

Re: [HACKERS] [GENERAL] pg_upgrade -u

On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote: > On 5/28/13 10:55 PM, Bruce Momjian wrote: > > Wow, I never realized other tools used -U for user, instead of -u. > > Should I change pg_upgrade to use -U for 9.4? I can keep supporting -u > > as an undocumented option. > > It se

Re: backend hangs at immediate shutdown (Re: [HACKERS] Back-branch update releases coming in a couple weeks)

On Fri, Jun 28, 2013 at 6:00 PM, Alvaro Herrera wrote: > MauMau escribió: > > Hi, > >> I did this. Please find attached the revised patch. I modified >> HandleChildCrash(). I tested the immediate shutdown, and the child >> cleanup succeeded. > > Thanks, committed. > > There are two matters pend

[HACKERS] psql and pset without any arguments

Hi, I was looking at psql 8.3 documention about \pset options and saw that there was the following note : "Note: It is an error to call \pset without any arguments. In the future this case might show the current status of all printing options." I looked backward and forward to find that this

Re: [HACKERS] [GENERAL] pg_upgrade -u

On Thu, May 30, 2013 at 08:42:21AM -0400, Ray Stell wrote: > > On May 29, 2013, at 11:07 AM, Bruce Momjian wrote: > > > On Wed, May 29, 2013 at 08:59:42AM -0400, Ray Stell wrote: > >>> [ moved to hacker ] The question is whether hard-wiring these > >>> helps more than it hurts, and which ones shoul

Re: [HACKERS] [NOVICE] index refuses to build

On Sun, Aug 26, 2012 at 09:47:01AM -0400, Bruce Momjian wrote: > On Thu, Dec 29, 2011 at 10:40:19PM -0500, Tom Lane wrote: > > Merlin Moncure writes: > > > On Thu, Dec 29, 2011 at 5:10 PM, Jean-Yves F. Barbier <12u...@gmail.com> > > > wrote: > > >> CREATE INDEX tst1m_name_lu_ix ON tst1m(unaccent(

Re: [HACKERS] Minor inheritance/check bug: Inconsistent behavior

On Sat, Jan 26, 2013 at 11:31:49AM +0530, Amit Kapila wrote: > On Friday, January 25, 2013 8:36 PM Bruce Momjian wrote: > > On Fri, Sep 14, 2012 at 02:04:51PM +, Amit kapila wrote: > > > On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote: > > > > > > On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapil

Re: [HACKERS] COPY and Volatile default expressions

On 24 June 2013 10:21, Kohei KaiGai wrote: > Hi Simon, > > I checked this patch. One thing I could comment on is, do you think it is > a good > idea to have oid of exception function list on > contain_volatile_functions_walker()? > > The walker function is static thus here is no impact for other

Re: [HACKERS] [GENERAL] pg_upgrade -u

On 6/28/13 6:06 PM, Bruce Momjian wrote: > On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote: >> On 5/28/13 10:55 PM, Bruce Momjian wrote: >>> Wow, I never realized other tools used -U for user, instead of -u. >>> Should I change pg_upgrade to use -U for 9.4? I can keep supporting

Re: [HACKERS] Add more regression tests for CREATE OPERATOR

On 27 June 2013 09:00, Robert Haas wrote: > On Wed, Jun 26, 2013 at 3:29 AM, Szymon Guz wrote: > > OK, so I think this patch can be committed, I will change the status. > > We have a convention that roles created by the regression tests needs > to have "regress" or something of the sort in the n

Re: [HACKERS] [GENERAL] pg_upgrade -u

On Fri, Jun 28, 2013 at 09:15:31PM -0400, Peter Eisentraut wrote: > On 6/28/13 6:06 PM, Bruce Momjian wrote: > > On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote: > >> On 5/28/13 10:55 PM, Bruce Momjian wrote: > >>> Wow, I never realized other tools used -U for user, instead of -u.

Re: [HACKERS] New regression test time

* Josh Berkus (j...@agliodbs.com) wrote: > So that's an increase of about 10% in test runtime (or 2 seconds per run > on my laptop), in order to greatly improve regression test coverage. > I'd say that splitting the tests is not warranted, and that we should go > ahead with these tests on their tes

  1   2   >