Hi,
Simon Riggs wrote:
In practice, many lock contention situations are caused by long running
idle transactions, so having a deadlock detector be able to resolve a
situation by deciding that an idle xact is actually in some kind of wait
state would be very useful.
Hm.. so you'd abort the
On Sat, Jan 2, 2010 at 03:13, Bruce Momjian br...@momjian.us wrote:
Magnus Hagander wrote:
I have adapted the win64 patches a bit, and now have a working build.
As in it runs the regression tests fine. However, I have well over a
thousand warnings of the type:
conversion from 'size_t' to
On Sat, Jan 2, 2010 at 02:20, Alvaro Herrera alvhe...@commandprompt.com wrote:
Magnus Hagander wrote:
I therefor propose that we rename this file to config.pl.default,
and change the scripts to first load config.pl.default, and then load
config.pl if it exists. config.pl then lives completely
Hello all,
With New Year !
I realized my own gist index, and now I want to debug it :) I want to use
amdb program
http://gist.cs.berkeley.edu/libgist-2.0/install.html
But I have problem with installing it.
When I running gmake cmdline
It doesn't find iostream.h file :( and uses g++ (it is c++
Sergej Galkin sergej.gal...@gmail.com writes:
I realized my own gist index, and now I want to debug it :)
I used Gevel for that:
http://www.sai.msu.su/~megera/wiki/Gevel
Regards,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Tom Lane wrote:
If you can set it up in such a way that the default behavior doesn't
change, this would be workable. I don't think we want people to
suddenly find their stuff installing in the wrong place.
It probably wouldn't be that hard, something along the lines of
ifndef
On fre, 2010-01-01 at 16:32 +0100, Magnus Hagander wrote:
I therefor propose that we rename this file to config.pl.default,
and change the scripts to first load config.pl.default, and then load
config.pl if it exists.
I'd keep the naming so that the extension .pl is preserved. Helps
editors
When trying to build plpython on win64, it fails because ssize_t is
defined differently.
PostgreSQL has it as
typedef long ssize_t;
And python has it as:
typedef __int64 ssize_t;
The postgresql deifnition comes from include/port/win32.h, which leads
me to think that we should just change that
(2009/12/30 10:38), Robert Haas wrote:
2009/12/16 KaiGai Koheikai...@ak.jp.nec.com:
It is a patch for the matter which I reported before.
When a column is inherited from multiple relations, ALTER TABLE with
RENAME TO option is problematic.
This patch fixes the matter. In correctly, it prevent
On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
When trying to build plpython on win64, it fails because ssize_t is
defined differently.
PostgreSQL has it as
typedef long ssize_t;
And python has it as:
typedef __int64 ssize_t;
What file/line is that? I don't see that in my
On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
When trying to build plpython on win64, it fails because ssize_t is
defined differently.
PostgreSQL has it as
typedef long ssize_t;
And python has it as:
typedef
Magnus Hagander mag...@hagander.net writes:
I'm not entirely sure what the type is for, though,
It's supposed to be the same width as size_t but signed. I would assume
that it should be 64 bits on Win64.
According to SUS this type should be provided by sys/types.h:
Magnus Hagander wrote:
On Sat, Jan 2, 2010 at 03:13, Bruce Momjian br...@momjian.us wrote:
Magnus Hagander wrote:
I have adapted the win64 patches a bit, and now have a working build.
As in it runs the regression tests fine. However, I have well over a
thousand warnings of the type:
2009/12/30 Robert Haas robertmh...@gmail.com:
On Tue, Dec 29, 2009 at 3:19 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
here is patch
The error handling in quote_literal() doesn't look right to me. The
documentation for PQescapeStringConn says that it stores an error
message in the
Pavel Stehule pavel.steh...@gmail.com writes:
a) print correct message and exit(1)
Which part of no, you're not doing that wasn't clear to you?
The error handling in this function should be no different from that
in the existing escaping functions. exit(1) is completely unacceptable.
Pavel Stehule pavel.steh...@gmail.com writes:
here is patch
I looked at this patch a bit, and I think the real problem with it is
that it's not multibyte safe. You've copied backend code that is
allowed to assume it's in a safe encoding (ie, one where multibyte
characters can't contain
2010/1/2 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
a) print correct message and exit(1)
Which part of no, you're not doing that wasn't clear to you?
The error handling in this function should be no different from that
in the existing escaping functions.
2010/1/2 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
here is patch
I looked at this patch a bit, and I think the real problem with it is
that it's not multibyte safe. You've copied backend code that is
allowed to assume it's in a safe encoding (ie, one where
KaiGai Kohei kai...@kaigai.gr.jp writes:
(2009/12/30 10:38), Robert Haas wrote:
No longer applies. Can you rebase?
The attached patch is the rebased revision.
I'm not really impressed with this patch, because it will reject
perfectly legitimate multiple-inheritance cases (ie, cases where
Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk writes:
Please find the revised v2 patch attached for comment. The one thing I
have done is separated out the moduledir variable into datamoduledir and
docmoduledir so there is a little bit of wiggle room if someone needs to
install DATA
On Sat, Jan 2, 2010 at 16:59, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
I'm not entirely sure what the type is for, though,
It's supposed to be the same width as size_t but signed. I would assume
that it should be 64 bits on Win64.
Yeah, seems
Folks,
Please find enclosed a patch which adds tab completion for DO blocks.
Thanks to Andrew Gierth and Stefan Kaltenbrunner for help putting it
together :)
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype:
David Fetter da...@fetter.org writes:
Please find enclosed a patch which adds tab completion for DO blocks.
Seems (a) rather pointless and (b) wrong in detail.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Please find enclosed a patch which adds tab completion for DO
blocks.
Seems (a) rather pointless and
I don't find it so.
(b) wrong in detail.
How? That it can't look back past the code
David Fetter da...@fetter.org writes:
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
(b) wrong in detail.
How?
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pltab, or just compare
source to the original
On Sat, Jan 02, 2010 at 04:53:45PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
(b) wrong in detail.
How?
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do
David Fetter da...@fetter.org writes:
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pltab, or just compare
source to the original Query_for_list_of_languages.
Thanks for the heads-up. New patch attached :)
My inclination is
On Sat, Jan 02, 2010 at 05:10:08PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pltab, or just compare
source to the original Query_for_list_of_languages.
It is possible to get an invalid byte sequence into a text field via pl,
in this case pl/perl :
---8--8--8--8--8--8---
CREATE TABLE utf_test
(
id serial PRIMARY KEY,
data character varying
);
CREATE OR REPLACE FUNCTION invalid_utf_seq()
RETURNS character varying AS
David Fetter da...@fetter.org writes:
My inclination is to not have the separate query at all,
I made one so people couldn't tab complete themselves an unpleasant
surprise. The overhead doesn't seem huge.
What unpleasant surprise is that going to be? They'll get an error
message telling
Hannu Krosing wrote:
[plperl can return data that is not valid in the server encoding and it
is not caught]
This results in a table, which has invalid utf sequence in it and
consequently does not pass dump/load
What would be the best place to fix this ?
Should there be checks in all text
On lör, 2010-01-02 at 16:29 +0100, Magnus Hagander wrote:
On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
When trying to build plpython on win64, it fails because ssize_t is
defined differently.
PostgreSQL
On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2010-01-02 at 16:29 +0100, Magnus Hagander wrote:
On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2010-01-02 at 15:42 +0100, Magnus Hagander wrote:
When trying to build plpython on
Magnus Hagander mag...@hagander.net writes:
On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut pete...@gmx.net wrote:
Seems kind of buggy. They shouldn't be defining it at all.
Why not? Should they just stop using it? In that case, so should we, no?
What's buggy is M$ failing to provide it in
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut pete...@gmx.net wrote:
Seems kind of buggy. ?They shouldn't be defining it at all.
Why not? Should they just stop using it? In that case, so should we, no?
What's buggy is M$
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I think the Python guys are up against the same problem as us, namely
substituting for the platform's failure to define the type.
I am unclear if accepting what Python chose as a default is the right
route vs. doing more research.
What
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I think the Python guys are up against the same problem as us, namely
substituting for the platform's failure to define the type.
I am unclear if accepting what Python chose as a default is the right
route vs.
Bruce Momjian br...@momjian.us writes:
Well, I saw two definitions listed in this thread, and it wasn't clear
to me the Python one was known to be the correct one:
PostgreSQL has it as
typedef long ssize_t;
That one is our 32-bit-only definition.
regards,
On Sun, Jan 3, 2010 at 01:01, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I think the Python guys are up against the same problem as us, namely
substituting for the platform's failure to define the type.
I am unclear if
Magnus Hagander wrote:
On Sun, Jan 3, 2010 at 01:01, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I think the Python guys are up against the same problem as us, namely
substituting for the platform's failure to define
Bruce Momjian br...@momjian.us writes:
OK, so my question is whether __int64 is the right definition or only
what Python chose.
I see no reason to question either the width or the signedness.
If you do, feel free to research away.
regards, tom lane
--
Sent via
On sön, 2010-01-03 at 00:24 +0100, Magnus Hagander wrote:
On Sun, Jan 3, 2010 at 00:20, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2010-01-02 at 16:29 +0100, Magnus Hagander wrote:
On Sat, Jan 2, 2010 at 16:23, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2010-01-02 at 15:42 +0100,
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
As for the overhead, these queries are not zero-maintenance. I still
think that the usefulness of tab completion here is pretty darn
minimal,
since most people are more likely to rely on default_do_language;
We really don't have any data on
Peter Eisentraut pete...@gmx.net writes:
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
As for the overhead, these queries are not zero-maintenance. I still
think that the usefulness of tab completion here is pretty darn
minimal,
since most people are more likely to rely on
On fre, 2010-01-01 at 17:19 -0500, Andrew Dunstan wrote:
Mine for one :-). Quite apart from any other reason I would expect it to
make indexing parts of the JSON more tractable. Say we use it to store a
web session object, which is a natural enough use. I might well want to
find or modify
This evening's argument about DO completion caused me to look a bit
closer at tab-complete.c than I ever had before. I am now wondering
exactly why we bother with all the logic like
WHERE substring(pg_catalog.quote_ident(rolname),1,%d)='%s'
in the SQL queries that it issues. It appears to me
Andrew Dunstan wrote:
I think the plperl glue code should check returned strings using
pg_verifymbstr().
Please test this patch. I think we'd probably want to trap the encoding
error and issue a customised error message, but this plugs all the holes
I can see with the possible
On Sun, Jan 3, 2010 at 1:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If the conditions
were phrased in a way that made them indexable, they might be worth the
trouble --- but they aren't.
Wow, that is weird, especially since it's *easier* to write them
properly using LIKE anyways.
--
greg
--
2010/1/2 Peter Eisentraut pete...@gmx.net:
On tor, 2009-12-31 at 11:28 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
The definition of c.h is bogus anyway. You might think it contains
includes and defines to set up a portable C environment, which is what
the first half
Peter Eisentraut wrote:
On fre, 2010-01-01 at 16:32 +0100, Magnus Hagander wrote:
I therefor propose that we rename this file to config.pl.default,
and change the scripts to first load config.pl.default, and then load
config.pl if it exists.
I'd keep the naming so that the extension
2010/1/3 Peter Eisentraut pete...@gmx.net:
On fre, 2010-01-01 at 17:19 -0500, Andrew Dunstan wrote:
Mine for one :-). Quite apart from any other reason I would expect it to
make indexing parts of the JSON more tractable. Say we use it to store a
web session object, which is a natural enough
Hitoshi Harada wrote:
A question: Isn't there no possibility that we have our own
implementation to handle JSON (i.e. no use of external libraries)?
Why should we reinvent a wheel someone else has already invented? This
is what shared libraries are all about.
cheers
andrew
--
Sent
2010/1/3 Andrew Dunstan and...@dunslane.net:
Hitoshi Harada wrote:
A question: Isn't there no possibility that we have our own
implementation to handle JSON (i.e. no use of external libraries)?
Why should we reinvent a wheel someone else has already invented? This is
what shared
Greg Stark gsst...@mit.edu writes:
On Sun, Jan 3, 2010 at 1:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If the conditions
were phrased in a way that made them indexable, they might be worth the
trouble --- but they aren't.
Wow, that is weird, especially since it's *easier* to write them
On Fri, Jan 1, 2010 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
another parameter that is interesting is seq_page_cost, AFAIUI all the
other cost parameters (in the planner section of course) are relative
to this one. so what is the logic in allow changing it?
Please read the discussions
55 matches
Mail list logo
