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

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

Re: [HACKERS] Planner hints in Postgresql

> >> > 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] Providing catalog view to pg_hba.conf file - Patch submission

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] pg_archivecleanup bug

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] issue log message to suggest VACUUM FULL if a table is nearly empty

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

[HACKERS] QSoC proposal: Rewrite pg_dump and pg_restore

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] pg_archivecleanup bug

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] GSoC application: MADlib k-medoids clustering

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

[HACKERS] logical decoding doc

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 |

Re: [HACKERS] Wiki Page Draft for upcoming release

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

Re: [HACKERS] Minimum supported version of Python?

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] First draft of update announcement

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] First draft of update announcement

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] ALTER TABLE lock strength reduction patch is unsafe Reply-To:

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] plpgsql.warn_shadow

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] plpgsql.warn_shadow

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] Wiki Page Draft for upcoming release

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

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] Windows build patch

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] Failure while inserting parent tuple to B-tree is not fun

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] Wiki Page Draft for upcoming release

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

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

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] [WIP] Better partial index-only scans

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

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] Wiki Page Draft for upcoming release

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] [WIP] Better partial index-only scans

> 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] Portability issues in shm_mq

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] First-draft release notes for next week's releases

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] Planner hints in Postgresql

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] [WIP] Better partial index-only scans

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] Wiki Page Draft for upcoming release

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] Wiki Page Draft for upcoming release

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

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] plpgsql.warn_shadow

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] Patch: show relation and tuple infos of a lock to acquire

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

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 +they cause ha

Re: [HACKERS] Planner hints in Postgresql

On Tue, Mar 18, 2014 at 11:53 AM, Claudio Freire wrote: > > On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane wrote: >> >> Claudio Freire writes: >> > On Mon, Mar 17, 2014 at 7:01 PM, Jim Nasby wrote: >> >> Even better would be if the planner could estimate how bad a plan will >> >> become if we made a

Re: [HACKERS] plpgsql.warn_shadow

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 >> +they cause harm, PL/PgSQL provides a number of >> additional >> +checks. When enabled, depending on the

Re: [HACKERS] plpgsql.warn_shadow

On 18/03/14 20:36, Pavel Stehule wrote: +To aid the user in finding instances of simple but common problems before +they cause harm, PL/PgSQL provides a number of additional +checks. When enabled, depending on the configuration, they +can be used to emit either a WARNING

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

On Tue, Mar 18, 2014 at 12:53 PM, Tom Lane wrote: > 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, eve

Re: [HACKERS] plpgsql.warn_shadow

On 3/18/14, 7:56 PM, Petr Jelinek wrote: Ok, so I took the liberty of rewriting the patch so that it uses plpgsql.extra_warnings and plpgsql.extra_errors configuration variables with possible values "none", "all" and "shadow" ("none" being the default). Updated doc and regression tests to reflect

Re: [HACKERS] plpgsql.warn_shadow

Hello Tomorrow I'll do a review fast check +To aid the user in finding instances of simple but common problems before +they cause harm, PL/PgSQL provides a number of additional +checks. When enabled, depending on the configuration, they +can be used to emit either a WARNIN

Re: [HACKERS] Wiki Page Draft for upcoming release

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/20140317233919.GS16438%40awork2.anaraze

Re: [HACKERS] Wiki Page Draft for upcoming release

On Tue, Mar 18, 2014 at 7:05 PM, Greg Stark wrote: > I'll do a first pass now. I fixed the "Causes" section. I haven't touched the other sections which are pretty reasonable. It would be nice to have more suggestions for what people should do other than dump/restore. It would be nice to be able

Re: [HACKERS] plpgsql.warn_shadow

On 18/03/14 20:15, Pavel Stehule wrote: 2014-03-18 20:14 GMT+01:00 Simon Riggs >: On 18 March 2014 19:04, Pavel Stehule mailto:pavel.steh...@gmail.com>> wrote: > I don't think so only "shadow" is good name for some check. Maybe > "shadow-variables-ch

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 20:14 GMT+01:00 Simon Riggs : > On 18 March 2014 19:04, Pavel Stehule wrote: > > > I don't think so only "shadow" is good name for some check. Maybe > > "shadow-variables-check" > > "shadowed-variables" would be a better name. > +1 > > -- > Simon Riggs http://www.

