Re: [HACKERS] 9.3 Beta1 status report

2013-04-25 Thread Vik Fearing
On 04/24/2013 06:34 PM, Heikki Linnakangas wrote: Let me clarify --- changes to our WAL binary format and source code changes are not really incompatibilities from a user perspective as we never promise to do our best to minimize such changes --- m eaning the fact the WAL format changed is

Re: [HACKERS] LEFT JOIN LATERAL can remove rows from LHS

2013-06-18 Thread Vik Fearing
On 06/18/2013 01:52 AM, Jeremy Evans wrote: Maybe I am misunderstanding how LATERAL is supposed to work, but my expectation is that doing a LEFT JOIN should not remove rows from the LHS. I would expect all of the following select queries would return a single row, but that isn't the case:

Re: [HACKERS] LEFT JOIN LATERAL can remove rows from LHS

2013-06-20 Thread Vik Fearing
On 06/18/2013 01:52 AM, Jeremy Evans wrote: Maybe I am misunderstanding how LATERAL is supposed to work, but my expectation is that doing a LEFT JOIN should not remove rows from the LHS. I have added this to the list of 9.3 blockers. https://wiki.postgresql.org/wiki/PostgreSQL_9.3_Open_Items

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-05 Thread Vik Fearing
On 07/04/2013 10:15 AM, Dean Rasheed wrote: On 4 July 2013 00:08, David Fetter da...@fetter.org wrote: Patch re-jiggered for recent changes to master. I re-validated this, and it all still looks good, so still ready for committer IMO. I tried to check this out, too and make check fails with

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-05 Thread Vik Fearing
On 07/05/2013 04:51 PM, Vik Fearing wrote: I tried to check this out, too and make check fails with the following. I have not looked into the cause. Running ./configure again fixed it. Sorry for the noise. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] [GENERAL] Insert result does not match record count

2013-07-24 Thread Vik Fearing
On 07/22/2013 06:20 PM, Jeff Janes wrote: On Fri, Jul 19, 2013 at 3:20 PM, Natalie Wenz nataliew...@ebureau.com wrote: Hi all, I am moving some data from one table to another in 9.2.4, and keep seeing this strange scenario: insert into newtable select data from oldtable where proc_date = x

Re: [HACKERS] [GENERAL] Insert result does not match record count

2013-07-24 Thread Vik Fearing
On 07/24/2013 04:04 PM, Vik Fearing wrote: On 07/22/2013 06:20 PM, Jeff Janes wrote: On Fri, Jul 19, 2013 at 3:20 PM, Natalie Wenz nataliew...@ebureau.com wrote: Hi all, I am moving some data from one table to another in 9.2.4, and keep seeing this strange scenario: insert into newtable

Re: [HACKERS] Review: UNNEST (and other functions) WITH ORDINALITY

2013-07-29 Thread Vik Fearing
On 07/29/2013 09:56 AM, Craig Ringer wrote: Unless LATERAL provides a way to do lock-step iteration through a pair (or more) of functions I don't think we can get rid of SRFs-in-FROM just yet. I don't think anyone was arguing for that; we're talking about deprecating SRFs-in-SELECT. -- Sent

[HACKERS] [PATCH] pg_sleep(interval)

2013-08-08 Thread Vik Fearing
Someone on IRC a while ago was complaining that there was no way to specify an interval for pg_sleep, so I made one. Patch against today's HEAD attached. Usage: SELECT pg_sleep(interval '2 minutes'); I would add this to the next commitfest but I seem to be unable to log in with my community

[HACKERS] [PATCH] Statistics collection for CLUSTER command

2013-08-08 Thread Vik Fearing
As part of routine maintenance monitoring, it is interesting for us to have statistics on the CLUSTER command (timestamp of last run, and number of runs since stat reset) like we have for (auto)ANALYZE and (auto)VACUUM. Patch against today's HEAD attached. I would add this to the next commitfest

Re: [HACKERS] [PATCH] Statistics collection for CLUSTER command

2013-08-08 Thread Vik Fearing
On 08/08/2013 07:57 PM, Stefan Kaltenbrunner wrote: On 08/08/2013 01:52 PM, Vik Fearing wrote: I would add this to the next commitfest but I seem to be unable to log in with my community account (I can log in to the wiki). Help appreciated. whould be a bit easier to diagnose if we knew your

Re: [HACKERS] [PATCH] Statistics collection for CLUSTER command

2013-08-09 Thread Vik Fearing
On 08/08/2013 02:26 PM, Fabien COELHO wrote: As part of routine maintenance monitoring, it is interesting for us to have statistics on the CLUSTER command (timestamp of last run, and number of runs since stat reset) like we have for (auto)ANALYZE and (auto)VACUUM. Patch against today's HEAD

Re: [HACKERS] [PATCH] Statistics collection for CLUSTER command

