Re: [HACKERS] [JDBC] Support for JDBC setQueryTimeout, et al.

On Fri, Oct 15, 2010 at 03:40, Radosław Smogura wrote: >> Regarding JDBC in the CF process -- other interfaces are handled >> there.  I haven't seen one patch this size for JDBC since I've been >> involved, let alone two competing patches to implement the same >> feature.  Small patches which can

Re: [HACKERS] Hot Standby: too many KnownAssignedXids

On Sat, Nov 20, 2010 at 6:46 AM, Joachim Wieland wrote: > I still have the server, if you want me to debug anything or send a > patch against 9.0.1 that gives more output, just let me know. Per previous Simon's comment, the following information would be useful. http://archives.postgresql.org/pgs

Re: [HACKERS] unlogged tables

I have done a bunch of benchmarking. It was not easy to find consistent numbers, so I picked a job and ran the same thing over and over. I'm running Slackware 13.1 on a desktop computer. Linux storm 2.6.35.7-smp #1 SMP Sun Oct 10 21:43:07 CDT 2010 i686 AMD Athlon(tm) 7850 Dual-Core Processor

Re: [HACKERS] SQL/MED estimated time of arrival?

On Sun, Nov 21, 2010 at 10:14 PM, Itagaki Takahiro wrote: > On Mon, Nov 22, 2010 at 11:16, Robert Haas wrote: >> To have a chance of getting a significant portion >> of this into PostgreSQL 9.1, it really needs to be broken up into >> INDEPENDENTLY COMMITTABLE SUB-PATCHES. > > Did we discuss abou

Re: [HACKERS] SQL/MED estimated time of arrival?

On Mon, Nov 22, 2010 at 11:16, Robert Haas wrote: > To have a chance of getting a significant portion > of this into PostgreSQL 9.1, it really needs to be broken up into > INDEPENDENTLY COMMITTABLE SUB-PATCHES. Did we discuss about syntax-only patch is not acceptable because it makes the head bro

Re: [HACKERS] security hooks on object creation

2010/11/12 KaiGai Kohei : > (2010/11/12 19:34), KaiGai Kohei wrote: >> I revised my patch according to the prior suggestions. >> > I'm sorry. I revised my patch, but not attached. > > Please see this attached one. I'm satisfied with this approach, although I intend to change InvokeObjectAccessHook

Re: [HACKERS] Per-column collation

On Tue, Nov 16, 2010 at 04:42, Peter Eisentraut wrote: > On mån, 2010-11-15 at 11:34 +0100, Pavel Stehule wrote: >> I am checking a patch. I found a problem with initdb > Ah, late night brain farts, it appears.  Here is a corrected version. This version cannot be applied cleanly any more. Please

Re: [HACKERS] psql: Add \dL to show languages

On Sun, Nov 21, 2010 at 9:44 PM, Josh Kupershmidt wrote: > On Sun, Nov 21, 2010 at 8:39 PM, Robert Haas wrote: >> Please add this patch to the currently open CommitFest: > > Added to 2011-01. > >> https://commitfest.postgresql.org/action/commitfest_view/open >> >> And please also help with review

Re: [HACKERS] psql: Add \dL to show languages

On Sun, Nov 21, 2010 at 8:39 PM, Robert Haas wrote: > Please add this patch to the currently open CommitFest: Added to 2011-01. > https://commitfest.postgresql.org/action/commitfest_view/open > > And please also help with review of patches from the current CommitFest: > > https://commitfest.post

Re: [HACKERS] SQL/MED estimated time of arrival?

On Fri, Nov 19, 2010 at 9:55 AM, Shigeru HANADA wrote: > [ new SQL/MED patch ] I can't help noticing that this patch adds 8,982 lines and removes 408, making it far larger any other patch I've ever seen on this list. And what that means is that committing all of this in one go is going to be ver

Re: [HACKERS] Instrument checkpoint sync calls

