[HACKERS] missing entry in GucSource_Names

2009-10-13 Thread Jeff Davis
It appears that the patch here: http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=a30fa4ca33d055c46bebc0e5c701d5b4fd27814d missed adding PGC_S_DATABASE_USER to a few locations, most notably GucSource_Names, where the PGC_S_SESSION now points off the end of the array. Patch attached.

Re: [HACKERS] Skip WAL in ALTER TABLE

2009-10-13 Thread Simon Riggs
On Tue, 2009-10-13 at 11:39 +0900, Itagaki Takahiro wrote: We can skip writing WAL during COPY and CLUSTER if archive_mode is off, but we don't use the skipping during tables rewrites in ALTER TABLE. Also we don't use BulkInsertState there. Is it possible to use WAL-skipping and

Re: [HACKERS] transaction_isolation vs. default_transaction_isolation

2009-10-13 Thread Peter Eisentraut
On Mon, 2009-10-12 at 22:22 -0700, Jeff Davis wrote: On Mon, 2009-10-12 at 22:13 -0700, Josh Berkus wrote: However, for *two* settings, and two settings only, we distinguish that by naming an identical setting default_* in postgresql.conf. This is confusing and inconsistent with the rest

[HACKERS] SQL Standard Committee

2009-10-13 Thread Simon Riggs
Please can someone pass me details on/off-list about joining the SQL Standard Committee, as discussed at developer meeting in May. Thanks, -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] SQL Standard Committee

2009-10-13 Thread Peter Eisentraut
On Tue, 2009-10-13 at 10:18 +0100, Simon Riggs wrote: Please can someone pass me details on/off-list about joining the SQL Standard Committee, as discussed at developer meeting in May. I have replied to Simon off-list about the details, which had also been forwarded to the funds group. The

Re: [HACKERS] Concurrency testing

2009-10-13 Thread Simon Riggs
On Wed, 2009-10-07 at 13:07 -0400, Alvaro Herrera wrote: David Fetter wrote: I seem to recall that there were some patches to get psql to help with such things, but they didn't go in. Time to revive them? Yeah, the API they implemented wasn't ideal, so there was some discussion that

Re: [HACKERS] COPY enhancements

2009-10-13 Thread Emmanuel Cecchet
Tom Lane wrote: Ultimately, there's always going to be a tradeoff between speed and flexibility. It may be that we should just say if you want to import dirty data, it's gonna cost ya and not worry about the speed penalty of subtransaction-per-row. But that still leaves us with the 2^32 limit.

Re: [HACKERS] Re: [GENERAL] contrib/plantuner - enable PostgreSQL planner hints

2009-10-13 Thread Kevin Grittner
Robert Haas robertmh...@gmail.com wrote: I sometimes want to know what the planner thinks the cost of some plan other than the one actually selected would be. Another DBMS I used for years had a way to turn on an *extremely* verbose mode for their planner; it showed everything it considered

Re: [HACKERS] Re: [GENERAL] contrib/plantuner - enable PostgreSQL planner hints

2009-10-13 Thread Bruce Momjian
Kevin Grittner wrote: Robert Haas robertmh...@gmail.com wrote: I sometimes want to know what the planner thinks the cost of some plan other than the one actually selected would be. Another DBMS I used for years had a way to turn on an *extremely* verbose mode for their planner; it

Re: [HACKERS] missing entry in GucSource_Names

2009-10-13 Thread Alvaro Herrera
Jeff Davis wrote: It appears that the patch here: http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=a30fa4ca33d055c46bebc0e5c701d5b4fd27814d missed adding PGC_S_DATABASE_USER to a few locations, most notably GucSource_Names, where the PGC_S_SESSION now points off the end of the

Re: [HACKERS] COPY enhancements

