Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

2014-03-18 Thread Alvaro Herrera
Tom Lane escribió: > Alvaro Herrera writes: > > Please see my reply to Robert. My proposal (in form of a patch) is > > while operating on tuple (0,2) in table "foo": updating tuple > > Would this work for you? > > It's pretty lousy from a readability standpoint, even in English; > I shudder to

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 Thread Pavel Stehule
2014-03-18 20:49 GMT+01:00 Petr Jelinek : > > On 18/03/14 20:45, Pavel Stehule wrote: > > > > 2014-03-18 20:44 GMT+01:00 Petr Jelinek : > >> >> On 18/03/14 20:36, Pavel Stehule wrote: >> >>> >>> >>> +To aid the user in finding instances of simple but common problems >>> before >>> +the

Re: [HACKERS] Wiki Page Draft for upcoming release

2014-03-18 Thread Josh Berkus
On 03/18/2014 12:35 PM, Andres Freund wrote: > I still think a rewriting noop ALTER TABLE ... ALTER COLUMN col TYPE > old_type USING (col); is the only real thing to do. Then why wouldn't VACUUM FULL work? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers m

Re: [HACKERS] Wiki Page Draft for upcoming release

2014-03-18 Thread Andres Freund
On 2014-03-18 12:52:49 -0700, Josh Berkus wrote: > On 03/18/2014 12:35 PM, Andres Freund wrote: > > I still think a rewriting noop ALTER TABLE ... ALTER COLUMN col TYPE > > old_type USING (col); is the only real thing to do. > > Then why wouldn't VACUUM FULL work? Please read the referenced messa

Re: [HACKERS] Wiki Page Draft for upcoming release

2014-03-18 Thread Josh Berkus
On 03/18/2014 12:55 PM, Andres Freund wrote: > On 2014-03-18 12:52:49 -0700, Josh Berkus wrote: >> On 03/18/2014 12:35 PM, Andres Freund wrote: >>> I still think a rewriting noop ALTER TABLE ... ALTER COLUMN col TYPE >>> old_type USING (col); is the only real thing to do. >> >> Then why wouldn't VA

Re: [HACKERS] [WIP] Better partial index-only scans

2014-03-18 Thread Robert Haas
On Mon, Mar 17, 2014 at 3:14 AM, Joshua Yanovski wrote: > Here's a SQL script that (1) demonstrates the new index only scan > functionality, and (2) at least on my machine, has a consistently > higher planning time for the version with my change than without it. I'm glad you're looking at this, b

Re: [HACKERS] Planner hints in Postgresql

2014-03-18 Thread Claudio Freire
On Tue, Mar 18, 2014 at 4:48 PM, Merlin Moncure wrote: > > That alone could improve things considerably, and statistical info could > be > > propagated along expressions to make it possible to model uncertainty in > > complex expressions as well. > > But how would that work? I see no solution ad

Re: [HACKERS] First-draft release notes for next week's releases

2014-03-18 Thread Josh Berkus
Folks: So another question, which I've already received from the field, is how can you detect this kind of corruption in the first place, if it's not causing a user-visible error? Got that question from someone who failed over between master and replica on 9.3.2 last weekend. They're not seeing

Re: [HACKERS] Portability issues in shm_mq

2014-03-18 Thread Tom Lane
Robert Haas writes: > On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane wrote: >> Meh. I think you're putting a bit too much faith in your ability to >> predict the locus of bugs that you think aren't there. > Well, I'm open to suggestions. As a suggestion: it'd be worth explicitly testing zero-byte

Re: [HACKERS] [WIP] Better partial index-only scans

2014-03-18 Thread Joshua Yanovski
> I'm glad you're looking at this, but we're in the final throws of > nailing down 9.4 and I don't have anticipate I'll have time to look at > it in the near future. You should add it here so we don't forget > about it: > > https://commitfest.postgresql.org/action/commitfest_view/open Yeah, no wor

Re: [HACKERS] Wiki Page Draft for upcoming release

2014-03-18 Thread Tom Lane
Andres Freund writes: > On 2014-03-18 19:28:53 +, Greg Stark wrote: >> It would be nice to be able to tell people that if they vacuum, then >> reindex and check all their foreign key constraints then they should >> be ok. > I don't think so: > http://archives.postgresql.org/message-id/2014031

Re: [HACKERS] Wiki Page Draft for upcoming release

2014-03-18 Thread Andres Freund
On 2014-03-18 16:19:01 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-03-18 19:28:53 +, Greg Stark wrote: > >> It would be nice to be able to tell people that if they vacuum, then > >> reindex and check all their foreign key constraints then they should > >> be ok. > > > I don't t

Re: [HACKERS] [WIP] Better partial index-only scans