On Mon, Nov 15, 2010 at 3:09 PM, Greg Smith wrote: > So my task list is: > > 0) Rebase against the HEAD that just code related to this touched today > > 1) Assume that log_checkpoints is sufficient control over whether the timing > overhead added is worth collecting, and therefore remove the half-

Re: [HACKERS] psql: Add \dL to show languages

On Sun, Nov 21, 2010 at 8:18 PM, Josh Kupershmidt wrote: > I'd like to revive Fernando Ike's patch implementing the "\dL" command > for psql to list available languages, last version here: >  http://archives.postgresql.org/pgsql-hackers/2009-07/msg01092.php Please add this patch to the currently

Re: [HACKERS] Tab completion for view triggers in psql

On Sun, Nov 21, 2010 at 08:27:34PM -0500, Robert Haas wrote: > On Sun, Nov 21, 2010 at 7:17 PM, David Fetter wrote: > > On Sun, Nov 21, 2010 at 07:09:08PM -0500, Robert Haas wrote: > >> On Sun, Nov 21, 2010 at 4:05 PM, David Fetter wrote: > >> >> > Could someone please commit this? :) > >> >> > >

Re: [HACKERS] Extensions, this time with a patch

On Sun, Nov 21, 2010 at 8:10 PM, Itagaki Takahiro wrote: > On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine > wrote: >> Ah yes, thinking it's an easy patch is not helping. Please find attached >> a revised version of it. > > I checked cfparser.v2.patch. > > It exports the static parseRecoveryComm

Re: [HACKERS] Tab completion for view triggers in psql

On Sun, Nov 21, 2010 at 7:17 PM, David Fetter wrote: > On Sun, Nov 21, 2010 at 07:09:08PM -0500, Robert Haas wrote: >> On Sun, Nov 21, 2010 at 4:05 PM, David Fetter wrote: >> >> > Could someone please commit this? :) >> >> >> >> Eh... was there some reason you didn't add it to the CommitFest app?

[HACKERS] psql: Add \dL to show languages

Hi all, I'd like to revive Fernando Ike's patch implementing the "\dL" command for psql to list available languages, last version here: http://archives.postgresql.org/pgsql-hackers/2009-07/msg01092.php The original patch produced columns "Name", "Owner", "Procedural Language", "Trusted", "Call

Re: [HACKERS] Extensions, this time with a patch

On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine wrote: > Ah yes, thinking it's an easy patch is not helping. Please find attached > a revised version of it. I checked cfparser.v2.patch. It exports the static parseRecoveryCommandFileLine() in xlog.c as the global cfParseOneLine() in cfparser.c wi

Re: [HACKERS] multibyte-character aware support for function "downcase_truncate_identifier()"

Robert Haas writes: > On Sun, Nov 21, 2010 at 6:48 PM, Tom Lane wrote: >> spec compliance aside, we know from bitter experience that we cannot use >> a definition that lets the Turkish locale fool with the mapping of i/I. >> I suspect that locale-dependent mappings of any other characters are >>

Re: [HACKERS] Tab completion for view triggers in psql

On Sun, Nov 21, 2010 at 07:09:08PM -0500, Robert Haas wrote: > On Sun, Nov 21, 2010 at 4:05 PM, David Fetter wrote: > >> > Could someone please commit this? :) > >> > >> Eh... was there some reason you didn't add it to the CommitFest app? > > > > I forgot. > > A fair excuse. :-) > > >> Because

Re: [HACKERS] Tab completion for view triggers in psql

On Sun, Nov 21, 2010 at 4:05 PM, David Fetter wrote: >> > Could someone please commit this? :) >> >> Eh... was there some reason you didn't add it to the CommitFest app? > > I forgot. A fair excuse. :-) >> Because that's what I work from. > > It's pretty trivial, but I don't feel comfortable ad

