Re: [HACKERS] Update obsolete text in indexam.sgml

> From: Tom Lane [mailto:t...@sss.pgh.pa.us] > "Etsuro Fujita" writes: > > ISTM it would be better to update the text about index cost estimation in > > indexam.sgml. Please find attached a patch. > > I'm not too thrilled with the proposed patch. In the first place, I > don't think it's necessa

Re: [HACKERS] Statistics and selectivity estimation for ranges

On Mon, 2012-11-05 at 11:12 -0300, Alvaro Herrera wrote: > What's going on with this patch? I haven't seen any activity in a > while. Should I just move this to the next commitfest? Sorry, I dropped the ball here. I will still review it, whether it makes this commitfest or not. Regards,

Re: [HACKERS] Arguments to foreign tables?

On Sun, 2012-11-04 at 15:13 -0500, Tom Lane wrote: > Jeff Davis writes: > > Is there any fundamental or philosophical reason why a foreign table > > can't accept arguments? > > That isn't a table; it's some sort of function. Now that we have > LATERAL, there is no good reason to contort SQL's sy

Re: [HACKERS] Doc patch, distinguish sections with an empty row in error code table

On 11/05/2012 02:40:12 PM, Tom Lane wrote: > Robert Haas writes: > > On Fri, Oct 26, 2012 at 10:03 AM, Karl O. Pinc > wrote: > >> This patch adds an empty row before each section header > >> in the error codes table in the docs. > > > This doesn't seem like a particularly good idea to me, but w

Re: [HACKERS] Logical to physical page mapping

On Mon, Oct 29, 2012 at 07:05:39AM -0400, Robert Haas wrote: > Yet another idea we've tossed around is to make only vacuum records > include FPWs, and have the more common heap insert/update/delete > operations include enough information that they can still be applied > correctly even if the page h

Re: [HACKERS] Pg_upgrade speed for many tables

On 11/05/2012 08:52 PM, Bruce Momjian wrote: On Mon, Nov 5, 2012 at 05:39:40PM -0800, Josh Berkus wrote: Sorry, I should've said psql --single-transaction. Although that isn't going to work either given the presence of \connect commands in the script. I wonder whether pg_dumpall ought to hav

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 05:39:40PM -0800, Josh Berkus wrote: > > > Sorry, I should've said psql --single-transaction. Although that isn't > > going to work either given the presence of \connect commands in the > > script. I wonder whether pg_dumpall ought to have some sort of "one > > transactio

Re: [HACKERS] RFC: Timing Events

> Huh? The typical use-case is to enable it for all sessions by > including it in shared_preload_libraries. That doesn't require any > particular session to be superuser. (If you're superuser you can then > turn it *off* in your session, should you wish.) It's not practical to have auto-explai

Re: [HACKERS] Pg_upgrade speed for many tables

> Sorry, I should've said psql --single-transaction. Although that isn't > going to work either given the presence of \connect commands in the > script. I wonder whether pg_dumpall ought to have some sort of "one > transaction per database please" option. pg_dumpall ought to support -Fc output

Re: [HACKERS] Pg_upgrade speed for many tables

