Re: [HACKERS] Race condition in b-tree page deletion

On 12/17/2013 03:57 AM, Kevin Grittner wrote: I agree with others that this patch is not suitable for back-patching. I wonder whether some other solution might be worth back-patching, since it is clearly a bug. The "never delete internal pages" might be safe enough to consider. It would lead t

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Tue, Dec 17, 2013 at 11:06 AM, David Rowley wrote: > On Tue, Dec 17, 2013 at 1:18 AM, Tom Lane wrote: > >> Once again: this patch has no business changing any user-visible behavior. >> That would include not changing the number of evaluations of volatile >> functions. The planner is full of

Re: [HACKERS] Heavily modified big table bloat even in auto vacuum is running

On Thu, Dec 12, 2013 at 12:24 PM, Haribabu kommi wrote: > On 06 December 2013 11:57 Amit Kapila wrote: > > A simplified test and updated patch by taking care the above comment are > attached in the mail. > I am not able to reduce the test duration but changed as the test > automatically exists a

Re: [HACKERS] dpkg-buildpackage fails on 9.2.6 on ubuntu 12.04.3 LTS

This is resolved by running dpkg-buildpackage with postgres and dpkg-buildpackage -rsudo with the postgresql source folder in a directory owned by postgres as dpkg creates a temporary folder in said parent directory. However, I am now running into the following issue: The reason I am compiling is

Re: [HACKERS] pg_rewarm status

On Tue, Dec 17, 2013 at 12:04 AM, Jeff Janes wrote: > On Mon, Dec 16, 2013 at 10:02 AM, Robert Haas wrote: >> On Mon, Dec 16, 2013 at 12:02 PM, Jeff Amiel >> wrote: >> Well, the patch was rejected, more or less because people felt it >> overlapped with pgfincore too much. I don't particularly

[HACKERS] commit fest 2013-11 final report

The commit fest is closed. Final score: Needs Review: 8, Ready for Committer: 13, Committed: 36, Returned with Feedback: 42, Rejected: 9. Total: 108. All patches that were in Waiting on Author or Needs Review state and have received a decent review have been moved to Returned with Feedback stat

Re: [HACKERS] Changeset Extraction Interfaces

On Sat, Dec 14, 2013 at 12:37 PM, Andres Freund wrote: > On 2013-12-14 11:50:00 -0500, Robert Haas wrote: >> On Fri, Dec 13, 2013 at 9:14 AM, Andres Freund >> wrote: >> > But can you imagine those users needing an exported snapshot? I can >> > think of several short-lived usages, but all of thos

Re: [HACKERS] planner missing a trick for foreign tables w/OR conditions

On Mon, Dec 16, 2013 at 6:59 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Dec 16, 2013 at 2:04 PM, Tom Lane wrote: >>> The problem is that that optimization is a crock; see the comments >>> for create_or_index_quals(). We can't just turn it loose to CNF-ify >>> every OR it might find.

Re: [HACKERS] Why no INSTEAD OF triggers on tables?

On Mon, Dec 16, 2013 at 9:16 PM, Josh Berkus wrote: > On 12/16/2013 04:22 PM, Tom Lane wrote: >> Josh Berkus writes: >>> I've looked in the archives, but I can't find a reason why INSTEAD OF >>> triggers were never enabled for tables. >> >> What would that mean exactly? And how would you do the

Re: [HACKERS] dpkg-buildpackage fails on 9.2.6 on ubuntu 12.04.3 LTS

http://pastebin.com/GP7b4FPT tail of the failure. Running: sudo -u postgres dpkg-buildpackage -rsudo Ends in the same failure. On Mon, Dec 16, 2013 at 9:50 PM, imagene...@gmail.com wrote: > Preface on the venue: It is specified in the description of mailing > lists that pgsql-general is for a

Re: [HACKERS] Race condition in b-tree page deletion