2013-08-09 Thread Vik Fearing
On 08/09/2013 10:37 PM, Stefan Kaltenbrunner wrote: On 08/08/2013 01:52 PM, Vik Fearing wrote: I would add this to the next commitfest but I seem to be unable to log in with my community account (I can log in to the wiki). Help appreciated. hmm looks like your account may be affected by one

Re: [HACKERS] [BUGS] BUG #8335: trim() un-document behaviour

2013-08-21 Thread Vik Fearing
On 08/14/2013 11:27 PM, Bruce Momjian wrote: On Mon, Aug 12, 2013 at 11:31:38PM -0400, Bruce Momjian wrote: On Mon, Aug 12, 2013 at 05:19:30PM -0400, Bruce Momjian wrote: Attached are docs that add the new syntax, and mention it is non-standard; you can see the output here:

[HACKERS] pg_system_identifier()

2013-08-21 Thread Vik Fearing
After someone in IRC asked if there was an equivalent to MySQL's server_id, it was noted that we do have a system identifier but it's not very accessible. The attached patch implements a pg_system_identifier() function that exposes it. Shall I add this to the next commitfest? -- Vik ***

Re: [HACKERS] pg_system_identifier()

2013-08-22 Thread Vik Fearing
On 08/22/2013 02:51 PM, Fujii Masao wrote: On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing vik.fear...@dalibo.com wrote: After someone in IRC asked if there was an equivalent to MySQL's server_id, it was noted that we do have a system identifier but it's not very accessible. The attached patch

Re: [HACKERS] pg_system_identifier()

2013-08-22 Thread Vik Fearing
On 08/22/2013 03:21 PM, Fujii Masao wrote: I don't know if that's justification enough, which is why I didn't add it to the commitfest yet. You can add the patch to CF, and then hear the opinions from other people during CF. Added. -- Vik -- Sent via pgsql-hackers mailing list

Re: [HACKERS] median and percentile function implementation

2013-08-26 Thread Vik Fearing
On 08/26/2013 02:39 PM, Pavel Stehule wrote: Hello Three years ago we worked on implementation of median function. http://www.postgresql.org/message-id/aanlktimrksuoggsk7-gtxnvjjgl-1qvuqxiduszqw...@mail.gmail.com Can we implement this function now? There are a few opened questions: *

Re: [HACKERS] Patch: Allow formatting in log_line_prefix

2013-08-27 Thread Vik Fearing
On 08/27/2013 05:06 AM, David Rowley wrote: Heikki wrote that it might be useful to allow formatting in the log_line_prefix here http://www.postgresql.org/message-id/5187cadb.50...@vmware.com I thought I'd take a bash at implementing space padding part on log_line_prefix options. It's been

Re: [HACKERS] record identical operator

2013-09-18 Thread Vik Fearing
On 09/19/2013 12:55 AM, Dimitri Fontaine wrote: We have, as a community, gone to a fair amount of trouble to make the concept of equality pluggable and allow multiple types of equality per type. To me it seems the perfect tool to solve this problem. Why the fuss? Because I don't

[HACKERS] Dump/Reload broken with relocatable extensions

2013-09-19 Thread Vik Fearing
I don't know if this has been discussed before, a cursory search of the archives didn't turn up anything interesting. I perhaps didn't put in the right keywords. Unfortunately, the easiest way that I've found to reproduce this bug is to apply the attached patch to the unaccent extension. This

Re: [HACKERS] Dump/Reload broken with relocatable extensions

2013-09-20 Thread Vik Fearing
On 09/19/2013 11:40 PM, Dimitri Fontaine wrote: Vik Fearing vik.fear...@dalibo.com writes: I don't know if this has been discussed before, a cursory search of the archives didn't turn up anything interesting. I perhaps didn't put in the right keywords. For others not to spend too much time

Re: [HACKERS] [PATCH] pg_sleep(interval)

2013-09-22 Thread Vik Fearing
On 09/20/2013 01:59 PM, Fabien COELHO wrote: Here is a review of the pg_sleep(INTERVAL) patch version 1: Thank you for looking at it. - the new function is *not* tested anywhere! I would suggest simply to replace some pg_sleep(int) instances by corresponding pg_sleep(interval)

Re: [HACKERS] Dump/Reload broken with relocatable extensions

2013-09-23 Thread Vik Fearing
On 09/19/2013 11:40 PM, Dimitri Fontaine wrote: Vik Fearing vik.fear...@dalibo.com writes: I don't know if this has been discussed before, a cursory search of the archives didn't turn up anything interesting. I perhaps didn't put in the right keywords. For others not to spend too much time

Re: [HACKERS] [PATCH] pg_sleep(interval)

2013-09-30 Thread Vik Fearing
On 09/22/2013 02:17 PM, Fabien COELHO wrote: Hello, There is no pg_sleep(text) function and the cast is unknown-double precision. My mistake. As I understand it, pg_sleep('12') currently works and would not anymore once your patch is applied. That is the concern raised by Robert Haas.