Re: [HACKERS] multibyte-character aware support for function "downcase_truncate_identifier()"

On Sun, Nov 21, 2010 at 6:48 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 11/21/2010 06:09 PM, Robert Haas wrote: >>> I think that's fair.  It actually doesn't seem like it should be that >>> hard if we knew that the server encoding were UTF8 - it's just a big >>> translation table somewher

Re: [HACKERS] Spread checkpoint sync

On Sun, Nov 21, 2010 at 4:54 PM, Greg Smith wrote: > Let me throw some numbers out [...] Interesting. > Ultimately what I want to do here is some sort of smarter write-behind sync > operation, perhaps with a LRU on relations with pending fsync requests.  The > idea would be to sync relations tha

Re: [HACKERS] multibyte-character aware support for function "downcase_truncate_identifier()"

Andrew Dunstan writes: > On 11/21/2010 06:09 PM, Robert Haas wrote: >> I think that's fair. It actually doesn't seem like it should be that >> hard if we knew that the server encoding were UTF8 - it's just a big >> translation table somewhere, no? > No, it's far more complex. See for example >

Re: [HACKERS] knngist - 0.8

Robert Haas writes: > That doesn't seem very hard on its face. The trick is what to do with > that information once you've got it. As far as I can tell, you need > to drill some kind of hole that lets you pass "additional details > about the desired sort order" to the index AM. We clearly need

Re: [HACKERS] multibyte-character aware support for function "downcase_truncate_identifier()"

On Sun, Nov 21, 2010 at 6:22 PM, Andrew Dunstan wrote: > > > On 11/21/2010 06:09 PM, Robert Haas wrote: > > I think that's fair. It actually doesn't seem like it should be that > hard if we knew that the server encoding were UTF8 - it's just a big > translation table somewhere, no? > > No, it's f

Re: [HACKERS] multibyte-character aware support for function "downcase_truncate_identifier()"

On 11/21/2010 06:09 PM, Robert Haas wrote: I think that's fair. It actually doesn't seem like it should be that hard if we knew that the server encoding were UTF8 - it's just a big translation table somewhere, no? No, it's far more complex. See for example

Re: [HACKERS] knngist - 0.8

On Sun, Nov 21, 2010 at 5:24 PM, Tom Lane wrote: > I haven't spent any time on this patch yet (hope to start looking at it > next week).  As for your specific question above, I don't have a big > problem with reusing ScanKey this way, but I do agree that using > RestrictInfo for this would be a cr

Re: [HACKERS] multibyte-character aware support for function "downcase_truncate_identifier()"

On Sun, Nov 21, 2010 at 4:41 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jul 7, 2010 at 10:07 AM, Tom Lane wrote: >>> IIRC this is intentional.  Please consult the archives for previous >>> discussions. > >> Why would this be intentional? > > Well, it's intentional for lack of any infra

Re: [HACKERS] Spread checkpoint sync

On 11/20/10 6:11 PM, Jeff Janes wrote: > True, but I think that changing these from their defaults is not > considered to be a dark art reserved for kernel hackers, i.e they are > something that sysadmins are expected to tweak to suite their work > load, just like the shmmax and such. I disagree.

Re: [HACKERS] Spread checkpoint sync

On Sunday 21 November 2010 23:19:30 Martijn van Oosterhout wrote: > For a similar problem we had (kernel buffering too much) we had success > using the fadvise and madvise WONTNEED syscalls to force the data to > exit the cache much sooner than it would otherwise. This was on Linux > and it had the

Re: [HACKERS] Fwd: What do these terms mean in the SOURCE CODE?

Thanks for that informative article. :) Taught me a few new points about Eclipse :) On Sun, Nov 21, 2010 at 2:29 PM, Leonardo Francalanci wrote: > > Here's my single biggest tip for newcomers to the Postgres source: > > if you don't use ctags, glimpse, or some other tool that can quickly > > sh

Re: [HACKERS] knngist - 0.8