On 11/9/13, 10:02 AM, Heikki Linnakangas wrote: 3. Another approach would be to get rid of the "can't delete rightmost child" limitation. We currently have that limitation because it ensures that we never need to change the high-key of a page. If we delete a page that is the rightmost child of

[HACKERS] dpkg-buildpackage fails on 9.2.6 on ubuntu 12.04.3 LTS

Preface on the venue: It is specified in the description of mailing lists that pgsql-general is for all topics except those relating to failed compiles. However doing a search for the word compile fails to yield any other mailing list for said compilation failures. Presumably this is the said maili

Re: [HACKERS] Why no INSTEAD OF triggers on tables?

On 12/16/2013 04:22 PM, Tom Lane wrote: > Josh Berkus writes: >> I've looked in the archives, but I can't find a reason why INSTEAD OF >> triggers were never enabled for tables. > > What would that mean exactly? And how would you do the actual update > when it came time to? Well, I'm specifical

Re: [HACKERS] Race condition in b-tree page deletion

Heikki Linnakangas wrote: > Here's a patch implementing this scheme. I've read through the papers on the btree technique, read the thread, and have been reviewing the patch.  It will take me another day or two to complete a close review and testing, but I wanted to give preliminary results, and

Re: [HACKERS] Extension Templates S03E11

On 12/16/13, 1:00 PM, Josh Berkus wrote: On 12/16/2013 10:53 AM, Josh Berkus wrote: Some PostgreSQL shops with lots of servers have large internal libraries of functions, views, and similar code that they've written to support their applications, which don't comprise a complete database. This f

Re: [HACKERS] Proposal: variant of regclass

>> static Datum regclass_gut(char *class_name_or_oid, bool raiseError); >> static List *stringToQualifiedNameList_gut(const char *string, bool >> raiseError); > > Please spell that as "guts" not "gut". Thanks. I see. >> regclass_gut is called from regclassin and toregclass and do the most >> jo

Re: [HACKERS] Why no INSTEAD OF triggers on tables?

Josh Berkus writes: > I've looked in the archives, but I can't find a reason why INSTEAD OF > triggers were never enabled for tables. What would that mean exactly? And how would you do the actual update when it came time to? > Was there a technical obstacle, or is this just a TUIT issue? It so

[HACKERS] Why no INSTEAD OF triggers on tables?

Hackers, I've looked in the archives, but I can't find a reason why INSTEAD OF triggers were never enabled for tables. I'm interested in them in order to return a rowcount to JDBC for INSERTs into partitioned tables. Was there a technical obstacle, or is this just a TUIT issue? -- Josh Berkus

Re: [HACKERS] Cost estimation problem on seq scan in a loop

On Mon, Dec 16, 2013 at 11:41 PM, Jeff Janes wrote: > Is there some principled way to go about teaching the planner that hashing > smallish_table on the join filter key is a cheap insurance policy against > underestimating the row count of the outer loop? The problem is that cheap protection can

Re: [HACKERS] planner missing a trick for foreign tables w/OR conditions

Robert Haas writes: > On Mon, Dec 16, 2013 at 2:04 PM, Tom Lane wrote: >> The problem is that that optimization is a crock; see the comments >> for create_or_index_quals(). We can't just turn it loose to CNF-ify >> every OR it might find. The case that we support at the moment is >> to CNF-ify

[HACKERS] Cost estimation problem on seq scan in a loop

While doing ad hoc queries I've seen several different problems that all seem to be variations on a theme. The plan comes out looking like this: Nested Loop (cost=826867.95..877038.04 rows=1 width=125) Join Filter: (foo.bar = smallish_table.bar) -> Something Complicated (cost=826867.95.

Re: [HACKERS] GIN improvements part 1: additional information

On 12/17/2013 12:22 AM, Alexander Korotkov wrote: On Mon, Dec 16, 2013 at 3:30 PM, Heikki Linnakangas wrote: On 12/12/2013 06:44 PM, Alexander Korotkov wrote: When values are packed into small groups, we have to either insert inefficiently encoded value or re-encode whole right part of va