Re: [HACKERS] WITHIN GROUP patch

2013-10-15 Thread Vik Fearing
On 10/09/2013 04:19 PM, Pavel Stehule wrote: I checked a conformance with ANSI SQL - and I didn't find any issue. I found so following error message is not too friendly (mainly because this functionality will be new) postgres=# select dense_rank(3,3,2) within group (order by

Re: [HACKERS] SSL renegotiation

2013-10-15 Thread Vik Fearing
On 09/23/2013 10:51 PM, Alvaro Herrera wrote: + /* are we in the middle of a renegotiation? */ + static bool in_ssl_renegotiation = false; + Since this was committed, I'm getting the following warning: be-secure.c:105:13: warning: ‘in_ssl_renegotiation’ defined but not used

Re: [HACKERS] [PATCH] Statistics collection for CLUSTER command

2013-10-15 Thread Vik Fearing
On 09/16/2013 08:26 AM, Satoshi Nagayasu wrote: (2013/08/08 20:52), Vik Fearing wrote: As part of routine maintenance monitoring, it is interesting for us to have statistics on the CLUSTER command (timestamp of last run, and number of runs since stat reset) like we have for (auto)ANALYZE

Re: [HACKERS] Doc Patch: Subquery section to say that subqueries can't modify data

2013-10-15 Thread Vik Fearing
On 08/06/2013 11:03 PM, Karl O. Pinc wrote: The attached documentation patch, doc-subqueries-v1.patch, applies against head. I wanted to document that subqueries can't modify data. This is mentioned in the documentation for SELECT and implied elsewhere but I was looking for something more

Re: [HACKERS] [PATCH] pg_sleep(interval)

2013-10-15 Thread Vik Fearing
On 09/30/2013 01:47 PM, Vik Fearing wrote: Yes, I understand you are trying to help, and I appreciate it! My opinion, and that of others as well from the original thread, is that this patch should either go in as is and break that one case, or not go in at all. I'm fine with either (although

Re: [HACKERS] [PATCH] pg_sleep(interval)

2013-10-16 Thread Vik Fearing
On 10/16/2013 10:57 AM, Fabien COELHO wrote: Hello Vik, I see this is marked as rejected in the commitfest app, but I don't see any note about who did it or why. I don't believe there is consensus for rejection on this list. In fact I think the opposite is true. May we have an explanation

Re: [HACKERS] [PATCH] pg_sleep(interval)

2013-10-17 Thread Vik Fearing
On 10/17/2013 10:03 AM, Fabien COELHO wrote: My guess is that it won't be committed if there is a single but it might break one code or surprise one user somewhere in the universe, but I wish I'll be proven wrong. IMO, returned with feedback on a 1 liner is really akin to rejected. I have

Re: [HACKERS] [PATCH] pg_sleep(interval)

2013-10-17 Thread Vik Fearing
On 10/17/2013 02:42 PM, Robert Haas wrote: On Thu, Oct 17, 2013 at 8:26 AM, Vik Fearing vik.fear...@dalibo.com wrote: On 10/17/2013 10:03 AM, Fabien COELHO wrote: My guess is that it won't be committed if there is a single but it might break one code or surprise one user somewhere

Re: [HACKERS] [PATCH] pg_sleep(interval)

2013-10-17 Thread Vik Fearing
On 10/17/2013 08:36 PM, Kevin Grittner wrote: Josh Berkus j...@agliodbs.com wrote: Our project has a serious, chronic problem with giving new patch-submitters a bad experience, and this patch is a good example of that. Perhaps; but it has also been an example of the benefits of having tight

Re: [HACKERS] [PATCH] pg_sleep(interval)

2013-10-17 Thread Vik Fearing
On 10/17/2013 06:59 PM, Josh Berkus wrote: Our project has a serious, chronic problem with giving new patch-submitters a bad experience, and this patch is a good example of that. The ultimate result is that people go off to contribute to other projects where submissions are easier and the

Re: [HACKERS] FDW API / flow charts for the docs?

2013-10-19 Thread Vik Fearing
On 10/19/2013 02:22 AM, Christopher Browne wrote: I would be more inclined to let GraphViz into the process than Dia; the former fits *much* better into a Make-based process. I also cast my vote for Graphviz. -- Vik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] FDW API / flow charts for the docs?

2013-10-21 Thread Vik Fearing
On 10/21/2013 06:24 AM, David Fetter wrote: On Sat, Oct 19, 2013 at 01:56:23PM -0400, Peter Eisentraut wrote: I'd also take a look at ditaa, which might make this even simpler. If we manage to keep Java out of our build toolchain, we will be much the better for it. Amen. -- Vik -- Sent

Re: [HACKERS] WITHIN GROUP patch