2014-03-18 Thread Robert Haas
On Tue, Mar 18, 2014 at 4:18 PM, Joshua Yanovski wrote: >> I'm glad you're looking at this, but we're in the final throws of >> nailing down 9.4 and I don't have anticipate I'll have time to look at >> it in the near future. You should add it here so we don't forget >> about it: >> >> https://com

Re: [HACKERS] Wiki Page Draft for upcoming release

2014-03-18 Thread Alvaro Herrera
Andres Freund wrote: > On 2014-03-18 16:19:01 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On 2014-03-18 19:28:53 +, Greg Stark wrote: > > >> It would be nice to be able to tell people that if they vacuum, then > > >> reindex and check all their foreign key constraints then they shou

Re: [HACKERS] Failure while inserting parent tuple to B-tree is not fun

2014-03-18 Thread Heikki Linnakangas
On 02/06/2014 01:54 AM, Peter Geoghegan wrote: On Thu, Jan 23, 2014 at 1:36 PM, Peter Geoghegan wrote: So while post-recovery callbacks no longer exist for any rmgr-managed-resource, 100% of remaining startup and cleanup callbacks concern the simple management of memory of AM-specific recovery

Re: [HACKERS] Wiki Page Draft for upcoming release

2014-03-18 Thread Andres Freund
On 2014-03-18 17:34:34 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > On 2014-03-18 16:19:01 -0400, Tom Lane wrote: > > > Andres Freund writes: > > > > On 2014-03-18 19:28:53 +, Greg Stark wrote: > > > >> It would be nice to be able to tell people that if they vacuum, then > > > >> re

Re: [HACKERS] Failure while inserting parent tuple to B-tree is not fun

2014-03-18 Thread Tom Lane
Heikki Linnakangas writes: > Yeah, it's a bit silly that each resource manager has to do that on > their own. It would be useful to have a memory context that was > automatically reset between each WAL record. In fact that should > probably be the default memory context you run the WAL redo rou

Re: [HACKERS] Windows build patch