Robert Haas writes: > 2010/11/12 Teodor Sigaev : >> My variants informs GiST by SK_ORDER flags and consistentFn looks at >> strategy number (strategy numbers are different for different purposes). > Yeah. At ten thousand feet, I think the open design question here is > to what extent it's OK to

Re: [HACKERS] Spread checkpoint sync

On Sun, Nov 21, 2010 at 04:54:00PM -0500, Greg Smith wrote: > Ultimately what I want to do here is some sort of smarter write-behind > sync operation, perhaps with a LRU on relations with pending fsync > requests. The idea would be to sync relations that haven't been touched > in a while in

Re: [HACKERS] Spread checkpoint sync

Robert Haas wrote: Doing all the writes and then all the fsyncs meets this requirement trivially, but I'm not so sure that's a good idea. For example, given files F1 ... Fn with dirty pages needing checkpoint writes, we could do the following: first, do any pending fsyncs for files not among F1

[HACKERS] Experimental JDBC driver

Hello, I last time added some features to JDBC driver meking in some way experimental driver, it could be quite usefull, but if it's possible I would like to ask for some reviews and tests. Maybe some ideas from this will be handly. Beacause the chageset is huge, I don't give patch set, but onl

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: > On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas wrote: >> Ah, nuts.  I see now there's a v7.  Never mind... > > OK. I looked at the right version, now. Hopefully. Yeah, that was the most recent one and I linked it in the commit fest application. Given the very fast feedback

Re: [HACKERS] multibyte-character aware support for function "downcase_truncate_identifier()"

Robert Haas writes: > On Wed, Jul 7, 2010 at 10:07 AM, Tom Lane wrote: >> IIRC this is intentional.  Please consult the archives for previous >> discussions. > Why would this be intentional? Well, it's intentional for lack of any infrastructure that would allow a more spec-compliant approach.

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

On 11/21/2010 12:31 AM, Terry Laurenzo wrote: I copied the 5 sample documents from json.org 's example section for these tests. These are loaded into a table with a varchar column 1000 times each (so the test table has 5000 rows in it). In all situations, the binary encod

Re: [HACKERS] multibyte-character aware support for function "downcase_truncate_identifier()"

On Wed, Jul 7, 2010 at 10:07 AM, Tom Lane wrote: > Rajanikant Chirmade writes: >> Every identifier is downcase & truncated by function >> "downcase_truncate_identifier()" >> before using it. > >> But since the function "downcase_truncate_identifier()" is not >> multibyte-charecter aware, >> it is

Re: [HACKERS] Tab completion for view triggers in psql

On Sun, Nov 21, 2010 at 03:36:58PM -0500, Robert Haas wrote: > On Sun, Nov 21, 2010 at 1:07 PM, David Fetter wrote: > > On Fri, Oct 29, 2010 at 08:33:00AM -0700, David Fetter wrote: > >> On Tue, Oct 26, 2010 at 11:55:07AM +0900, Itagaki Takahiro wrote: > >> > On Tue, Oct 26, 2010 at 11:34 AM, Davi

Re: [HACKERS] a new problem in MERGE

On Sun, Nov 14, 2010 at 2:41 PM, Greg Smith wrote: > Boxuan Zhai wrote: >> >> I have plan to fix the above two bugs together. (in fact, I have already >> started coding in merge_v202 edition). My question is how should I make my >> update be consistent with yours. Is it possible for you to give me

Re: [HACKERS] Tab completion for view triggers in psql

On Sun, Nov 21, 2010 at 1:07 PM, David Fetter wrote: > On Fri, Oct 29, 2010 at 08:33:00AM -0700, David Fetter wrote: >> On Tue, Oct 26, 2010 at 11:55:07AM +0900, Itagaki Takahiro wrote: >> > On Tue, Oct 26, 2010 at 11:34 AM, David Fetter wrote: >> > >> Do we need to 'add' it? >> > > Possibly.  My