2013-11-04 Thread Vik Fearing
On 11/04/2013 08:43 AM, Atri Sharma wrote: Please find attached our latest version of the patch. This version fixes the issues pointed out by the reviewers. No, it doesn't. The documentation still contains formatting and grammatical errors, and the code comments still do not match the their

Re: [HACKERS] WITHIN GROUP patch

2013-11-21 Thread Vik Fearing
On 11/21/2013 11:04 AM, Atri Sharma wrote: Please find attached the latest patch for WITHIN GROUP. This patch is after fixing the merge conflicts. I have spent quite some time on this and the previous versions. Here is my review, following the questions on the wiki. This patch is in context

Re: [HACKERS] new unicode table border styles for psql

2013-11-23 Thread Vik Fearing
On 11/21/2013 10:39 PM, Peter Eisentraut wrote: On 11/21/13, 2:09 AM, Pavel Stehule wrote: I wrote new styles for psql table borders. http://postgres.cz/wiki/Pretty_borders_in_psql This patch is simply and I am think so some styles can be interesting for final presentation. Do you think

Re: [HACKERS] Minor patch for the uuid-ossp extension

2013-11-23 Thread Vik Fearing
On 11/23/2013 01:12 PM, Mario Weilguni wrote: Am 22.11.2013 16:15, schrieb Tom Lane: [ memo to self: never, ever accept another contrib module whose name isn't a plain SQL identifier ] Well, in that case and since this is a rarely used extension (I guess so), maybe it would be the best to

Re: [HACKERS] CREATE FOREIGN TABLE ( ... LIKE ... )

2013-11-23 Thread Vik Fearing
On 10/15/2013 07:50 AM, David Fetter wrote: On Mon, Oct 07, 2013 at 11:16:56PM -0700, David Fetter wrote: Folks, Please find attached a patch implementing and documenting, to some extent, $subject. I did this in aid of being able to import SQL standard catalogs and other entities where a

Re: [HACKERS] Extension Templates S03E11

2013-11-27 Thread Vik Fearing
On 11/26/2013 10:07 PM, Dimitri Fontaine wrote: What I now think we should do is only grant superusers the privileges to install an extension from a template they own or is owned by another superuser. Say what? Superusers bypass all privileges by definition. -- Vik -- Sent via

[HACKERS] CREATE TABLESPACE SET

2013-12-24 Thread Vik Fearing
I was recently annoyed that I had to do CREATE TABLESPACE x LOCATION y; ALTER TABLESPACE x SET (random_page_cost = z); The attached patch is a quick n' dirty extension to allow the SET directly on the CREATE statement. CREATE TABLESPACE x LOCATION y SET (random_page_cost = z); If people think

Re: [HACKERS] CREATE TABLESPACE SET

2013-12-26 Thread Vik Fearing
On 12/26/2013 06:10 PM, David Fetter wrote: On Tue, Dec 24, 2013 at 07:25:01PM +0100, Vik Fearing wrote: I was recently annoyed that I had to do CREATE TABLESPACE x LOCATION y; ALTER TABLESPACE x SET (random_page_cost = z); The attached patch is a quick n' dirty extension to allow the SET

Re: [HACKERS] Proposal: variant of regclass

2013-12-30 Thread Vik Fearing
On 12/31/2013 02:38 AM, Tatsuo Ishii wrote: Before proceeding the work, I would like to make sure that followings are complete list of new functions. Inside parentheses are corresponding original functions. toregproc (regproc) toregoper (regoper) toregclass (regclass) toregtype (regtype)

Re: [HACKERS] CREATE TABLESPACE WITH

2014-01-14 Thread Vik Fearing
On 12/26/2013 06:10 PM, David Fetter wrote: On Tue, Dec 24, 2013 at 07:25:01PM +0100, Vik Fearing wrote: I was recently annoyed that I had to do CREATE TABLESPACE x LOCATION y; ALTER TABLESPACE x SET (random_page_cost = z); The attached patch is a quick n' dirty extension to allow the SET

Re: [HACKERS] CREATE TABLESPACE WITH

2014-01-15 Thread Vik Fearing
On 01/15/2014 03:07 AM, Michael Paquier wrote: I just had a quick look at this patch, no testing at all. Thank you for looking at it. I am seeing that regression tests are still missing here, they should be added in src/test/regress/input/tablespace.source. New patch attached, with

Re: [HACKERS] CREATE FOREIGN TABLE ( ... LIKE ... )

2014-01-15 Thread Vik Fearing
On 11/24/2013 02:03 AM, Vik Fearing wrote: On 10/15/2013 07:50 AM, David Fetter wrote: On Mon, Oct 07, 2013 at 11:16:56PM -0700, David Fetter wrote: Folks, Please find attached a patch implementing and documenting, to some extent, $subject. I did this in aid of being able to import SQL

Re: [HACKERS] CREATE FOREIGN TABLE ( ... LIKE ... )

2014-01-15 Thread Vik Fearing
On 01/16/2014 01:21 AM, Tom Lane wrote: Vik Fearing vik.fear...@dalibo.com writes: I am marking this patch as 'returned with feedback' in the commitfest app. It looks like this patch got left behind in the previous commitfest. What is the policy for moving it? Is it too late and will have

Re: [HACKERS] CREATE TABLESPACE WITH

2014-01-18 Thread Vik Fearing
On 01/18/2014 03:21 PM, Michael Paquier wrote: So, except for the regression output problem, I think that the code is clean so marking it as Ready for committer on the commit fest app. Thank you for the review. Sorry about the regression thing. I tried to randomize it a bit so that I would

Re: [HACKERS] Closing commitfest 2013-11

2014-01-21 Thread Vik Fearing
On 01/20/2014 10:31 PM, Tom Lane wrote: I think the idea was that patch authors should take responsibility for pushing their patches forward to 2014-01 if they still wanted them considered. Quite a few patches already were moved that way, IIRC. Agreed though that we shouldn't let them just

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

2014-01-29 Thread Vik Fearing
On 01/29/2014 01:12 PM, Heikki Linnakangas wrote: On 01/28/2014 06:11 PM, Christian Kruse wrote: Hi, attached you will find a new version of the patch, ported to HEAD, fixed the mentioned bug and - hopefully - dealing the the remaining issues. Thanks, I have committed this now. The

Re: [HACKERS] pg_sleep_enhancements.patch

2014-01-29 Thread Vik Fearing
On 01/29/2014 08:04 PM, Pavel Stehule wrote: Hello I am looking on this patch Thank you for looking at it. http://www.postgresql.org/message-id/525fe206.6000...@dalibo.com a) pg_sleep_for - no objection - it is simple and secure Okay. b) pg_sleep_until I am not sure - maybe this

Re: [HACKERS] pg_sleep_enhancements.patch

2014-01-29 Thread Vik Fearing
On 01/29/2014 08:21 PM, Pavel Stehule wrote: second question - is not this functionality too dangerous? If somebody use it as scheduler, then a) can holds connect, session data, locks too long time b) it can stop on query timeout probably much more early then user expect What is expected