Re: [HACKERS] plpgsql.warn_shadow

On 18 March 2014 19:04, Pavel Stehule wrote: > I don't think so only "shadow" is good name for some check. Maybe > "shadow-variables-check" "shadowed-variables" would be a better name. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training

Re: [HACKERS] pg_archivecleanup bug

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 anywhere in Postgres, so I don't see a reason to start now. Especially since C is not the nat

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

On Tue, Mar 18, 2014 at 4:12 AM, Heikki Linnakangas wrote: > See attached patch. The new contract of _bt_getroot is a bit weird: it locks > the returned page in the requested lock-mode, shared or exclusive, if the > root page was also the leaf page. Otherwise it's locked in shared mode > regardles

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

On 03/18/2014 12:11 PM, Alexander Korotkov wrote: > Josh, > > Anastasia has already consulted to me in person. It is not big proposal. > But for newbie who is not familiar with PostgreSQL code base and especially > GiST it seems fair enough. > Thanks, that's what I wanted to know. -- Josh Berk

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

Josh, Anastasia has already consulted to me in person. It is not big proposal. But for newbie who is not familiar with PostgreSQL code base and especially GiST it seems fair enough. With best regards, Alexander Korotkov. On Tue, Mar 18, 2014 at 9:16 PM, Josh Berkus wrote: > Alexander, > >

Re: [HACKERS] Portability issues in shm_mq

On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane wrote: >> It's tempting to instead add one or more tests that we specifically >> choose to have values we think are likely to exercise >> platform-specific differences or otherwise find bugs - e.g. just add a >> second test where the queue size and messa

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

On Tue, Mar 18, 2014 at 5:12 PM, Anastasia Lubennikova < lubennikov...@gmail.com> wrote: > 2. gistget algorithm (several parts omitted): > > Check the key > gistindex_keytest() - does this index tuple satisfy the scan key(s)? > > Scan all items on the GiST index page and insert them into the queue

Re: [HACKERS] Wiki Page Draft for upcoming release

On Tue, Mar 18, 2014 at 6:41 PM, Josh Berkus wrote: > > Anyone? We're going public with this in 36 hours, so I'd love for it to > actually be correct. I'll do a first pass now. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscriptio

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 19:56 GMT+01:00 Petr Jelinek : > > On 18/03/14 13:43, Pavel Stehule wrote: > > 2014-03-18 13:23 GMT+01:00 Petr Jelinek > >> >> Agree that compile_errors dos not make sense, additional_errors and >> additional_warnings seems better, maybe plpgsql.extra_warnings and >> plpgsql.extra_err

Re: [HACKERS] pg_archivecleanup bug

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 anywhere in Postgres, so I don't see a reason to start now. Especially since C is not the native language of many people these days and

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

On 02/06/2014 06:42 AM, Peter Geoghegan wrote: I'm not sure about this: *** _bt_findinsertloc(Relation rel, *** 675,680 --- 701,707 static void _bt_insertonpg(Relation rel, Buffer buf, + Buffer cbuf,

Re: [HACKERS] Portability issues in shm_mq

After the last round of changes, I can confirm that my original test with UTF8 locale works, and my HPPA box is happy too. We could still stand to improve the regression test though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] plpgsql.warn_shadow

On 18/03/14 13:43, Pavel Stehule wrote: 2014-03-18 13:23 GMT+01:00 Petr Jelinek > Agree that compile_errors dos not make sense, additional_errors and additional_warnings seems better, maybe plpgsql.extra_warnings and plpgsql.extra_errors? extra* sound

Re: [HACKERS] pg_archivecleanup bug

