ould be good if the 'main' partitioned table and
> its 'partitions' showed up as a different type in some way.
I've just read through this thread, and I'm wondering why we can't just
have something like \set SHOW_PARTITIONS true or something, and that
would default to false.
want to hijack the thread, but you can do that with exclusion
constraints.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
vidually, but you obviously disagree. Fair enough.>
> I guess it is that simple.
FWIW, my opinion falls in line with Robert's.
Also, whichever way it goes, this is a patch I've been wanting for a
long time.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadr
in 6ef2eba3f57.
Attached is a one-liner fix. I realize how imminent we are from
releasing v10 but I hope there is still time for such a minor issue as this.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff
aster. We should finish merging recovery.conf into
>>>> postgresql.conf.
>>>
>>> Definitely.
>>
>> There's a patch from Abhijit Menon-Sen you could adopt for PostgreSQL
>> 11 for that.
>
> Do you have a link to this?
https://commitfest.postgresql
On 10/19/2017 11:26 PM, Tom Lane wrote:
> Vik Fearing <vik.fear...@2ndquadrant.com> writes:
>> On 10/19/2017 10:54 PM, Tom Lane wrote:
>>> Uh ... recommended by whom? pg_statistic has exactly the same reliability
>>> guarantees as the rest of the system catalogs
d crash when there are
199,999,999 dead tuples, you currently get to wait for another 200
million to die before anything gets cleaned up.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
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
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:
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
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
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
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
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
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
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
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
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
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
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
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:
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
***
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
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
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:
*
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
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
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
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
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)
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
---
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
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
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
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
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
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
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
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
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)
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
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]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
--
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
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
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
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
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
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
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
1 - 100 of 202 matches
Mail list logo