Re: [HACKERS] [PATCH] pg_sleep(interval)

2014-01-30 Thread Vik Fearing
On 01/30/2014 09:48 PM, Robert Haas wrote: On Thu, Oct 17, 2013 at 9:11 AM, Vik Fearing vik.fear...@dalibo.com wrote: On 10/17/2013 02:42 PM, Robert Haas wrote: On Thu, Oct 17, 2013 at 8:26 AM, Vik Fearing vik.fear...@dalibo.com wrote: On 10/17/2013 10:03 AM, Fabien COELHO wrote: My guess

Re: [HACKERS] CREATE FOREIGN TABLE ( ... LIKE ... )

2014-01-31 Thread Vik Fearing
On 01/25/2014 06:25 AM, David Fetter wrote: I like this patch, but I don't like its implementation at all. First of all, the documentation doesn't compile: openjade:ref/create_foreign_table.sgml:124:17:E: end tag for LISTITEM omitted, but OMITTAG NO was specified

Re: [HACKERS] [GENERAL] Insert result does not match record count

2014-01-31 Thread Vik Fearing
On 01/31/2014 06:19 PM, Bruce Momjian wrote: On Wed, Jul 24, 2013 at 08:08:32PM +0200, Andres Freund wrote: On 2013-07-24 13:48:23 -0400, Tom Lane wrote: Vik Fearing vik.fear...@dalibo.com writes: Also worth mentioning is bug #7766. http://www.postgresql.org/message-id/e1tlli5-0007tr

Re: [HACKERS] [GENERAL] Insert result does not match record count

2014-01-31 Thread Vik Fearing
On 01/31/2014 10:56 PM, Bruce Momjian wrote: On Fri, Jan 31, 2014 at 04:38:21PM -0500, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: On Fri, Jan 31, 2014 at 06:34:27PM +0100, Vik Fearing wrote: Unfortunately, I gave up on it as being over my head when I noticed I was changing

Re: [HACKERS] [GENERAL] Insert result does not match record count

2014-02-02 Thread Vik Fearing
On 02/01/2014 02:26 AM, Bruce Momjian wrote: On Sat, Feb 1, 2014 at 02:25:16AM +0100, Vik Fearing wrote: OK, thanks for the feedback. I understand now. The contents of the string will potentially have a larger integer, but the byte length of the string in the wire protocol doesn't change

[HACKERS] nextVictimBuffer in README

2014-02-13 Thread Vik Fearing
While reading through src/backend/storage/buffer/README and looking at the code that it describes, I noticed that the case is wrong for nextVictimBuffer. It's no big deal really, but the attached trivial patch makes the README match the code. -- Vik *** a/src/backend/storage/buffer/README ---

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