Simon Riggs escribió: > On 18 March 2014 18:18, Bruce Momjian wrote: > > On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote: > >> Why make style changes at all? A patch with no style changes would > >> mean backpatch and HEAD versions would be the same. > > > > The old style had errno se

Re: [HACKERS] pg_archivecleanup bug

On 18 March 2014 18:18, Bruce Momjian wrote: > On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote: >> On 18 March 2014 18:01, Bruce Momjian wrote: >> > On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote: >> >> > While I am not a fan of backpatching, the fact we are ignoring erro

Re: [HACKERS] pg_archivecleanup bug

Bruce Momjian escribió: > On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote: > > On 18 March 2014 18:01, Bruce Momjian wrote: > > > On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote: > > >> > While I am not a fan of backpatching, the fact we are ignoring errors > > >> > in > >

Re: [HACKERS] Wiki Page Draft for upcoming release

On 03/17/2014 05:49 PM, Josh Berkus wrote: > All, > > https://wiki.postgresql.org/wiki/20140320UpdateIssues > > I'm sure my explanation of the data corruption issue is not correct, so > please fix it. Thanks! > Anyone? We're going public with this in 36 hours, so I'd love for it to actually b

Re: [HACKERS] Risk Estimation WAS: Planner hints in Postgresql

Atri Sharma writes: > One of the factors that leads to bad estimates is that the histogram of the > values of a column maintained by the planner gets old by time and the data > in the column changes. So, the histogram is no longer a quite accurate view > of the data and it leads to bad selectivity

Re: [HACKERS] Risk Estimation WAS: Planner hints in Postgresql

On Tue, Mar 18, 2014 at 11:43 PM, Josh Berkus wrote: > > > On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane wrote: > >> 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-uncert

Re: [HACKERS] Portability issues in shm_mq

and...@anarazel.de (Andres Freund) writes: > On 2014-03-18 13:31:47 -0400, Robert Haas wrote: >> Well, I definitely forgot that. I'll count myself lucky if that's the >> only problem. > One minor thing missing, patch attached. setup_dynamic_shared_memory needed some more hacking too. Committed.

Re: [HACKERS] pg_archivecleanup bug

On Tue, Mar 18, 2014 at 06:11:30PM +, Simon Riggs wrote: > On 18 March 2014 18:01, Bruce Momjian wrote: > > On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote: > >> > While I am not a fan of backpatching, the fact we are ignoring errors in > >> > some critical cases seems the non-cosm

Re: [HACKERS] Risk Estimation WAS: Planner hints in Postgresql

> On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane wrote: >> 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 typicall

Re: [HACKERS] pg_archivecleanup bug

On 18 March 2014 18:01, Bruce Momjian wrote: > On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote: >> > While I am not a fan of backpatching, the fact we are ignoring errors in >> > some critical cases seems the non-cosmetic parts should be backpatched. >> >> pg_resetxlog was not an offen

Re: [HACKERS] pg_archivecleanup bug

On Tue, Mar 18, 2014 at 04:17:53PM +, Simon Riggs wrote: > > While I am not a fan of backpatching, the fact we are ignoring errors in > > some critical cases seems the non-cosmetic parts should be backpatched. > > pg_resetxlog was not an offender here; its coding was sound. > > We shouldn't b

Re: [HACKERS] Portability issues in shm_mq

On 2014-03-18 13:31:47 -0400, Robert Haas wrote: > Well, I definitely forgot that. I'll count myself lucky if that's the > only problem. One minor thing missing, patch attached. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development,

Re: [HACKERS] Portability issues in shm_mq

On Tue, Mar 18, 2014 at 1:16 PM, Tom Lane wrote: > I wrote: >> Early returns not good: > > Also, these compiler messages are probably relevant: > > ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute > -Wformat-secur

Re: [HACKERS] Portability issues in shm_mq

I wrote: > Early returns not good: Also, these compiler messages are probably relevant: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