Re: [HACKERS] GIN improvements part 1: additional information

On Mon, Dec 16, 2013 at 3:30 PM, Heikki Linnakangas wrote: > On 12/12/2013 06:44 PM, Alexander Korotkov wrote: > >> I've thought about different algorithms little more. General problem I see >> is online update. We need it while it is typically not covered by >> researches at all. We already have

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Tue, Dec 17, 2013 at 1:18 AM, Tom Lane wrote: > Once again: this patch has no business changing any user-visible behavior. > That would include not changing the number of evaluations of volatile > functions. The planner is full of places where optimizations are disabled > for volatile subexpr

Re: [HACKERS] ANALYZE sampling is too good

On Mon, Dec 9, 2013 at 3:14 PM, Heikki Linnakangas wrote: > I took a stab at using posix_fadvise() in ANALYZE. It turned out to be > very easy, patch attached. Your mileage may vary, but I'm seeing a nice > gain from this on my laptop. Taking a 3 page sample of a table with > 717717 pages (

Re: [HACKERS] pg_rewarm status

On Mon, Dec 16, 2013 at 1:34 PM, Jeff Janes wrote: > On Mon, Dec 16, 2013 at 10:02 AM, Robert Haas wrote: >> On Mon, Dec 16, 2013 at 12:02 PM, Jeff Amiel >> wrote: >> > Trying to follow the threads and other references - but I can't >> > determine where this patch ended up. >> > >> > (http://www

Re: [HACKERS] planner missing a trick for foreign tables w/OR conditions

On Mon, Dec 16, 2013 at 2:04 PM, Tom Lane wrote: > The problem is that that optimization is a crock; see the comments > for create_or_index_quals(). We can't just turn it loose to CNF-ify > every OR it might find. The case that we support at the moment is > to CNF-ify whichever single OR conditi

Re: [HACKERS] 9.3 reference constraint regression

On 2013-12-16 17:43:37 -0300, Alvaro Herrera wrote: > Alvaro Herrera wrote: > > > This POC patch changes the two places in HeapTupleSatisfiesUpdate that > > need to be touched for this to work. This is probably too simplistic, > > in that I make the involved cases return HeapTupleBeingUpdated wit

Re: [HACKERS] pgsql: Fix a couple of bugs in MultiXactId freezing

BTW, there are a a couple of spec files floating around which perhaps we should consider getting into the source repo (in some cleaned up form). Noah published one, Andres shared a couple more with me, and I think I have two more. They can't be made to work in normal circumstances, because they de

Re: [HACKERS] 9.3 reference constraint regression

Alvaro Herrera wrote: > This POC patch changes the two places in HeapTupleSatisfiesUpdate that > need to be touched for this to work. This is probably too simplistic, > in that I make the involved cases return HeapTupleBeingUpdated without > checking that there actually are remote lockers, which

Re: [HACKERS] row security roadmap proposal

On 12/16/13 9:36 AM, Craig Ringer wrote: - Finish and commit updatable security barrier views. I've still got a lot of straightening out to do there. I don't follow why you've put this part first. It has a lot of new development and the risks that go along with that, but the POC projects I've

Re: [HACKERS] Extension Templates S03E11

Josh Berkus writes: > So, the reason I was confused by this feature -- and the reason Stephen > hates it, I think -- is that I thought it was solving the "Extensions > don't follow replication, and they are complicated to install if your OS > doesn't have good packages" problem. It's not, and it

Re: [HACKERS] logical changeset generation v6.8

Robert Haas writes: > There's that, too. But again, these messages are not can't-happen > scenarios. The argument is just whether to reuse existing error > message text (like "could not write file") or invent a new variation > (like "could not write remapping file"). As long as the message incl

Re: [HACKERS] planner missing a trick for foreign tables w/OR conditions