2014-03-01 Thread Vik Fearing
On 03/01/2014 12:06 PM, Simon Riggs wrote: On 27 February 2014 08:48, Simon Riggs si...@2ndquadrant.com wrote: On 26 February 2014 15:25, Andres Freund and...@2ndquadrant.com wrote: On 2014-02-26 15:15:00 +, Simon Riggs wrote: On 26 February 2014 13:38, Andres Freund and...@2ndquadrant.com

Re: [HACKERS] commit fest status and release timeline

2014-03-01 Thread Vik Fearing
On 03/01/2014 07:50 PM, Josh Berkus wrote: On 03/01/2014 09:01 AM, Peter Eisentraut wrote: Status Summary. Needs Review: 36, Waiting on Author: 7, Ready for Committer: 16, Committed: 43, Returned with Feedback: 8, Rejected: 4. Total: 114. We're still on track to achieve about 50% committed

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

2014-03-09 Thread Vik Fearing
On 03/06/2014 10:47 AM, Simon Riggs wrote: On 5 March 2014 09:28, Simon Riggs si...@2ndquadrant.com wrote: So that returns us to solving the catalog consistency problem in pg_dump and similar applications. No answer, guys, and time is ticking away here. Sorry, I've accumulated several days

Re: [HACKERS] Planner hints in Postgresql

2014-03-17 Thread Vik Fearing
On 03/17/2014 06:28 PM, Stephen Frost wrote: a value passed in as part of the query, with a high likelihood of users figuring out how to use it to say use my plan forever and always.. Last time this came up, I said on irc that if we ever do implement hints, I'd like them to be tied to a major

Re: [HACKERS] Planner hints in Postgresql

2014-03-17 Thread Vik Fearing
On 03/17/2014 11:15 PM, Josh Berkus wrote: 2. they eventually become a barrier to upgrading, once the performance of the DB engine changes in a way that makes older query decorators crippling and/or erroneous. Because they are scattered all around the code, it then becomes a major refactoring

Re: [HACKERS] four minor proposals for 9.5

2014-03-19 Thread Vik Fearing
On 03/19/2014 04:34 PM, Pavel Stehule wrote: Hello I wrote a few patches, that we use in our production. These patches are small, but I hope, so its can be interesting for upstream: 1. cancel time - we log a execution time cancelled statements +1 I even wrote a patch to do this, but it

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

2014-03-20 Thread Vik Fearing
On 03/18/2014 11:39 AM, Simon Riggs wrote: On 8 March 2014 11:14, Simon Riggs si...@2ndquadrant.com wrote: On 7 March 2014 09:04, Simon Riggs si...@2ndquadrant.com wrote: The right thing to do here is to not push to the extremes. If we mess too much with the ruleutil stuff it will just be

Re: [HACKERS] Partial index locks

2014-03-21 Thread Vik Fearing
On 03/22/2014 01:43 AM, Thom Brown wrote: Hi, I've created a table with 1000 partial indexes. Each one matches exactly one row based on the predicate WHERE id = value. However, when I perform an UPDATE of a single row in a transaction, I've noticed that all those partial indexes show up in

[HACKERS] Buildfarm network under attack

2014-04-09 Thread Vik Fearing
According to Joshua Drake on IRC, there is a DDOS in progress against a customer in the same network as the buildfarm. As a consequence, you may experience slowness, or inability to connect while they deal with it. -- Vik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] New pg_lsn type doesn't have hash/btree opclasses

2014-05-06 Thread Vik Fearing
On 05/06/2014 04:59 PM, Heikki Linnakangas wrote: On 05/06/2014 05:17 PM, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-05-06 09:37:54 -0400, Tom Lane wrote: Sorry, it is *way* too late for 9.4. It's imo a regression/oversight introduced in the pg_lsn patch. Not a new

Re: [HACKERS] Bison 3.0 updates

2014-05-21 Thread Vik Fearing
I'm getting some more of these, including some I thought you had fixed. Bison 3.0.2 on current head. Writing postgres.bki Writing schemapg.h Writing postgres.description Writing postgres.shdescription gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’ [-Wdeprecated]

Re: [HACKERS] Bison 3.0 updates

2014-05-21 Thread Vik Fearing
On 05/21/2014 12:29 PM, Tom Lane wrote: Vik Fearing vik.fear...@dalibo.com writes: I'm getting some more of these, including some I thought you had fixed. Bison 3.0.2 on current head. I didn't do anything to suppress those warnings: gram.y:172.1-13: warning: deprecated directive, use ‘%name

[HACKERS] SQL access to database attributes

2014-05-23 Thread Vik Fearing
We try to tell our clients not to update the catalogs directly, but there are at least two instances where it's not possible to do otherwise (pg_database.datistemplate and .datallowconn). This patch aims to remedy that. For example, it is now possible to say ALTER DATABASE d ALLOW

Re: [HACKERS] SQL access to database attributes