Re: [HACKERS] Improving prep_buildtree used in VPATH builds

On Fri, Nov 19, 2010 at 7:50 AM, Alvaro Herrera wrote: > Excerpts from Greg Smith's message of vie nov 19 01:52:34 -0300 2010: > >> I'd think that if configure takes >> longer than it has to because the system is heavily loaded, the amount >> compilation time is going to suffer from that would alw

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

On Sun, Nov 21, 2010 at 12:31 AM, Terry Laurenzo wrote: > What we see from this is that parsing JSON text and generating a binary > representation is cheap, representing approximately 10% of the base case > time.  Conversely, anything that involves generating JSON text is expensive, > accounting f

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: > So, attached is a proposed patch that just adds CheckSetNamespace() > and makes the existing SET SCHEMA commands use it. Barring > objections, I'll go ahead and commit this part. Thank you for applying the new function to the existing code paths, that was needed as soon as

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Nov 21, 2010, at 1:03 PM, David Fetter wrote: > Should this really error out? It's just a NOOP, so perhaps a NOTICE > would be more appropriate. Perhaps, but the purpose of this patch is to streamline the code, not change the behavior. ...Robert -- Sent via pgsql-hackers mailing list (pgsq

Re: [HACKERS] Tab completion for view triggers in psql

On Fri, Oct 29, 2010 at 08:33:00AM -0700, David Fetter wrote: > On Tue, Oct 26, 2010 at 11:55:07AM +0900, Itagaki Takahiro wrote: > > On Tue, Oct 26, 2010 at 11:34 AM, David Fetter wrote: > > >> Do we need to 'add' it? > > > Possibly.  My understanding is that it couldn't really replace it. > > >

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sun, Nov 21, 2010 at 07:53:57AM -0500, Robert Haas wrote: > On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas wrote: > > Ah, nuts.  I see now there's a v7.  Never mind... > > OK. I looked at the right version, now. Hopefully. > > It seems we have no regression tests at all for any of the existi

Re: [HACKERS] patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

On Nov 20, 2010, at 9:31 PM, Terry Laurenzo wrote: > Assuming that the JSON datatype (at a minimum) normalizes text for storage, > then the text storage option accounts for about the most expensive path but > with none of the benefits of an internal binary form (smaller size, ability > to cheap

Re: [HACKERS] Spread checkpoint sync

Jeff Janes wrote: And for very large memory systems, even 1% may be too much to cache (dirty*_ratio can only be set in integer percent points), so recent kernels introduced dirty*_bytes parameters. I like these better because they do what they say. With the dirty*_ratio, I could never figure ou

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas wrote: > Ah, nuts.  I see now there's a v7.  Never mind... OK. I looked at the right version, now. Hopefully. It seems we have no regression tests at all for any of the existing SET SCHEMA commands. This seems like a good time to correct that over

Re: Latches with weak memory ordering (Re: [HACKERS] max_wal_senders must die)

On Sat, Nov 20, 2010 at 4:07 PM, Tom Lane wrote: > Robert Haas writes: >> So what DO we need to guard against here? > > I think the general problem can be stated as "process A changes two or > more values in shared memory in a fairly short span of time, and process > B, which is concurrently exam

Re: [HACKERS] Fwd: patch: format function - fixed oid

On Nov 21, 2010, at 1:09 AM, Pavel Stehule wrote: >> >> OK, I've committed this, after a fairly heavy rewrite. > > thank you very much Ah, nuts. I forgot to bump catversion. ...Robert

Re: [HACKERS] Fwd: What do these terms mean in the SOURCE CODE?

> Here's my single biggest tip for newcomers to the Postgres source: > if you don't use ctags, glimpse, or some other tool that can quickly > show you all references to a given identifier, go out and get one. > It's one of the easiest ways to learn about things. I guess Eclipse is the best to