Robert Haas writes: > Consider a query such as: > SELECT * FROM a, b WHERE (a.x = 42 AND b.y = 43) OR (a.x = 44 AND b.z = 45); > If a and/or b are regular tables, the query planner will cleverly > consider the possibility of using an index on a to filter for rows > with a.x = 42 OR a.x = 44, or o

Re: [HACKERS] Extension Templates S03E11

On 12/16/2013 10:53 AM, Josh Berkus wrote: > Some PostgreSQL shops with lots of servers have large internal libraries > of functions, views, and similar code that they've written to support > their applications, which don't comprise a complete database. This > feature would allow them to "package"

Re: [HACKERS] Extension Templates S03E11

On 12/15/2013 10:47 PM, Jeff Davis wrote: > The patch offers an alternative to dropping files on the filesystem > before doing CREATE EXTENSION. Instead, if the extension has no C code, > you can put it in the catalog using ordinary SQL access, and execute the > same kind of CREATE EXTENSION. Aside

Re: [HACKERS] logical changeset generation v6.8

Robert Haas escribió: > There's that, too. But again, these messages are not can't-happen > scenarios. The argument is just whether to reuse existing error > message text (like "could not write file") or invent a new variation > (like "could not write remapping file"). Andres' argument (which i

Re: [HACKERS] pg_rewarm status

On Mon, Dec 16, 2013 at 10:02 AM, Robert Haas wrote: > On Mon, Dec 16, 2013 at 12:02 PM, Jeff Amiel > wrote: > > Trying to follow the threads and other references - but I can't > determine where this patch ended up. > > ( > http://www.postgresql.org/message-id/ca+tgmobrrrxco+t6gcqrw_djw+uf9zedwf

Re: [HACKERS] pg_rewarm status

On Mon, Dec 16, 2013 at 9:02 AM, Jeff Amiel wrote: > Trying to follow the threads and other references - but I can't determine > where this patch ended up. > ( > http://www.postgresql.org/message-id/ca+tgmobrrrxco+t6gcqrw_djw+uf9zedwf9bejnu+rb5teb...@mail.gmail.com > ) > > I'm > trying to experi

Re: [HACKERS] pg_rewarm status

On Mon, Dec 16, 2013 at 12:02 PM, Jeff Amiel wrote: > Trying to follow the threads and other references - but I can't determine > where this patch ended up. > (http://www.postgresql.org/message-id/ca+tgmobrrrxco+t6gcqrw_djw+uf9zedwf9bejnu+rb5teb...@mail.gmail.com) Well, the patch was rejected, m

Re: [HACKERS] planner missing a trick for foreign tables w/OR conditions

On Mon, Dec 16, 2013 at 12:41:43PM -0500, Robert Haas wrote: > Consider a query such as: > > SELECT * FROM a, b WHERE (a.x = 42 AND b.y = 43) OR (a.x = 44 AND b.z = 45); > > If a and/or b are regular tables, the query planner will cleverly > consider the possibility of using an index on a to filt

Re: [HACKERS] logical changeset generation v6.8

On Mon, Dec 16, 2013 at 12:21 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Dec 16, 2013 at 6:01 AM, Andres Freund >> wrote: >>> Perhaps we should just introduce a marker that some such strings are not >>> to be translated if they are of the unexpected kind. That would probably >>> make

[HACKERS] planner missing a trick for foreign tables w/OR conditions

Consider a query such as: SELECT * FROM a, b WHERE (a.x = 42 AND b.y = 43) OR (a.x = 44 AND b.z = 45); If a and/or b are regular tables, the query planner will cleverly consider the possibility of using an index on a to filter for rows with a.x = 42 OR a.x = 44, or of using an index on b to filte

Re: [HACKERS] 9.3 reference constraint regression

Alvaro Herrera wrote: > The fix for the immediate bug is to add some code to HTSU so that it > checks for locks by other transactions even when the tuple was created > by us. I haven't looked at the other tqual routines yet, but I imagine > they will need equivalent fixes. This POC patch changes