Bruce Momjian writes: > That could generate a lot of WAL files if used regularly. :-( Does > SELECT txid_current() generate WAL? I think it does. Well, it assigns a XID. I'm not sure it'd be a good idea to assume that the mere act of doing that, without actually writing anything to tables, wo

Re: [HACKERS] alter table tablename add column - breaks pl/pgsql function returns tablename

Palle Girgensohn writes: > Ah, sorry. Other sessions get the error immediately as well though. Would > input parameters matter, or is it just the return type? I'll see if I can > find a test case that breaks permanently, but I'm probably mistaken about > that bit then. It's not the return val

Re: [HACKERS] What are the advantages of not being able to access multiple databases with one connection?

On Mon, Nov 5, 2012 at 11:33 AM, Robert Haas wrote: > On Tue, Oct 30, 2012 at 8:37 AM, crocket wrote: >> MySQL permits a connection to access multiple databases. >> But Postgresql restricts a connection to one database. >> I think postgresql database connection is somewhat limited. >> >> Is it an

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 12:14 PM, Tom Lane wrote: > Bruce Momjian writes: >> Magnus reported that a customer with a million tables was finding >> pg_upgrade slow. > > You sure there's not an O(N^2) issue in there somewhere? There certainly will be before he gets to a million, but it probably does

Re: [HACKERS] alter table tablename add column - breaks pl/pgsql function returns tablename

5 nov 2012 kl. 22:23 skrev Tom Lane : > Palle Girgensohn writes: >> Please note that this problem does not go away by disconnecting and >> reconnecting, and other sessions get the error immediately, so the claim >> that it is bound to a session is false. > > Huh? The test case you provided

Re: [HACKERS] What are the advantages of not being able to access multiple databases with one connection?

> functional gap here. I am not sure I'd bother implementing the > multi-database concept today if we didn't have it already ... but it > seems kind of pointless to rip it out given that it's already there. It's very useful for webhosts. You can give each user their own private database and not

Re: [HACKERS] Synchronous commit not... synchronous?

On Mon, Nov 5, 2012 at 1:19 PM, Robert Haas wrote: > Well, feel free to make a suggestion. We could have a mode where a > commit, once initiated, is not user-cancellable, but that doesn't seem > like a usability improvement to me. That just forces somebody to > bounce the server in a situation w

Re: [HACKERS] foreign key locks

Alvaro Herrera writes: >> FOR NON KEY UPDATE >> FOR KEY UPDATE >> >> KEY is the default, so FOR UPDATE is a synonym of FOR KEY UPDATE > > Not really sure about the proposed syntax, but yes clearly we need some > other syntax to mean "FOR NON KEY UPDATE". I would rather keep FOR > UPDATE to mean

Re: [HACKERS] alter table tablename add column - breaks pl/pgsql function returns tablename

5 nov 2012 kl. 19:36 skrev Robert Haas : > On Thu, Nov 1, 2012 at 12:14 AM, Amit kapila wrote: >>> Is this very hard to fix? >> >> Currently the compiled body is not discarded on DDL's, so I believe it is >> not a bug as per current implementation. >> However it can be thought of as a new

Re: [HACKERS] Deprecations in authentication

On 11/05/2012 04:54 PM, Magnus Hagander wrote: On Mon, Nov 5, 2012 at 10:21 PM, Andrew Dunstan > wrote: On 11/05/2012 01:53 PM, Magnus Hagander wrote: On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan mailto:and...@dunslane.net>

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 1:39 PM, Robert Haas wrote: > On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera > wrote: >> AFAIR any transaction that modifies catalogs gets sync commit forcibly, >> regardless of the setting. And sync commit means you get to wait for >> all previous transactions to be flus

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 05, 2012 at 04:42:56PM -0500, Bruce Momjian wrote: > On Mon, Nov 5, 2012 at 04:39:27PM -0500, Robert Haas wrote: > > On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera > > wrote: > > > AFAIR any transaction that modifies catalogs gets sync commit forcibly, > > > regardless of the setting

Re: [HACKERS] Deprecations in authentication

On Mon, Nov 5, 2012 at 10:21 PM, Andrew Dunstan wrote: > > On 11/05/2012 01:53 PM, Magnus Hagander wrote: > > >> On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan > and...@dunslane.net>> wrote: >> >> >> On 11/05/2012 12:13 PM, Magnus Hagander wrote: >> >> >> >> >> http://www.pgbuildfarm

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 4:42 PM, Bruce Momjian wrote: > On Mon, Nov 5, 2012 at 04:39:27PM -0500, Robert Haas wrote: >> On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera >> wrote: >> > AFAIR any transaction that modifies catalogs gets sync commit forcibly, >> > regardless of the setting. And sync c

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 04:39:27PM -0500, Robert Haas wrote: > On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera > wrote: > > AFAIR any transaction that modifies catalogs gets sync commit forcibly, > > regardless of the setting. And sync commit means you get to wait for > > all previous transaction

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 4:33 PM, Alvaro Herrera wrote: > AFAIR any transaction that modifies catalogs gets sync commit forcibly, > regardless of the setting. And sync commit means you get to wait for > all previous transactions to be flushed as well. So simply creating a > temp table ought to do

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 06:33:16PM -0300, Alvaro Herrera wrote: > Bruce Momjian escribió: > > On Mon, Nov 5, 2012 at 04:14:47PM -0500, Robert Haas wrote: > > > On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote: > > > > Or have options for pg_dump and pg_restore to insert "set > > > > synchronous_c

Re: [HACKERS] install zic binary

On Tue, Oct 23, 2012 at 12:40:54PM -0200, Euler Taveira wrote: > Hi, > > Every year we have a ton of questions about updating the time zone data in > Brazil (our politics decided to do it at 90min at the second half). Problem is > that there is not sufficient time to release a new minor version wi

Re: [HACKERS] Pg_upgrade speed for many tables

Bruce Momjian escribió: > On Mon, Nov 5, 2012 at 04:14:47PM -0500, Robert Haas wrote: > > On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote: > > > Or have options for pg_dump and pg_restore to insert "set > > > synchronous_commit=off" into the SQL stream? > > > > It would be kind of neat if we ha

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 01:23:58PM -0800, Jeff Janes wrote: > On Mon, Nov 5, 2012 at 1:14 PM, Robert Haas wrote: > > On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote: > >> Or have options for pg_dump and pg_restore to insert "set > >> synchronous_commit=off" into the SQL stream? > > > > It would

Re: [HACKERS] to_char timezone

On Sun, Oct 21, 2012 at 05:40:40PM -0400, Andrew Dunstan wrote: > > I'm not sure if this has come up before. > > A client was just finding difficulties because to_char() doesn't > support formatting the timezone part of a timestamptz numerically > (i.e. as +-hhmm) instead of using a timezone name

Re: [HACKERS] alter table tablename add column - breaks pl/pgsql function returns tablename

Palle Girgensohn writes: > Please note that this problem does not go away by disconnecting and > reconnecting, and other sessions get the error immediately, so the claim that > it is bound to a session is false. Huh? The test case you provided certainly doesn't exhibit any such behavior. I g

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 1:14 PM, Robert Haas wrote: > On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote: >> Or have options for pg_dump and pg_restore to insert "set >> synchronous_commit=off" into the SQL stream? > > It would be kind of neat if we had a command that would force all > previously-as

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 04:14:47PM -0500, Robert Haas wrote: > On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote: > > Or have options for pg_dump and pg_restore to insert "set > > synchronous_commit=off" into the SQL stream? > > It would be kind of neat if we had a command that would force all > p

Re: [HACKERS] Deprecations in authentication

On 11/05/2012 01:53 PM, Magnus Hagander wrote: On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan > wrote: On 11/05/2012 12:13 PM, Magnus Hagander wrote: http://www.pgbuildfarm.org/cgi-bin/show_status.pl ...it seems there are LOTS of machin

Re: [HACKERS] Synchronous commit not... synchronous?

On Mon, Nov 5, 2012 at 2:59 PM, Daniel Farina wrote: > On Sun, Nov 4, 2012 at 6:00 PM, Robert Haas wrote: >> On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer wrote: >>> * Daniel Farina: The idea of canceling a COMMIT statement causing a COMMIT seems pretty strange to me. >>> >>> Cancelin

Re: [HACKERS] Doc patch, distinguish sections with an empty row in error code table

On Mon, Nov 5, 2012 at 3:40 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Oct 26, 2012 at 10:03 AM, Karl O. Pinc wrote: >>> This patch adds an empty row before each section header >>> in the error codes table in the docs. > >> This doesn't seem like a particularly good idea to me, but wha

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 4:07 PM, Jeff Janes wrote: > Or have options for pg_dump and pg_restore to insert "set > synchronous_commit=off" into the SQL stream? It would be kind of neat if we had a command that would force all previously-asynchronous commits to complete. It seems likely that very, v

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 01:07:45PM -0800, Jeff Janes wrote: > On Mon, Nov 5, 2012 at 12:49 PM, Bruce Momjian wrote: > > On Mon, Nov 5, 2012 at 03:30:32PM -0500, Tom Lane wrote: > >> Magnus Hagander writes: > >> > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote: > >> >> BTW, does pg_upgrade run p

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 12:49 PM, Bruce Momjian wrote: > On Mon, Nov 5, 2012 at 03:30:32PM -0500, Tom Lane wrote: >> Magnus Hagander writes: >> > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote: >> >> BTW, does pg_upgrade run pg_restore in --single-transaction mode? >> >> That would probably make

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 10:01:22PM +0100, Magnus Hagander wrote: > On Mon, Nov 5, 2012 at 9:49 PM, Bruce Momjian wrote: > > On Mon, Nov 5, 2012 at 03:30:32PM -0500, Tom Lane wrote: > > Magnus Hagander writes: > > > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote: > > >> BTW, doe

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 9:49 PM, Bruce Momjian wrote: > On Mon, Nov 5, 2012 at 03:30:32PM -0500, Tom Lane wrote: > > Magnus Hagander writes: > > > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote: > > >> BTW, does pg_upgrade run pg_restore in --single-transaction mode? > > >> That would probably

Re: [HACKERS] RFC: Timing Events

On Sun, Nov 4, 2012 at 1:35 AM, Pavel Stehule wrote: > Hello > > 2012/11/4 Satoshi Nagayasu : >>> >> >> Do we have something to add to auto_explain? > > Now I am working on expanding slow query record and auto_explain with > some locking times (lock on objects, lock on enhancing pages, other > loc

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 03:30:32PM -0500, Tom Lane wrote: > Magnus Hagander writes: > > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote: > >> BTW, does pg_upgrade run pg_restore in --single-transaction mode? > >> That would probably make synchronous_commit moot, at least for that > >> step. > > >

Re: [HACKERS] RFC: Timing Events

Josh Berkus writes: >> Do we have something to add to auto_explain? > Well, to be frank, I've never found auto-explain to be useful because of > its restriction to superuser sessions. It's an interesting > proof-of-concept, but completely useless at any production site. Huh? The typical use-ca

Re: [HACKERS] Doc patch, distinguish sections with an empty row in error code table

Robert Haas writes: > On Fri, Oct 26, 2012 at 10:03 AM, Karl O. Pinc wrote: >> This patch adds an empty row before each section header >> in the error codes table in the docs. > This doesn't seem like a particularly good idea to me, but what do > other people think? It seems like a kluge. If t

Re: [HACKERS] [PATCH] Prefetch index pages for B-Tree index scans

On Fri, Nov 2, 2012 at 09:59:08AM -0400, John Lumby wrote: > Thanks for the mentioning this posting.    Interesting. > However,    the OP describes an implementation based on libaio. > Today what we have (for linux) is librt,  which is quite different. > It is arguable worse than libaio (well act

Re: [HACKERS] Pg_upgrade speed for many tables

Magnus Hagander writes: > On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote: >> BTW, does pg_upgrade run pg_restore in --single-transaction mode? >> That would probably make synchronous_commit moot, at least for that >> step. > It doesn't use pg_restore at all - it uses the dump from pg_dumpall, wh

Re: [HACKERS] Pg_upgrade speed for many tables

On Mon, Nov 5, 2012 at 9:14 PM, Tom Lane wrote: > Bruce Momjian writes: > > Magnus reported that a customer with a million tables was finding > > pg_upgrade slow. > > You sure there's not an O(N^2) issue in there somewhere? > > I don't see anything unsafe about having pg_upgrade use > > synchr

Re: [HACKERS] Limiting the number of parameterized indexpaths created

On Mon, Nov 5, 2012 at 3:07 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Nov 5, 2012 at 2:44 PM, Tom Lane wrote: >>> Um, no. This is a useful counterexample: >>> WHERE t.a > x.c1 AND t.a < y.c2 > >> Well, OK. So maybe you also need the operator to be the same as well. > > Nope. A

Re: [HACKERS] Pg_upgrade speed for many tables

Bruce Momjian writes: > Magnus reported that a customer with a million tables was finding > pg_upgrade slow. You sure there's not an O(N^2) issue in there somewhere? > I don't see anything unsafe about having pg_upgrade use > synchronous_commit=off. No objection, but this seems unlikely to be b

[HACKERS] Pg_upgrade speed for many tables

Magnus reported that a customer with a million tables was finding pg_upgrade slow. I had never considered many table to be a problem, but decided to test it. I created a database with 2k tables like this: CREATE TABLE test1990 (x SERIAL); Running the git version of pg_upgrade on that to

Re: [HACKERS] Limiting the number of parameterized indexpaths created

Robert Haas writes: > On Mon, Nov 5, 2012 at 2:44 PM, Tom Lane wrote: >> Um, no. This is a useful counterexample: >> WHERE t.a > x.c1 AND t.a < y.c2 > Well, OK. So maybe you also need the operator to be the same as well. Nope. A counterexample to that claim is a GIN index on an array co

Re: [HACKERS] Synchronous commit not... synchronous?

On Sun, Nov 4, 2012 at 6:00 PM, Robert Haas wrote: > On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer wrote: >> * Daniel Farina: >>> The idea of canceling a COMMIT statement causing a COMMIT seems pretty >>> strange to me. >> >> Canceling commits is inherently racy, so I'm not sure if this behavior

Re: [HACKERS] Limiting the number of parameterized indexpaths created

On Mon, Nov 5, 2012 at 2:44 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Nov 5, 2012 at 2:05 PM, Tom Lane wrote: >>> There are three different parameterized paths we could create: one >>> relying on x only, one relying on y only, one relying on both. > >> Sure, but that example is differ

Re: [HACKERS] Limiting the number of parameterized indexpaths created

Robert Haas writes: > On Mon, Nov 5, 2012 at 2:05 PM, Tom Lane wrote: >> There are three different parameterized paths we could create: one >> relying on x only, one relying on y only, one relying on both. > Sure, but that example is different from the test case provided in the > bug report. I

Re: [HACKERS] Limiting the number of parameterized indexpaths created

On Mon, Nov 5, 2012 at 2:05 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Oct 30, 2012 at 5:57 PM, Tom Lane wrote: >>> I looked into the complaint of unreasonable planner runtime in bug #7626, >>> http://archives.postgresql.org/pgsql-bugs/2012-10/msg00232.php > >> You know, when I read th

Re: [HACKERS] Limiting the number of parameterized indexpaths created

Robert Haas writes: > On Tue, Oct 30, 2012 at 5:57 PM, Tom Lane wrote: >> I looked into the complaint of unreasonable planner runtime in bug #7626, >> http://archives.postgresql.org/pgsql-bugs/2012-10/msg00232.php > You know, when I read this, my first thought was ... why is this an > exponentia

Re: [HACKERS] Deprecations in authentication

On Mon, Nov 5, 2012 at 7:50 PM, Andrew Dunstan wrote: > > On 11/05/2012 12:13 PM, Magnus Hagander wrote: > >> >> >> >> http://www.pgbuildfarm.org/**cgi-bin/show_status.pl >> >> ...it seems there are LOTS of machines building with krb5, a

Re: [HACKERS] RFC: Timing Events

> I think auto_explain would help you solve such rare incidents > if it could dump several statistics into server log, including lock > waits and block reads/writes statistic per-session, for example. > > Do we have something to add to auto_explain? Well, to be frank, I've never found auto-expla

Re: [HACKERS] Deprecations in authentication

On 11/05/2012 12:13 PM, Magnus Hagander wrote: http://www.pgbuildfarm.org/cgi-bin/show_status.pl ...it seems there are LOTS of machines building with krb5, and NONE with gssapi. AFAICS there is no icon for gssapi. So your first statement is correct, but the second one isn't.

Re: [HACKERS] Deprecations in authentication

On 11/5/12 12:13 PM, Magnus Hagander wrote: > AFAICS there is no icon for gssapi. So your first statement is correct, > but the second one isn't. Yeah, for example it's used here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=smew&dt=2012-11-02%2011%3A38%3A04 -- Sent via pgsql-hackers

Re: [HACKERS] Update obsolete text in indexam.sgml

"Etsuro Fujita" writes: > ISTM it would be better to update the text about index cost estimation in > indexam.sgml. Please find attached a patch. I'm not too thrilled with the proposed patch. In the first place, I don't think it's necessary to address costing of index order-by expressions in an

Re: [HACKERS] [PATCH] PL/Python: Add spidata to all spiexceptions

On 05/11/12 19:07, Jan Urbański wrote: On 05/11/12 18:35, Robert Haas wrote: You should probably add this to the next CF so we don't forget about it. I will, as soon as I recover my community account. Added as https://commitfest.postgresql.org/action/patch_view?id=971 J -- Sent via pgsql

Re: [HACKERS] Doc patch, distinguish sections with an empty row in error code table

On Fri, Oct 26, 2012 at 10:03 AM, Karl O. Pinc wrote: > This patch adds an empty row before each section header > in the error codes table in the docs. > > I tried not putting an empty row before the first > section, but it looks better to always have > an empty row. IMO. > > File: errorcode_tabl

Re: [HACKERS] Bug in ALTER COLUMN SET DATA TYPE ?

Pavan Deolasee writes: > Please see attached patch which does what you suggested above. May be it > needs a little more commentary to record why we made this specific change. > Please let me know if you think so and want me to do that. Applied with some cosmetic adjustments and addition of a regr

Re: [HACKERS] alter table tablename add column - breaks pl/pgsql function returns tablename

On Thu, Nov 1, 2012 at 12:14 AM, Amit kapila wrote: >> Is this very hard to fix? > >Currently the compiled body is not discarded on DDL's, so I believe it is > not a bug as per current implementation. >However it can be thought of as a new feature. Seems like a bug to me. -- Robert Haa

Re: [HACKERS] Limiting the number of parameterized indexpaths created

On Tue, Oct 30, 2012 at 5:57 PM, Tom Lane wrote: > I looked into the complaint of unreasonable planner runtime in bug #7626, > http://archives.postgresql.org/pgsql-bugs/2012-10/msg00232.php > > In the given example, the indexed relation "foo" has join clauses with > 30 other relations. The code t

Re: [HACKERS] September 2012 commitfest

I said last week: > Waiting on Author: 1 > Needs Review: 10 > Ready for Committer: 7 Now there are only 9 patches "Ready for committer". All other patches have either been moved to the next commitfest, or returned with feedback. So we've made some progress, but we need a final push from committ

Re: [HACKERS] [PATCH] PL/Python: Add spidata to all spiexceptions

On 05/11/12 18:35, Robert Haas wrote: On Wed, Oct 31, 2012 at 5:33 AM, Jan Urbański wrote: On 30/10/12 22:06, Oskari Saarenmaa wrote: PL/Python maps Python SPIError exceptions with 'spidata' attribute into SQL errors. Here's an alternative patch that takes advantage of the already present (

Re: [HACKERS] [PATCH] PL/Python: Add spidata to all spiexceptions

On Wed, Oct 31, 2012 at 5:33 AM, Jan Urbański wrote: > On 30/10/12 22:06, Oskari Saarenmaa wrote: >> >> PL/Python maps Python SPIError exceptions with 'spidata' attribute into >> SQL >> errors. PL/Python also creates classes in plpy.spiexceptions for all >> known >> errors but does not initialize

Re: [HACKERS] What are the advantages of not being able to access multiple databases with one connection?

On Tue, Oct 30, 2012 at 8:37 AM, crocket wrote: > MySQL permits a connection to access multiple databases. > But Postgresql restricts a connection to one database. > I think postgresql database connection is somewhat limited. > > Is it an old and decrepit design? or does it deserve some appreciati

Re: [HACKERS] [PERFORM] out of memory

On 11/05/12 9:27 AM, Robert Haas wrote: That is, if we have a large datum that we're trying to send back to the client, could we perhaps chop off the first 50MB or so, do the encoding on that amount of data, send the data to the client, lather, rinse, repeat? I'd suggest work_mem sized chunks f

Re: [HACKERS] [PERFORM] out of memory

On Tue, Oct 30, 2012 at 6:08 AM, Tatsuo Ishii wrote: >> i have sql file (it's size are 1GB ) >> when i execute it then the String is 987098801 bytr too long for encoding >> conversion error occured . >> pls give me solution about > > You hit the upper limit of internal memory allocation limit in

Re: [HACKERS] WIP checksums patch

On Mon, Oct 29, 2012 at 4:31 PM, Jim Nasby wrote: > For whatever it's worth... we (and presumably others) still use londiste (or > Slony) as our upgrade path, so we could tolerate a cluster-wide setting. > We'd just set it when building new clusters via londiste and forget about > it. > > So I'd r

Re: [HACKERS] Deprecations in authentication

On Mon, Nov 5, 2012 at 6:10 PM, Robert Haas wrote: > On Mon, Nov 5, 2012 at 9:57 AM, Stephen Frost wrote: > > Magnus, > > > > * Magnus Hagander (mag...@hagander.net) wrote: > >> I have no idea what platform that would be. Both the standard > >> implementations of krb5 have supported gssapi since

Re: [HACKERS] Deprecations in authentication

On Mon, Nov 5, 2012 at 9:57 AM, Stephen Frost wrote: > Magnus, > > * Magnus Hagander (mag...@hagander.net) wrote: >> I have no idea what platform that would be. Both the standard >> implementations of krb5 have supported gssapi since forever. The only >> nonstandard environment we support there is

Re: [HACKERS] Deprecations in authentication

Magnus, * Magnus Hagander (mag...@hagander.net) wrote: > I have no idea what platform that would be. Both the standard > implementations of krb5 have supported gssapi since forever. The only > nonstandard environment we support there is Windows, and that one *only* > has support for GSSAPI/SSPI.

Re: [HACKERS] Allow WAL information to recover corrupted pg_controldata

On Monday, November 05, 2012 7:33 PM Alvaro Herrera wrote: > I'm not sure what to do with this patch. There was some resistance to > the idea originally; then after some discussion, there was some > apparent agreement that it might be useful on occasion. Later, a patch > was posted, but there wa

Re: [HACKERS] Unresolved error 0xC0000409 on Windows Server

On Fri, Nov 2, 2012 at 8:00 PM, Noah Misch wrote: >> hm, several times over the last couple of months (both on postgres 9.1 >> and 9.2), i've seen a similar crash, but on linux. It hits the log >> like this: >> >> Execution halted (~ 200x) >> Error: segfault from C stack overflow >> Execution h

Re: [HACKERS] Statistics and selectivity estimation for ranges

What's going on with this patch? I haven't seen any activity in a while. Should I just move this to the next commitfest? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hacker

Re: [HACKERS] Unresolved error 0xC0000409 on Windows Server

On Sun, Nov 4, 2012 at 3:39 AM, Craig Ringer wrote: > On 11/04/2012 08:47 AM, Matthew Gerber wrote: > > > So I attached the VS debugger, but the server died without raising an > exception in VS. Not sure what's going on here. > >> >> Try creating a directory called "crashdumps" in the data dir

Re: [HACKERS] Allow WAL information to recover corrupted pg_controldata

I'm not sure what to do with this patch. There was some resistance to the idea originally; then after some discussion, there was some apparent agreement that it might be useful on occasion. Later, a patch was posted, but there was almost no review of it; except to say that it should probably be r

Re: [HACKERS] Deprecations in authentication

On Mon, Oct 22, 2012 at 4:24 PM, Stephen Frost wrote: > Magnus, all, > > * Magnus Hagander (mag...@hagander.net) wrote: > > On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas > wrote: > > > That seems like a sufficiently long deprecation window, but is gssapi > > > a full substitute for krb5? I don't

Re: [HACKERS] foreign key locks

On Monday, November 05, 2012 02:37:15 PM Alvaro Herrera wrote: > FWIW I have gotten a lot of feedback about this patch, and since I don't > have time right now to produce an updated version, that I'm going to > close this as Returned with Feedback, and submit an updated version to > the upcoming co

[HACKERS] gset updated patch

Hello here is a updated patch Regards Pavel gset_12.diff 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] foreign key locks

FWIW I have gotten a lot of feedback about this patch, and since I don't have time right now to produce an updated version, that I'm going to close this as Returned with Feedback, and submit an updated version to the upcoming commitfest. This patch still needs much more review -- for example, as f

Re: [HACKERS] Fwd: Stalled post to pgsql-hackers

Thanks Magnus :) Pavel 2012/11/5 Magnus Hagander : > That message just means it's stuck in moderation. You just have to wait for > a moderator to approve it (which I just did now) > > /Magnus > > On Nov 5, 2012 10:19 AM, "Pavel Stehule" wrote: >> >> Hello >> >> I cannot to send a patch to mailin

Re: [HACKERS] Fwd: Stalled post to pgsql-hackers

That message just means it's stuck in moderation. You just have to wait for a moderator to approve it (which I just did now) /Magnus On Nov 5, 2012 10:19 AM, "Pavel Stehule" wrote: > Hello > > I cannot to send a patch to mailing list > > Regards > > Pavel Stehule > > > -- Forwarded messa

[HACKERS] Fwd: Stalled post to pgsql-hackers

Hello I cannot to send a patch to mailing list Regards Pavel Stehule -- Forwarded message -- From: Date: 2012/11/3 Subject: Stalled post to pgsql-hackers To: Pavel Stehule Your message to pgsql-hackers has been delayed, and requires the approval of the moderators, for the

Re: [HACKERS] Synchronous commit not... synchronous?

On Fri, Nov 2, 2012 at 11:41 AM, Daniel Farina wrote: > On Fri, Nov 2, 2012 at 10:31 AM, Simon Riggs wrote: >> On 2 November 2012 16:27, Jeff Janes wrote: >>> It would be. But you are not cancelling the commit, you are >>> *attempting* to cancel the commit. The message you receive explains >>>

Re: [HACKERS] Synchronous commit not... synchronous?

On Fri, Nov 2, 2012 at 10:31 AM, Simon Riggs wrote: > On 2 November 2012 16:27, Jeff Janes wrote: >> It would be. But you are not cancelling the commit, you are >> *attempting* to cancel the commit. The message you receive explains >> to what extend your attempt succeeded. > > That is correct.

Re: [HACKERS] Synchronous commit not... synchronous?

On 10/31/12 9:39 PM, Peter van Hardenberg wrote: > This was rather surprising - my synchronous commit was... not cancelled. > Is this expected behaviour? > > d5r5fdj6u5ieml=> begin; > BEGIN > d5r5fdj6u5ieml=> set synchronous_commit = 'on'; > SET > d5r5fdj6u5ieml=> insert into data values ('baz');

Re: [HACKERS] Bug in ALTER COLUMN SET DATA TYPE ?

On Mon, Nov 5, 2012 at 4:41 AM, Tom Lane wrote: > > > It's clear that we need to pass down the information that this action is > coming from re-creation of a check constraint, but I think the above > proposal for how to do it is pretty wrong-headed. Yeah, I only meant that we need to teach ATEx