2014-05-23 Thread Vik Fearing
On 05/24/2014 12:03 AM, Jaime Casanova wrote: On Fri, May 23, 2014 at 10:53 PM, Vik Fearing vik.fear...@dalibo.com wrote: It was suggested to me that these options should either error out if there are existing connections or terminate said connections. I don't agree with that because

Re: [HACKERS] SQL access to database attributes

2014-05-26 Thread Vik Fearing
On 05/26/2014 07:10 AM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: I don't really object to doing an unlocked check for another such database, but I'm not convinced that additional locking to try to prevent a race is worth its keep. +1 on the nannyism, and +1 to ignoring the

Re: [HACKERS] SQL access to database attributes

2014-05-28 Thread Vik Fearing
On 05/26/2014 08:19 PM, Vik Fearing wrote: On 05/26/2014 07:10 AM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: I don't really object to doing an unlocked check for another such database, but I'm not convinced that additional locking to try to prevent a race is worth its keep

[HACKERS] idle_in_transaction_timeout

2014-06-03 Thread Vik Fearing
This patch implements a timeout for broken clients that idle in transaction. This is a TODO item. When the timeout occurs, the backend commits suicide with a FATAL ereport. I thought about just aborting the transaction to free the locks but decided that the client is clearly broken so might as

Re: [HACKERS] idle_in_transaction_timeout

2014-06-03 Thread Vik Fearing
On 06/03/2014 03:30 PM, Abhijit Menon-Sen wrote: At 2014-06-03 15:06:11 +0200, vik.fear...@dalibo.com wrote: This patch implements a timeout for broken clients that idle in transaction. I think this is a nice feature, but I suggest that (at the very least) the GUC should be named

Re: [HACKERS] idle_in_transaction_timeout

2014-06-03 Thread Vik Fearing
On 06/04/2014 01:38 AM, Josh Berkus wrote: On 06/03/2014 02:53 PM, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: Out of curiosity, how much harder would it have been just to abort the transaction? I think breaking the connection is probably the right behavior, but before folks start

Re: [HACKERS] idle_in_transaction_timeout

2014-06-03 Thread Vik Fearing
On 06/04/2014 02:01 AM, David G Johnston wrote: ​Default to dropping the connection but give the usersadministrators the capability to decide for themselves? Meh. I still haven't heard an argument for why this wouldn't apply to aborted idle-in-transactions. I get the focus in on releasing

Re: [HACKERS] RETURNING PRIMARY KEY syntax extension

2014-06-09 Thread Vik Fearing
On 06/09/2014 09:06 AM, Gavin Flower wrote: From memory all unique keys can be considered 'candidate primary keys', but only one can be designated 'the PRIMARY KEY'. Almost. Candidate keys are also NOT NULL. -- Vik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Allowing NOT IN to use ANTI joins

2014-06-09 Thread Vik Fearing
On 06/08/2014 02:36 PM, David Rowley wrote: + if (!get_attnotnull(tle-resorigtbl, tle-resorigcol)) + return false; As Marti says, you can't do this because NOT NULL doesn't have an oid to attach a dependency to. You'll have to restrict this test to primary keys

Re: [HACKERS] RETURNING PRIMARY KEY syntax extension

2014-06-10 Thread Vik Fearing
On 06/09/2014 07:13 PM, Andres Freund wrote: On 2014-06-09 13:42:22 +0200, Vik Fearing wrote: On 06/09/2014 09:06 AM, Gavin Flower wrote: From memory all unique keys can be considered 'candidate primary keys', but only one can be designated 'the PRIMARY KEY'. Almost. Candidate keys are also