Re: [HACKERS] logical changeset generation v6.8

Robert Haas writes: > On Mon, Dec 16, 2013 at 6:01 AM, Andres Freund wrote: >> Perhaps we should just introduce a marker that some such strings are not >> to be translated if they are of the unexpected kind. That would probably >> make debugging easier too ;) > Well, we have that: it's called el

Re: [HACKERS] logical changeset generation v6.8

On Mon, Dec 16, 2013 at 6:01 AM, Andres Freund wrote: >> There's no hard and >> fast rule here, because some cases are distinguished, but my gut >> feeling is that all of the errors your patch introduces are >> sufficiently obscure cases that separate messages with separate >> translations are not

[HACKERS] pg_rewarm status

Trying to follow the threads and other references - but I can't determine where this patch ended up. (http://www.postgresql.org/message-id/ca+tgmobrrrxco+t6gcqrw_djw+uf9zedwf9bejnu+rb5teb...@mail.gmail.com) I'm trying to experiment with some new hardware - and the functionality to add specific

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Sat, Dec 14, 2013 at 8:00 PM, Tom Lane wrote: > Greg Stark writes: >> On 14 Dec 2013 15:40, "Tom Lane" wrote: >>> I think you *can't* cover them for the float types; roundoff error >>> would mean you don't get the same answers as before. > >> I was going to say the same thing. But then I star

Re: [HACKERS] pgsql: Fix a couple of bugs in MultiXactId freezing

Noah Misch wrote: > On Tue, Dec 03, 2013 at 07:26:38PM +0100, Andres Freund wrote: > > On 2013-12-03 13:14:38 -0500, Noah Misch wrote: > > > On Tue, Dec 03, 2013 at 04:37:58PM +0100, Andres Freund wrote: > > > > I currently don't see fixing the errorneous freezing of lockers (not the > > > > update

Re: [HACKERS] "stuck spinlock"

Tom Lane escribió: > Andres Freund writes: > > On 2013-12-16 09:46:19 -0500, Tom Lane wrote: > >> Are they complete now? > > > Hm. There's two issues I know of left, both discovered in #8673: > > - slru.c:SlruScanDirectory() doesn't support long enough > > filenames. Afaics that should be a fai

Re: Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

On 12/6/13, 9:58 AM, Antonin Houska wrote: > Tested git apply and build again. No warnings. > > The regression test also looks good to me now. > > I'm done with this review. > > (Not sure if I should move it to 'ready for committer' status or the CFM > should do). You should do that, but I'll d

Re: [HACKERS] "stuck spinlock"

Andres Freund writes: > On 2013-12-16 09:46:19 -0500, Tom Lane wrote: >> Are they complete now? > Hm. There's two issues I know of left, both discovered in #8673: > - slru.c:SlruScanDirectory() doesn't support long enough > filenames. Afaics that should be a fairly easy fix. > - multixact/membe

Re: [HACKERS] row security roadmap proposal

On 12/16/2013 10:43 PM, Tom Lane wrote: > Craig Ringer writes: >> - Add an attribute to portals that stores the user ID at the time the >> portal was planned. Possibly extensibly; I'd be surprised if we won't >> need to associate other local info with a portal later. > > This bit seems rather con

Re: [HACKERS] "stuck spinlock"

On 2013-12-16 09:46:19 -0500, Tom Lane wrote: > Andres Freund writes: > > The multixact fixes in 9.3.2 weren't complete either... (see recent push) > > Are they complete now? Hm. There's two issues I know of left, both discovered in #8673: - slru.c:SlruScanDirectory() doesn't support long enough

Re: [HACKERS] "stuck spinlock"

Andres Freund writes: > Hard to say, the issues fixed in the release are quite important as > well. I'd tend to say they are more important. I think we just need to > release 9.3.3 pretty soon. Yeah. > The multixact fixes in 9.3.2 weren't complete either... (see recent push) Are they complete n