Alexander, Can you comment on the below proposal? I'd like your opinion on how difficult it will be. On 03/18/2014 06:12 AM, Anastasia Lubennikova wrote: > Hello! > Here is the text of my proposal which I've applied to GSoC. > (and link > http://www.google-melange.com/gsoc/proposal/public/google

[HACKERS] json/jsonb/hstore operator precedence

Fwiw I'm finding myself repeatedly caught up by the operator precedence rules when experimenting with jsonb: stark=***# select segment->'id' as id from flight_segments where segment->>'marketing_airline_code' <> segment->>'operating_airline_code' ; ERROR: 42883: operator does not exist: text <>

Re: [HACKERS] Planner hints in Postgresql

On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane wrote: > Claudio Freire writes: > > On Mon, Mar 17, 2014 at 7:01 PM, Jim Nasby wrote: > >> Even better would be if the planner could estimate how bad a plan will > >> become if we made assumptions that turn out to be wrong. > > > That's precisely what r

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

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 think what it might come out as

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

Tom Lane escribió: > Robert Haas writes: > > Well, if we're back to one version of the message, and I'm glad we > > are, can we go back to saying: > > > CONTEXT: while updating tuple (0,2) in relation "public"."foo" of > > database "postgres" > > If I end up being the one who commits this, it's

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

Robert Haas writes: > Well, if we're back to one version of the message, and I'm glad we > are, can we go back to saying: > CONTEXT: while updating tuple (0,2) in relation "public"."foo" of > database "postgres" If I end up being the one who commits this, it's going to say while updating tuple

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

Robert Haas escribió: > On Tue, Mar 18, 2014 at 12:00 AM, Amit Kapila wrote: > >> Therefore I think the only case worth considering here is when > >> database/relation/TID are all defined. The other cases where there is > >> partial information are dead code; and the case where there is nothing >

Re: [HACKERS] Portability issues in shm_mq

I wrote: > Robert Haas writes: >> First, can you retest this with the latest code? > Yeah, on it now. Early returns not good: *** /Users/buildfarm/bf-data/HEAD/pgsql.93630/contrib/test_shm_mq/expected/test_shm_mq.out Tue Mar 18 12:00:18 2014 --- /Users/buildfarm/bf-data/HEAD/pgsql.93630

Re: [HACKERS] Minimum supported version of Python?

Peter Eisentraut-2 wrote > On 3/18/14, 11:22 AM, Andrew Dunstan wrote: >> Actually, if you run a buildfarm animal you have considerable control >> over what it tests. > > I appreciate that. My problem here isn't time or ideas or coding, but > lack of hardware resources. If I had hardware, I coul

Re: [HACKERS] pg_archivecleanup bug

On 13 March 2014 05:48, Bruce Momjian wrote: > On Mon, Dec 9, 2013 at 11:27:28AM -0500, Robert Haas wrote: >> On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote: >> > But the other usages seem to be in assorted utilities, which >> > will need to do it right for themselves. initdb.c's walkdir() seem

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

On Tue, Mar 18, 2014 at 12:00 AM, Amit Kapila wrote: >> Therefore I think the only case worth considering here is when >> database/relation/TID are all defined. The other cases where there is >> partial information are dead code; and the case where there is nothing >> defined (such as the one in

Re: [HACKERS] Portability issues in shm_mq

Robert Haas writes: > First, can you retest this with the latest code? Yeah, on it now. > If we want to inject some randomness into the test, which parameters > do we want to randomize and over what ranges? I think the message length is the only particularly interesting parameter. It'd be nice

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

On Tue, Mar 18, 2014 at 11:59 AM, Greg Stark wrote: > On Tue, Mar 18, 2014 at 3:42 AM, Amit Kapila wrote: >> The message for exclusive lock on tuple print the database information. > > It is true that it is possible to have a deadlock or lock chains that > involves locks on other databases. > In

Re: [HACKERS] Portability issues in shm_mq

All right. On Fri, Mar 14, 2014 at 4:43 PM, Tom Lane wrote: > Whilst setting up a buildfarm member on an old, now-spare Mac, I was > somewhat astonished to discover that contrib/test_shm_mq crashes thus: > TRAP: FailedAssertion("!(rb >= sizeof(uint64))", File: "shm_mq.c", Line: 429) > but only in

Re: [HACKERS] Minimum supported version of Python?

On 3/18/14, 11:22 AM, Andrew Dunstan wrote: > Actually, if you run a buildfarm animal you have considerable control > over what it tests. I appreciate that. My problem here isn't time or ideas or coding, but lack of hardware resources. If I had hardware, I could set up tests for every build depe

Re: [HACKERS] pg_archivecleanup bug

On 18 March 2014 15:50, Robert Haas wrote: > On Tue, Mar 18, 2014 at 11:36 AM, Simon Riggs wrote: >> Given the above, this means we've run for about 7 years without a >> reported issue on this. If we are going to "make this better" by >> actually having it throw errors in places that didn't throw

Re: [HACKERS] Minimum supported version of Python?

On 3/17/14, 10:47 PM, Joshua D. Drake wrote: > We shouldn't be supporting anything the community doesn't support. > Python 2.3 is dead. We shouldn't actively support it nor suggest that we > could or should via the docs. The information that is available to me about this issue is lacking details,

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

On Tue, Mar 18, 2014 at 3:42 AM, Amit Kapila wrote: > The message for exclusive lock on tuple print the database information. It is true that it is possible to have a deadlock or lock chains that involves locks on other databases. In this example the table "test" is not in the database that just

Re: [HACKERS] pg_archivecleanup bug

On Tue, Mar 18, 2014 at 11:36 AM, Simon Riggs wrote: > Given the above, this means we've run for about 7 years without a > reported issue on this. If we are going to "make this better" by > actually having it throw errors in places that didn't throw errors > before, are we sure that is going to ma

Re: [HACKERS] Minimum supported version of Python?

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, what version, what Python version, ho

Re: [HACKERS] pg_archivecleanup bug

On 18 March 2014 14:15, Alvaro Herrera wrote: > Bruce Momjian escribió: >> On Tue, Mar 18, 2014 at 10:03:46AM -0400, Robert Haas wrote: >> > On Tue, Mar 18, 2014 at 9:56 AM, Tom Lane wrote: >> > > Bruce Momjian writes: >> > >> Very good point. I have modified the patch to add this block in all

Re: [HACKERS] Portability issues in shm_mq

On Tue, Mar 18, 2014 at 10:44 AM, Tom Lane wrote: >> The thing I kind of like about this approach is that it makes the code >> fully independent of the relationship between MAXIMUM_ALIGNOF and >> sizeof(Size). > > Yeah. If it's not costing us much to support both cases, let's do so. OK, committe

Re: [HACKERS] Minimum supported version of Python?

On 03/17/2014 10:31 PM, Peter Eisentraut wrote: On Sun, 2014-03-16 at 22:34 -0400, Tom Lane wrote: As for 2.4 vs 2.5, I don't have a lot of faith that we're really supporting anything that's not represented in the buildfarm... There are many other features that the build farm doesn't test and

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

Robert Haas writes: > Tom Lane previously proposed extending SP-GiST to support index-only > scans. You might find that discussing worth reading, or perhaps > consider it as an alternative if GiST doesn't work out: > http://www.postgresql.org/message-id/10839.1323885...@sss.pgh.pa.us That wasn't

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

On Tue, Mar 18, 2014 at 9:12 AM, Anastasia Lubennikova wrote: > Support for index-only scans for GIST index This is a cool idea, if it can be made to work. > If the fetch() is specified by the developer, then using it, algorithm can > retrieve the data directly to output areas at this stage, wit

Re: [HACKERS] Portability issues in shm_mq

Robert Haas writes: > On Mon, Mar 17, 2014 at 11:09 PM, Tom Lane wrote: >> Would it get noticeably simpler or faster if you omitted support for >> the sizeof(Size) > MAXIMUM_ALIGNOF case? It looks like perhaps not, >> but if we were paying anything much I'd be tempted to just put in >> a static

  1   2   >