Re: [HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules

2014-06-17 Thread Vik Fearing
On 06/17/2014 09:43 AM, Hannu Krosing wrote: On 06/14/2014 09:35 PM, Tom Lane wrote: As I mentioned awhile ago, I'm thinking about implementing the SQL-standard construct UPDATE foo SET ..., (a,b,...) = (SELECT x,y,...), ... I've run into a rather nasty problem, which is how does

Re: [HACKERS] GSoC on WAL-logging hash indexes

2014-06-19 Thread Vik Fearing
On 04/30/2014 11:41 PM, Tom Lane wrote: We really oughta fix the WAL situation, not just band-aid around it. After re-reading this thread, it is not clear that anyone is going to work on it so I'll just ask: Is anyone working on this? If not, I'd like to put it on my plate. -- Vik --

Re: [HACKERS] Minmax indexes

2014-06-19 Thread Vik Fearing
On 06/18/2014 12:46 PM, Andres Freund wrote: Isn't 'simpler implementation' a valid reason that's already been discussed onlist? Obviously simpler implementation doesn't trump everything, but it's one valid reason... Note that I have zap to do with the design of this feature. I work for

Re: [HACKERS] idle_in_transaction_timeout

2014-06-19 Thread Vik Fearing
On 06/19/2014 05:42 PM, Kevin Grittner wrote: Abhijit Menon-Sen a...@2ndquadrant.com wrote: At 2014-06-19 10:58:34 +0200, pavel.steh...@gmail.com wrote: pgbouncer has idle_transaction_timeout defined some years without any problems, so we can take this design idle_transaction_timeout

Re: [HACKERS] change alter user to be a true alias for alter role

2014-06-19 Thread Vik Fearing
On 01/20/2014 03:31 PM, Jov wrote: the doc say: ALTER USER is now an alias for ALTER ROLE http://www.postgresql.org/docs/devel/static/sql-alterrole.html. but alter user lack the following format: [...] this make alter user a true alias for alter role. This is a

Re: [HACKERS] change alter user to be a true alias for alter role

2014-06-19 Thread Vik Fearing
On 06/19/2014 07:18 PM, Tom Lane wrote: Jov am...@amutu.com writes: the doc say: ALTER USER is now an alias for ALTER ROLEhttp://www.postgresql.org/docs/devel/static/sql-alterrole.html but alter user lack the following format: ... If we're going to have a policy that these commands be

Re: [HACKERS] Window function optimisation, allow pushdowns of items matching PARTITION BY clauses

2014-06-20 Thread Vik Fearing
I've had a chance to look at this and here is my review. On 04/14/2014 01:19 PM, David Rowley wrote: I've included the updated patch with some regression tests. The first thing I noticed is there is no documentation, but I don't think we document such things outside of the release notes, so

Re: [HACKERS] SQL access to database attributes

2014-06-21 Thread Vik Fearing
On 06/21/2014 10:11 PM, Pavel Stehule wrote: Hello I am looking createdb_alterdb_grammar_refactoring.v1.patch http://www.postgresql.org/message-id/53868e57.3030...@dalibo.com Thank you for looking at this. Is any reason or is acceptable incompatible change CONNECTION_LIMIT instead

Re: [HACKERS] SQL access to database attributes

2014-06-21 Thread Vik Fearing
On 06/21/2014 10:21 PM, Pavel Stehule wrote: Second question related to second patch: Must be new syntax ALLOW_CONNECTIONS? It doesn't *have* to be called that, but that's what the corresponding column in pg_database is called so why add confusion? (Actually, it's called datallowconn but

Re: [HACKERS] idle_in_transaction_timeout

2014-06-21 Thread Vik Fearing
On 06/21/2014 08:23 PM, Kevin Grittner wrote: OK, so I think we want to see a patch based on v1 (FATAL approach) with a change of the name to idle_in_transaction_session_timeout and the units changed to milliseconds. I don't see why the remoteversion test shouldn't be changed to use 90500

Re: [HACKERS] idle_in_transaction_timeout

2014-06-23 Thread Vik Fearing
On 06/22/2014 07:47 PM, Andres Freund wrote: On 2014-06-22 09:27:24 -0700, Kevin Grittner wrote: Andres Freund and...@2ndquadrant.com wrote: The idea with the GUC name is that if we ever get support for cancelling transactions we can name that idle_in_transaction_transaction_timeout? That

Re: [HACKERS] please review source(SQLServer compatible)‏

2014-06-23 Thread Vik Fearing
On 06/23/2014 04:51 PM, rohtodeveloper wrote: 1.SQL statement support INSERT statement without INTO keyword DELETE statement without FROM keywork Why would we want this? -- Vik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] SQL access to database attributes

2014-06-23 Thread Vik Fearing
On 06/23/2014 06:21 PM, Robert Haas wrote: On Sun, Jun 22, 2014 at 2:59 PM, Pavel Stehule pavel.steh...@gmail.com wrote: I found only one problem - first patch introduce a new property CONNECTION_LIMIT and replace previously used CONNECTION LIMIT in documentation. But CONNECTION LIMIT is

Re: [HACKERS] idle_in_transaction_timeout

2014-06-24 Thread Vik Fearing
On 06/22/2014 05:11 PM, Kevin Grittner wrote: I found one substantive issue that had been missed in discussion, though. The patch modifies the postgres_fdw extension to make it automatically exempt from an attempt to set a limit like this on the server to which it connects. I'm not sure

Re: [HACKERS] idle_in_transaction_timeout

2014-06-24 Thread Vik Fearing
On 06/24/2014 03:29 PM, David G Johnston wrote: On Tue, Jun 24, 2014 at 9:20 AM, Vik Fearing [via PostgreSQL] [hidden email] /user/SendEmail.jtp?type=nodenode=5808883i=0wrote: On 06/22/2014 05:11 PM, Kevin Grittner wrote: I found one substantive issue that had been missed

Re: [HACKERS] idle_in_transaction_timeout

2014-06-24 Thread Vik Fearing
On 06/24/2014 04:04 PM, Robert Haas wrote: If the local transaction is actually idle in transaction and the local server doesn't have a timeout, we're no worse off than before this patch. I think we are. First, the correct timeout is a matter of remote-server-policy, not

  1   2   3   >