Re: [HACKERS] "stuck spinlock"

On 2013-12-16 08:36:51 -0600, Merlin Moncure wrote: > On Sat, Dec 14, 2013 at 6:20 AM, Andres Freund wrote: > > On 2013-12-13 15:49:45 -0600, Merlin Moncure wrote: > >> Is this an edge case or something that will hit a lot of users? > >> Arbitrary server panics seems pretty serious... > > > > Is y

Re: [HACKERS] row security roadmap proposal

Craig Ringer writes: > - Add an attribute to portals that stores the user ID at the time the > portal was planned. Possibly extensibly; I'd be surprised if we won't > need to associate other local info with a portal later. This bit seems rather confused. A portal is a runnable query; we do not s

Re: [HACKERS] row security roadmap proposal

Hi all I'd like to outline a path toward getting row-security into core. Comments / discussion appreciated. I think I/we need to: - Finish and commit updatable security barrier views. I've still got a lot of straightening out to do there. - Add an attribute to portals that stores the user ID at

Re: [HACKERS] "stuck spinlock"

On Sat, Dec 14, 2013 at 6:20 AM, Andres Freund wrote: > On 2013-12-13 15:49:45 -0600, Merlin Moncure wrote: >> On Fri, Dec 13, 2013 at 12:32 PM, Robert Haas wrote: >> > On Fri, Dec 13, 2013 at 11:26 AM, Tom Lane wrote: >> >> And while we're on the subject ... isn't bgworker_die() utterly and >>

Re: [HACKERS] Heavily modified big table bloat even in auto vacuum is running

On Mon, Dec 16, 2013 at 6:51 PM, Peter Eisentraut wrote: > Amit, if you think this patch is ready now, please mark it as Ready for > Committer. Otherwise, I encourage your to continue the discussion and > possibly resubmit the patch to the next commitfest. Only one test is pending from myside to

Re: [HACKERS] Assertion failure in base backup code path

Hi, On 2013-12-16 15:08:51 +0100, Antonin Houska wrote: > In HEAD, pg_basebackup causes WAL sender to fail when the replication > user is not a superuser: > > > #0 0x7f34f671dd25 in raise () from /lib64/libc.so.6 > #1 0x7f34f671f1a8 in abort () from /lib64/libc.so.6 > #2 0x008

[HACKERS] Assertion failure in base backup code path

In HEAD, pg_basebackup causes WAL sender to fail when the replication user is not a superuser: #0 0x7f34f671dd25 in raise () from /lib64/libc.so.6 #1 0x7f34f671f1a8 in abort () from /lib64/libc.so.6 #2 0x008989a9 in ExceptionalCondition (conditionName=0xa51ac1 "!(IsTransactionS

Re: [HACKERS] Proposal: variant of regclass

Tatsuo Ishii writes: > To implement toregclass, which does not throw errors when invalid > argument is given, src/backend/utils/adt/regproc.c is modified. I > added two static functions: > static Datum regclass_gut(char *class_name_or_oid, bool raiseError); > static List *stringToQualifiedNameLis

Re: [HACKERS] Heavily modified big table bloat even in auto vacuum is running

Amit, if you think this patch is ready now, please mark it as Ready for Committer. Otherwise, I encourage your to continue the discussion and possibly resubmit the patch to the next commitfest. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscri

Re: [HACKERS] Useless "Replica Identity: NOTHING" noise from psql \d

On 2013-12-14 17:43:36 +0100, Andres Freund wrote: > On 2013-12-14 11:27:53 -0500, Tom Lane wrote: > > In HEAD: > > > > regression=# \d pg_depend > >Table "pg_catalog.pg_depend" > >Column| Type | Modifiers > > -+-+--- > > classid | oid | not nul

Re: [HACKERS] [9.3 bug] disk space in pg_xlog increases during archive recovery