2009-10-13 Thread Tom Lane
Emmanuel Cecchet m...@frogthinker.org writes: - speed with error logging best effort: no use of sub-transactions but errors that can safely be trapped with pg_try/catch (no index violation, There aren't any. You can *not* put a try/catch around arbitrary code without a subtransaction. Don't

Re: [HACKERS] EvalPlanQual seems a tad broken

2009-10-13 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote: 5. Now commit in the second session. First session resumes and prints f1 | f2 | f3 | f4 +++- 1 | 1 | 1 | 111 1 | 1 | 1 | 112 2 | 42 | 2 | 113 2 | 42 | 2 | 114 2 | 42 | 2 | 113 2 | 42 | 2 | 114 (6 rows) Of

Re: [HACKERS] EvalPlanQual seems a tad broken

2009-10-13 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov writes: Is this related to issue 4593? No, not directly. Now that locking is done in a separate plan node, we could think about addressing #4593 by switching the order of the LockRows and Sort plan nodes, but that has nothing to do with how well

[HACKERS] Client application name

2009-10-13 Thread Dave Page
A useful feature found in other DBMSs such as MS SQL Server that has been requested on these lists a few times, is the ability for a client application to report its name to the server. This information may then be presented in logs, activity reports and so on to aid debugging and help the

Re: [HACKERS] Client application name

2009-10-13 Thread Alvaro Herrera
Dave Page wrote: The attached patch is a first quick cut of the basic functionality to do this. Currently, it makes the following changes: Couple of thoughts, - should we use argv[0] automatically in libpq unless overridden? - should we reject funny chars such as \n? (hopefully \0 won't be a

Re: [HACKERS] Client application name

2009-10-13 Thread Andrew Dunstan
Dave Page wrote: My questions to the group are: - Is my approach reasonable? - What interface should I include in libpq? On the second question, obviously the user can call SET to set a value, as I've done for now in psql, however in other DBMSs, it may be set in the connection string. My

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Dave Page wrote: The attached patch is a first quick cut of the basic functionality to do this. Currently, it makes the following changes: Couple of thoughts, - should we use argv[0] automatically in libpq

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan and...@dunslane.net wrote: Doing it with a GUC will not be nearly so useful as having it in the wire protocol, IMNSHO. Just one example: it wouldn't be present in connection records, because it wouldn't be set yet. I quite like the flexibility

Re: [HACKERS] Client application name

2009-10-13 Thread Alvaro Herrera
Dave Page wrote: On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: - should we reject funny chars such as \n? (hopefully \0 won't be a problem) Is there any need? I can't see that it would do any harm other than maybe messing up some query output - and

Re: [HACKERS] Client application name

2009-10-13 Thread Andrew Dunstan
Dave Page wrote: On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan and...@dunslane.net wrote: Doing it with a GUC will not be nearly so useful as having it in the wire protocol, IMNSHO. Just one example: it wouldn't be present in connection records, because it wouldn't be set yet. I

Re: [HACKERS] Buffer usage in EXPLAIN and pg_stat_statements (review)

2009-10-13 Thread Tom Lane
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes: Here is an update version of buffer usage patch. I started to look at this patch, and I have a few comments: 1. I was expecting this patch to get rid of ShowBufferUsage() and friends altogether, instead of adding yet more static counters

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan and...@dunslane.net wrote: From time to time people ask for scalar variable facility. ISTM what you're trying to do is just a special case of that. Maybe we could approach it by providing a builtin (and non-removable) custom_variable_classes

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: - Is my approach reasonable? - What interface should I include in libpq? I thought the plan was to have libpq look at an environment variable, compare PGCLIENTENCODING for example. I'm not convinced psql should be involved in the logic at all --- if it is,

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: - should we use argv[0] automatically in libpq unless overridden? How can I get to it from libpq? You can't. regards, tom lane -- Sent via

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan and...@dunslane.net wrote: From time to time people ask for scalar variable facility. I'm not sure that's really related to this It isn't; I think Andrew confused this thread with the one where someone wanted

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: - Is my approach reasonable? - What interface should I include in libpq? I thought the plan was to have libpq look at an environment variable, I wasn't aware we had a plan :-) compare

Re: [HACKERS] Client application name

2009-10-13 Thread Andrew Dunstan
Tom Lane wrote: Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan and...@dunslane.net wrote: From time to time people ask for scalar variable facility. I'm not sure that's really related to this It isn't; I think Andrew confused

[HACKERS] Wire protocol docs

2009-10-13 Thread Dave Page
On http://www.postgresql.org/docs/8.4/interactive/protocol.html we say: Higher level features built on this protocol (for example, how libpq passes certain environment variables when the connection is established) are covered elsewhere. I cannot find anything that is obviously 'elsewhere' in the

Re: [HACKERS] Client application name

2009-10-13 Thread Kris Jurka
On Tue, 13 Oct 2009, Dave Page wrote: A useful feature found in other DBMSs such as MS SQL Server that has been requested on these lists a few times, is the ability for a client application to report its name to the server. This information may then be presented in logs, activity reports and

Re: [HACKERS] Client application name

2009-10-13 Thread Massa, Harald Armin
I can have libpq look at the environment as it does for PGCLIENTENCODING, but I'd certainly like to be able to use the connection string as well, as environment variables are not really the another challenge with the Environment variable: they are (at least on windows) usually set for one logged

Re: [HACKERS] COPY enhancements

2009-10-13 Thread Emmanuel Cecchet
Tom Lane wrote: Emmanuel Cecchet m...@frogthinker.org writes: - speed with error logging best effort: no use of sub-transactions but errors that can safely be trapped with pg_try/catch (no index violation, There aren't any. You can *not* put a try/catch around arbitrary code without

Re: [HACKERS] COPY enhancements

2009-10-13 Thread Dimitri Fontaine
Emmanuel Cecchet m...@frogthinker.org writes: Tom was also suggesting 'refactoring COPY into a series of steps that the user can control'. What would these steps be? Would that be per row and allow to discard a bad tuple? The idea is to have COPY usable from a general SELECT query so that the

Re: [HACKERS] Wire protocol docs

2009-10-13 Thread Abhijit Menon-Sen
At 2009-10-13 17:25:15 +0100, dp...@pgadmin.org wrote: I cannot find anything that is obviously 'elsewhere' in the docs - does that need fixing, or do my searching skills need improving? I don't know, but… *starts reading source code* :-) Look at what fe-protocol3.c:build_startup_packet()

Re: [HACKERS] Wire protocol docs

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 5:41 PM, Abhijit Menon-Sen a...@toroid.org wrote: At 2009-10-13 17:25:15 +0100, dp...@pgadmin.org wrote: I cannot find anything that is obviously 'elsewhere' in the docs - does that need fixing, or do my searching skills need improving? I don't know, but… *starts

Re: [HACKERS] Client application name

2009-10-13 Thread Andres Freund
On Tuesday 13 October 2009 18:30:54 Massa, Harald Armin wrote: I can have libpq look at the environment as it does for PGCLIENTENCODING, but I'd certainly like to be able to use the connection string as well, as environment variables are not really the another challenge with the Environment

Re: [HACKERS] Client application name

2009-10-13 Thread Robert Haas
On Tue, Oct 13, 2009 at 12:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: - Is my approach reasonable? - What interface should I include in libpq? I thought the plan was to have libpq look at an environment variable, compare PGCLIENTENCODING for example.  I'm

Re: [HACKERS] COPY enhancements

2009-10-13 Thread Tom Lane
Emmanuel Cecchet m...@asterdata.com writes: Tom Lane wrote: There aren't any. You can *not* put a try/catch around arbitrary code without a subtransaction. Don't even think about it. Well then why the tests provided with the patch are working? Because they carefully exercise only a tiny

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: What happens if we want to change the application name after the fact? As long as it's a GUC variable you can just do SET. I think the point of discussion is what is the best convention for getting it set initially. regards, tom

Re: [HACKERS] Client application name

2009-10-13 Thread Jaime Casanova
On Tue, Oct 13, 2009 at 11:55 AM, Robert Haas robertmh...@gmail.com wrote: What happens if we want to change the application name after the fact?  Consider the case where there is a connection pooler between the database and application, for example. good point... -- Atentamente, Jaime

Re: [HACKERS] Wire protocol docs

2009-10-13 Thread Greg Smith
On Tue, 13 Oct 2009, Dave Page wrote: On http://www.postgresql.org/docs/8.4/interactive/protocol.html we say: Higher level features built on this protocol (for example, how libpq passes certain environment variables when the connection is established) are covered elsewhere.

Re: [HACKERS] SQL Standard Committee

2009-10-13 Thread Josh Berkus
Peter, The current status is that no one at INCITS is replying to my emails. If someone preferably in the right time zone is interested in phoning them up or pursuing other means of getting an answer out of them, please let me know privately. I can't give this the attention it apparently

Re: [HACKERS] Wire protocol docs

2009-10-13 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: Right. My complaint though, is that the docs imply that the info on how those values get set is in the docs somewhere, which appears to be incorrect. The libpq documentation does cover the fact that libpq uses those variables to establish initial settings.

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: - Is my approach reasonable? I thought the plan was to have libpq look at an environment variable, I wasn't aware we had a plan :-) There was some

Re: [HACKERS] transaction_isolation vs. default_transaction_isolation

2009-10-13 Thread Josh Berkus
Yeah, they basically have semantics specified by the SQL standard that are not compatible with anything else in GUC land. They are more like SET LOCAL settings, but again not quite. Mind you, transaction_isolation and transaction_read_only aren't documented anywhere in our docs *as

Re: [HACKERS] Wire protocol docs

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 6:24 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: Right. My complaint though, is that the docs imply that the info on how those values get set is in the docs somewhere, which appears to be incorrect. The libpq documentation does cover the

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 6:38 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: - Is my approach reasonable? I thought the plan was to have libpq look at an

Re: [HACKERS] Re: [GENERAL] contrib/plantuner - enable PostgreSQL planner hints

2009-10-13 Thread Jeff Davis
On Tue, 2009-10-13 at 09:14 -0500, Kevin Grittner wrote: Now that we can generate EXPLAIN output in more structured formats, perhaps we could think about adding an extremely verbose mode where the planner would think out loud as a whole separate section from where we show the chosen plan? Tom

Re: [HACKERS] Re: [GENERAL] contrib/plantuner - enable PostgreSQL planner hints

2009-10-13 Thread Joshua D. Drake
On Tue, 2009-10-13 at 11:26 -0700, Jeff Davis wrote: On Tue, 2009-10-13 at 09:14 -0500, Kevin Grittner wrote: Now that we can generate EXPLAIN output in more structured formats, perhaps we could think about adding an extremely verbose mode where the planner would think out loud as a whole

Re: [HACKERS] Re: [GENERAL] contrib/plantuner - enable PostgreSQL planner hints

2009-10-13 Thread Robert Haas
On Tue, Oct 13, 2009 at 10:14 AM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Robert Haas robertmh...@gmail.com wrote: I sometimes want to know what the planner thinks the cost of some plan other than the one actually selected would be. Another DBMS I used for years had a way to turn

Re: [HACKERS] Client application name

2009-10-13 Thread Jaime Casanova
On Tue, Oct 13, 2009 at 1:07 PM, Dave Page dp...@pgadmin.org wrote: Oh, and apologies to Jaime who I just noticed had volunteered to work on this :-( never mind... i get blocked for the ugliness of the libpq api connect functions... and my first attempt to solve that was seriously broken...

Re: [HACKERS] Client application name

2009-10-13 Thread Dave Page
On Tue, Oct 13, 2009 at 9:13 PM, Jaime Casanova jcasa...@systemguards.com.ec wrote: On Tue, Oct 13, 2009 at 1:07 PM, Dave Page dp...@pgadmin.org wrote: Oh, and apologies to Jaime who I just noticed had volunteered to work on this :-( never mind... i get blocked for the ugliness of the libpq

Re: [HACKERS] Unicode UTF-8 table formatting for psql text output

2009-10-13 Thread Tom Lane
Roger Leigh rle...@codelibre.net writes: The attached updated patch renames all user-visible uses of utf8 to unicode. It also updates the documentation regarding locale to psql client character set encoding so the docs now match the code exactly. Applied with light editorialization. The

Re: [HACKERS] Client application name

2009-10-13 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Tue, Oct 13, 2009 at 9:13 PM, Jaime Casanova jcasa...@systemguards.com.ec wrote: besides, as Robert mention, because of pooler connections using a GUC is more appropiate... I'd like both options to be available to the programmer. We have several things

Re: [HACKERS] Re: [GENERAL] contrib/plantuner - enable PostgreSQL planner hints

2009-10-13 Thread Greg Smith
On Tue, 13 Oct 2009, Robert Haas wrote: An exhaustive dump of everything the planner has considered is going to be a LOT of data, and I don't really want to have to set up a graphical visualization tool every time I have a planning question. I am a command-line kind of guy... Wouldn't this

Re: [HACKERS] Triggers on columns

2009-10-13 Thread Peter Eisentraut
On Sat, 2009-10-10 at 00:04 +0300, Peter Eisentraut wrote: On Mon, 2009-09-14 at 18:58 +0900, Itagaki Takahiro wrote: Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp wrote: Ok, the attached patch implements standard-compliant version of column trigger. Here is an updated version

Re: [HACKERS] [PATCH] Largeobject access controls

2009-10-13 Thread Tom Lane
KaiGai Kohei kai...@ak.jp.nec.com writes: The attached patch is the revised one for largeobejct access controls, because it conflicted to the GRANT/REVOKE ON ALL xxx IN SCHEMA. I started to look through this patch with the hope of committing it, but found out that it's not really ready. The

Re: [HACKERS] [PATCH] Largeobject access controls

2009-10-13 Thread KaiGai Kohei
Tom Lane wrote: KaiGai Kohei kai...@ak.jp.nec.com writes: The attached patch is the revised one for largeobejct access controls, because it conflicted to the GRANT/REVOKE ON ALL xxx IN SCHEMA. I started to look through this patch with the hope of committing it, but found out that it's not