2014-03-18 Thread Alvaro Herrera
Wim Dumon wrote: > 9.3.1 is the version that failed for me, MSVS 2012, Windows 7. It's pretty clear that we will never be able to keep this working unless somebody sets up a buildfarm animal that tests this stuff directly. If you're up to the task, please see here: https://wiki.postgresql.org/wiki

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 Thread Marti Raudsepp
On Tue, Mar 18, 2014 at 9:29 PM, Petr Jelinek wrote: > Attached V4 uses "shadowed-variables" instead of "shadow". I think that should be "shadowed_variables" for consistency; GUC values usually have underscores, not dashes. (e.g. intervalstyle=sql_standard, backslash_quote=safe_encoding, synchron

Re: [HACKERS] Wiki Page Draft for upcoming release

2014-03-18 Thread Andrew Dunstan
On 03/18/2014 04:39 PM, Andres Freund wrote: Mail that's CC/TOed to me onlist, is automatically marked as read by a sieve script so I don't have to mark it as read twice. It seems something went wrong there for a couple of messages... Why not just turn on eliminatecc on the majordomo server

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 Thread Simon Riggs
On 18 March 2014 20:52, Marti Raudsepp wrote: > On Tue, Mar 18, 2014 at 9:29 PM, Petr Jelinek wrote: >> Attached V4 uses "shadowed-variables" instead of "shadow". > > I think that should be "shadowed_variables" for consistency; GUC > values usually have underscores, not dashes. (e.g. > intervalst

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 Thread Marko Tiikkaja
Hi Petr, On 3/18/14, 8:38 PM, I wrote: I did one small change (that I think was agreed anyway) from Marko's original patch in that warnings are only emitted during function creation, no runtime warnings and no warnings for inline (DO) plpgsql code either as I really don't think these optional wa

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe Reply-To:

2014-03-18 Thread Noah Misch
On Tue, Mar 18, 2014 at 10:39:03AM +, Simon Riggs wrote: > On 8 March 2014 11:14, Simon Riggs wrote: > > Implemented in attached patch, v22 > > I commend this patch to you for final review; I would like to commit > > this in a few days. > > I'm planning to commit this today at 1500UTC barrin

Re: [HACKERS] First draft of update announcement

2014-03-18 Thread Josh Berkus
All, Updated per feedback. CC'd to Advocacy now for additional corrections. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com The PostgreSQL Global Development Group has released an update to all supported version of the database system, including versions 9.3.4, 9.2.8, 9.1.13, 9.0.1

Re: [HACKERS] First draft of update announcement

2014-03-18 Thread Tom Lane
Josh Berkus writes: > Updated per feedback. CC'd to Advocacy now for additional corrections. A few thoughts: > The PostgreSQL Global Development Group has released an update to all > supported version of the database system, including versions 9.3.4, 9.2.8, > 9.1.13, 9.0.19, and 8.4.20. By my

Re: [HACKERS] Minimum supported version of Python?

2014-03-18 Thread Tom Lane
Peter Eisentraut writes: > On 3/17/14, 10:55 PM, Tom Lane wrote: >> It doesn't pass the regression tests. Do you need more of a bug report >> than that? > It does pass the tests for me and others. If you are seeing something > different, then we need to see some details, like what platform, wha

Re: [HACKERS] Wiki Page Draft for upcoming release

2014-03-18 Thread Tom Lane
Josh Berkus writes: > On 03/17/2014 05:49 PM, Josh Berkus wrote: >> https://wiki.postgresql.org/wiki/20140320UpdateIssues > Anyone? We're going public with this in 36 hours, so I'd love for it to > actually be correct. I did a bit more hacking on this page. Could use another look from Alvaro a

[HACKERS] logical decoding doc

2014-03-18 Thread Tatsuo Ishii
It seems two exactly same sql sessions are repeated in logicaldecoding.sgml. Is this intended? postgres=# -- You can also peek ahead in the change stream without consuming changes postgres=# SELECT * FROM pg_logical_slot_peek_changes('regression_slot', NULL, NULL); location | xid |

[HACKERS] GSoC application: MADlib k-medoids clustering

2014-03-18 Thread Maxence Ahlouche
Hi all, Some of you may remember me from last year: I had applied to implement the k-medoids clustering method in MADlib, a Postgres and GreenPlum library. As this project could not be selected last year, I'm trying again now! You can find my application at this address: https://github.com/viodle

Re: [HACKERS] pg_archivecleanup bug

2014-03-18 Thread Bruce Momjian
On Tue, Mar 18, 2014 at 09:13:28PM +0200, Heikki Linnakangas wrote: > On 03/18/2014 09:04 PM, Simon Riggs wrote: > >On 18 March 2014 18:55, Alvaro Herrera wrote: > > > >>That said, I don't find comma expression to be particularly "not > >>simple". > > > >Maybe, but we've not used it before anywher

[HACKERS] QSoC proposal: Rewrite pg_dump and pg_restore

2014-03-18 Thread Alexandr
Hello! Here is the text of my proposal which I've applied to GSoC. (and link https://docs.google.com/document/d/1s-Q4rzEysPxo-dINsk_eKFJOBoVjNYDrQ-Oh75gtYEM/edit?usp=sharing) Any suggestions and comments are welcome. * PostgreSQL GSoC 2014 proposal Project name Rewrite (add) pg_dump and pg_

Re: [HACKERS] issue log message to suggest VACUUM FULL if a table is nearly empty

2014-03-18 Thread Wang, Jing
On Friday, 14 March 2014 2:42 PM, Amit Kapila wrote: >On Wed, Mar 12, 2014 at 12:22 PM, Haribabu Kommi >wrote: >> On Tue, Mar 11, 2014 at 2:59 PM, Amit Kapila wrote: >> >>> By the way have you checked if FreeSpaceMapVacuum() can serve your >>> purpose, because this call already traverses FSM i

Re: [HACKERS] pg_archivecleanup bug

2014-03-18 Thread Tom Lane
Bruce Momjian writes: > Would people accept? > for (errno = 0; (dirent = readdir(dir)) != NULL; errno = 0) It's a bit weird looking, but I agree that there's value in only needing the errno-zeroing in precisely one place. regards, tom lane -- Sent via pgsql-hack

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

2014-03-18 Thread Prabakaran, Vaishnavi
On Friday, Mar 14, 2014 at 9:33 PM, Maganus Hagander mailto:mag...@hagander.net> > wrote: >>Hi, >>In connection to my previous proposal about "providing catalog view to >>pg_hba.conf file contents" , I have developed the attached patch . >> [Current situation] >>Currently, to view the pg_hba.

Re: [HACKERS] Planner hints in Postgresql

2014-03-18 Thread Atri Sharma
> >> > That's precisely what risk estimation was about. >> >> Yeah. I would like to see the planner's cost estimates extended to >> include some sort of uncertainty estimate, whereupon risk-averse people >> could ask it to prefer low-uncertainty plans over high-uncertainty ones >> (the plans we ty

Re: [HACKERS] B-tree descend for insertion locking

2014-03-18 Thread Amit Kapila
On Tue, Mar 18, 2014 at 4:42 PM, Heikki Linnakangas wrote: > When inserting into a B-tree index, all the pages are read-locked when > descending the tree. When we reach the leaf page, the read-lock is exchanged > for a write-lock. > > There's nothing wrong with that, but why don't we just directly

<    1   2