Hi, Fujii san, On Wed, Aug 7, 2013 at 7:03 AM, Fujii Masao wrote: On second thought, probably we cannot remove the restored WAL files early because they might be required for fast promotion which is new feature in 9.3. In fast promotion, an end-of-recovery checkpoint is not executed. After t

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

David Rowley writes: >> One thing that is currently on my mind is what to do when passing volatile >> functions to the aggregate. Since the number of times we execute a volatile >> function will much depend on the window frame options, I think we should >> include some sort of warning in the docum

Re: [HACKERS] GIN improvements part 1: additional information

On 12/12/2013 06:44 PM, Alexander Korotkov wrote: I've thought about different algorithms little more. General problem I see is online update. We need it while it is typically not covered by researches at all. We already have to invent small index in the end of page. Different encoding methods ad

Re: [HACKERS] logical changeset generation v6.8

Hi Robert, On 2013-12-16 00:53:10 -0500, Robert Haas wrote: > On Wed, Dec 11, 2013 at 7:08 PM, Andres Freund wrote: > >> I don't think there's much point in including "remapping" in all of > >> the error messages. It adds burden for translators and users won't > >> know what a remapping file is

Re: [HACKERS] autovacuum_work_mem

On 16 December 2013 10:12, Heikki Linnakangas wrote: > On 12/13/2013 08:40 PM, Alvaro Herrera wrote: >> >> Heikki Linnakangas escribió: >> >>> I haven't been following this thread in detail, but would it help if >>> we implemented a scheme to reduce (auto)vacuum's memory usage? Such >>> schemes ha

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

KaiGai-san, 2013/12/16 KaiGai Kohei : > (2013/12/16 14:15), Shigeru Hanada wrote: >> (1) ctidscan >> Is session_preload_libraries available to enable the feature, like >> shared_*** and local_***? According to my trial it works fine like >> two similar GUCs. >> > It shall be available; nothing di

Re: [HACKERS] autovacuum_work_mem

On 12/13/2013 08:40 PM, Alvaro Herrera wrote: Heikki Linnakangas escribió: I haven't been following this thread in detail, but would it help if we implemented a scheme to reduce (auto)vacuum's memory usage? Such schemes have been discussed in the past, packing the list of dead items more tightl

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Sun, Dec 15, 2013 at 12:17 PM, David Rowley wrote: > > One thing that is currently on my mind is what to do when passing volatile > functions to the aggregate. Since the number of times we execute a volatile > function will much depend on the window frame options, I think we should > include s

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Mon, Dec 16, 2013 at 9:39 PM, Heikki Linnakangas wrote: > > There's another technique we could use which doesn't need a negative > transition function, assuming the order you feed the values to the aggreate > function doesn't matter: keep subtotals. For example, if the window first > contains

Re: [HACKERS] Like operator for name type

Mohsen SM wrote: > I don't find where of code run the like operation for name Type. > > can you tell me where compare Like clues with one column of name type ? > > I don't find function for this operation in /src/backend/utils/adt/name.c > when I was in debugging mode > and get break point on al

Re: [HACKERS] Proposal: variant of regclass

> Tatsuo Ishii writes: >> Can I make sure that we want to keep the current behavior: > >> test=# SELECT 'pg_klass'::regclass; >> ERROR: relation "pg_klass" does not exist > > Yeah, I think the consensus is to not change the behavior of the input > functions, just add some new ones. Ok, here is

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On 12/15/2013 03:57 AM, Tom Lane wrote: Josh Berkus writes: I think even the FLOAT case deserves some consideration. What's the worst-case drift? Complete loss of all significant digits. The case I was considering earlier of single-row windows could be made safe (I think) if we apply the ne

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On 12/16/2013 08:39 AM, David Rowley wrote: > On Mon, Dec 16, 2013 at 6:00 AM, Ants Aasma > wrote: > > On Dec 15, 2013 6:44 PM, "Tom Lane" > wrote: > > David Rowley > writes: > > > I've attach