Hello,
just doing an upgrade form PostgreSQL 8.4.4 on Windows 2007 64bit to
PostgreSQL 9.0 64bit on the same system.
I am working along
http://developer.postgresql.org/pgdocs/postgres/pgupgrade.html
There is written:
NET STOP postgresql-8.4
NET STOP postgresql-9.0
or
NET STOP pgsql-8.3
Hello,
there is updated version - with support of window clause. The limits
are work_mem for using inside window aggregate or unlimited when it is
used as standard query.
This patch needs a few work - can share a compare functionality with
tuplesort.c, but I would to verify a concept now.
Hello Peter
Is there any reason why you prohibit a different encodings per one
database? Actually people expect from collate per column a possibility
to store a two or more different encodings per one database. Without
this possibility - only UTF8 is possible for practical work - and for
other
On Sun, Sep 26, 2010 at 1:15 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Is there any reason why you prohibit a different encodings per one
database? Actually people expect from collate per column a possibility
to store a two or more different encodings per one database.
These are two
On 09/26/2010 09:37 AM, Greg Stark wrote:
We could have a
encoded_text data type which includes both the encoding and the string
and which any comparison function automatically handles conversion
based on the encoding of the collation requested -- but I wouldn't
want that to be the default
On 25/09/10 19:43, Peter Eisentraut wrote:
I'm not subscribed to pgsql-committers, but apparently under the new
git-enabled setup, I'm getting a Stalled post to pgsql-committers
message for every commit. Fix that please.
Just subscribe with 'nomail'. That's what I did.
--
Heikki
On Sun, Sep 26, 2010 at 15:39, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 25/09/10 19:43, Peter Eisentraut wrote:
I'm not subscribed to pgsql-committers, but apparently under the new
git-enabled setup, I'm getting a Stalled post to pgsql-committers
message for every
I have these types:
CREATE TYPE p_type AS
(
x double precision,
y double precision
);
CREATE TYPE d_type AS
(
i p_type,
e p_type,
id integer
);
CREATE OR REPLACE FUNCTION d_swap(d_type)
RETURNS d_type
AS '/home/user/PostgreSQL/9.0/lib/mylib','d_swap'
LANGUAGE C STRICT;
My problem is that I
On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Still more tweaking of git_changelog.
1. Don't assume there's only one candidate match; check them all and use the
one with the closest timestamp. Avoids funny output when someone makes
several successive commits with the
On Thu, Sep 23, 2010 at 11:34 PM, Dennis Björklund d...@zigo.dhs.org wrote:
On Wed, Sep 22, 2010 at 6:03 AM, Dennis Björklund d...@zigo.dhs.org wrote:
But I confess that I'm sort of murky on how ORDER affects the window
frame, or how to rephrase this more sensibly.
The rows included in the
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Still more tweaking of git_changelog.
Uhm, could you stop massively changing the behavior of this script
with no discussion at all?
Uh, there was no discussion of the original
On Fri, Sep 24, 2010 at 9:13 AM, Dmitriy Igrishin dmit...@gmail.com wrote:
Tell me please, why lo_write() returns me the number of bytes actually
written
when current write location is out of 2GB ? IMO, in this case it should
returns
at least zero.
lo_read() returns zero in this case, and it
Marios Vodas mvo...@gmail.com writes:
My problem is that I don't know how to construct the d_type tuple in the c
function.
Seems like the main problem with that function is that you're passing
an uninitialized nulls array to heap_form_tuple.
I kinda wonder why you are using a fixed-length
Hey Robert,
Yes, I am sure. I've tested it by test case in my original post.
Do you can compile and reproduce it please?
--
// Dmitriy.
On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Still more tweaking of git_changelog.
Uhm, could you stop massively changing the behavior of this script
with no
I see what you mean and I changed the code BUT still my main problem is that
I want to know how to fill values array. I remind you that d_type contains
attributes of another composite type p_type.
I need a solution to that because I need to use it in other parts of the
code.
Datum
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm? As far as I can tell, this fixes that not breaks it. The problem
I was seeing was that commits would be attributed to a branch when in
fact they were made before the branch ever
Marios Vodas mvo...@gmail.com writes:
//I need to get this working
*values[0] = e;*
*values[1] = i;*
Maybe you're missing HeapTupleGetDatum() there? Just from a data type
cleanliness standpoint, you shouldn't ever assign something to Datum or
vice versa without applying the correct
I wrote:
If we could figure out how to show which major release a master-branch
commit antedated, and which point release a back-branch commit
antedated, I think we would have something that's actually significantly
more useful for both purposes than either of these behaviors.
I think we
On Sun, Sep 26, 2010 at 1:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
If we could figure out how to show which major release a master-branch
commit antedated, and which point release a back-branch commit
antedated, I think we would have something that's actually significantly
more
Suppose I had the data that form the returning tuple in 5 variables like
this:
float8 xi = 1;
float8 yi = 2;
float8 xe = 3;
float8 ye = 4;
int32 id = 1;
In addition the function wouldn't have any input parameters. It just returns
a tuple of type d_type.
Can you tell me how it is possible to form
Hmm... it is true that average will produce the same results on any
ordering of the same set of input values, though. Perhaps the word
partition emcompass that, though then again maybe not.
I'd be happy to fix this if I understand what to fix it to.
I wish I knew how to rephrase it so it is
Robert Haas robertmh...@gmail.com writes:
But I still want an option for the original behavior. I have been
using it extensively and I like it.
You really think this:
Author: Tom Lane t...@sss.pgh.pa.us
Branch: master [872c1497f] 2005-05-24 18:02:31 +
Branch: REL9_0_STABLE [872c1497f]
On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
[Do you really want the behavior you said you wanted?]
Yes.
? It's not hard to offer an option for that, I guess, but I foresee an
argument about what the default is going to be.
If there's no clear consensus, I'm OK with
Seems like it's probably a good idea, but I wanted to double-check
that no one has a different thought.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
gitignore-regression-failures.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list
--On 25. September 2010 19:55:02 -0300 José Arthur Benetasso Villanova
jose.art...@gmail.com wrote:
One thing that I take notice is when you create a simple table like this
one: select count(*) from pg_constraint ; 12 rows appears in
pg_constraint, 10 to the sequence. Is that ok?
Not sure
Do you think it would be better to change d_type to this?
CREATE TYPE d_type AS
(
xi double precision,
yi double precision,
xe double precision,
ye double precision,
id integer
);
*Note: This is NOT something I want to do but if there is no other way to
form d_type tuple from the variables...*
Robert Haas wrote:
Hmm... it is true that average will produce the same results on any
ordering of the same set of input values, though.
Not exactly. For floating point approximations you get a more
accurate sum (and therefore a more accurate average) if you add the
values in ascending
On Sat, Sep 25, 2010 at 14:49, Robert Haas robertmh...@gmail.com wrote:
On Sat, Sep 25, 2010 at 8:28 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
It looks like your transition to git has been a success. Your very
careful conversion from CVS to git and your exacting scrutiny of the
On Sun, Sep 26, 2010 at 2:11 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 25. September 2010 19:55:02 -0300 José Arthur Benetasso Villanova
jose.art...@gmail.com wrote:
One thing that I take notice is when you create a simple table like this
one: select count(*) from pg_constraint ; 12
I wrote:
I think we could get that behavior fairly easily by remembering the last
tag matching one of the commits on a branch, as we chase the branch
backwards.
I find that this works just fine for the branches, but not so well for
master, because more often than not the initial RELx_y_z tag
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
? It's not hard to offer an option for that, I guess, but I foresee an
argument about what the default is going to be.
If there's no clear consensus, I'm OK with the time-honored
Robert Haas robertmh...@gmail.com writes:
Seems like it's probably a good idea, but I wanted to double-check
that no one has a different thought.
-1. If the lack of an ignore causes a problem for you, it indicates
that you're trying to commit code that fails the regression tests.
Is it really
On Sun, Sep 26, 2010 at 3:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We could perhaps fix that if there were an inexpensive way to get the
SHA1 of the master commit that each branch is sprouted from. However,
I'm inclined to propose that we instead manually place a tag at each
sprout point.
Robert Haas robertmh...@gmail.com writes:
I think his question was - how do we feel about the massive catalog
bloat this patch will create?
It's a fair question.
I can imagine designing things so that we don't create an explicit
pg_constraint row for the simplest case of an unnamed,
On Sun, Sep 26, 2010 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Seems like it's probably a good idea, but I wanted to double-check
that no one has a different thought.
-1. If the lack of an ignore causes a problem for you, it indicates
that
Is it posible? Either by using heap_form_tuple or BuildTupleFromCStrings.
CREATE TYPE p_type AS
(
x double precision,
y double precision
);
CREATE TYPE d_type AS
(
i p_type,
e p_type,
id integer
);
CREATE OR REPLACE FUNCTION demo()
RETURNS d_type
AS
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 26, 2010 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
-1. If the lack of an ignore causes a problem for you, it indicates
that you're trying to commit code that fails the regression tests.
Is it really a good idea to let that happen
I wrote:
We could perhaps fix that if there were an inexpensive way to get the
SHA1 of the master commit that each branch is sprouted from. However,
I'm inclined to propose that we instead manually place a tag at each
sprout point.
Hah, I have a plan. Let's just run git log for
On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
We could perhaps fix that if there were an inexpensive way to get the
SHA1 of the master commit that each branch is sprouted from. However,
I'm inclined to propose that we instead manually place a tag at each
sprout
On Sun, Sep 26, 2010 at 4:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The reason I assumed we'd want to ignore these is because they're
automatically generated files - unlike *.rej files, which are never
going to end up in your tree as a result of make anything. It doesn't
actually matter that
Hi,
I noticed that there's no way to specify the location of recovery.conf
in postgresql.conf. The pg_hba and pg_ident files can be altered, so
I'm wondering why this file can't have a specified location. In
Ubuntu, all configuration files are in a different location to the
cluster by default,
Hello again,
I checked the code for the keepalive feature. It seems that the socket
options are only set on the primary's socket connection. The tcp connection
created on the secondary for walreceiver does not use the keepalive
parameters from the configuration.
Am I correct? Is this intended or
On Mon, Sep 27, 2010 at 7:46 AM, fazool mein fazoolm...@gmail.com wrote:
I checked the code for the keepalive feature. It seems that the socket
options are only set on the primary's socket connection. The tcp connection
created on the secondary for walreceiver does not use the keepalive
Ah, great. I missed looking there.
Thanks.
On Sun, Sep 26, 2010 at 4:19 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 27, 2010 at 7:46 AM, fazool mein fazoolm...@gmail.com wrote:
I checked the code for the keepalive feature. It seems that the socket
options are only set on the
On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown t...@linux.com wrote:
I noticed that there's no way to specify the location of recovery.conf
in postgresql.conf. The pg_hba and pg_ident files can be altered, so
I'm wondering why this file can't have a specified location. In
Ubuntu, all
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hah, I have a plan. Let's just run git log for master..RELx_y_STABLE
for each branch, rather than all the way back.
This doesn't seem more reliable to me in any way. Looking at the
Marios Vodas mvo...@gmail.com writes:
Is it posible? Either by using heap_form_tuple or BuildTupleFromCStrings.
heap_form_tuple followed by HeapTupleGetDatum should work; that's what's
done in ExecEvalRow() for instance. You've omitted to tell us just
what's going wrong for you.
On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown t...@linux.com wrote:
I noticed that there's no way to specify the location of recovery.conf
in postgresql.conf. The pg_hba and pg_ident files can be altered, so
I'm wondering
Jaime Casanova ja...@2ndquadrant.com writes:
On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown t...@linux.com wrote:
I noticed that there's no way to specify the location of recovery.conf
in postgresql.conf.
+1
That
On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hah, I have a plan. Let's just run git log for master..RELx_y_STABLE
for each branch, rather than all the way back.
On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova ja...@2ndquadrant.com writes:
On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown t...@linux.com wrote:
I noticed that there's no way to specify
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I looked at doing that but it didn't seem like an improvement. Take
a look at the new version and see what you think.
I'm not really sure. I suppose I'll have to play with it for a
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. The original design for recovery.conf envisioned that it has only
a short lifespan while you're doing an archive recovery. Putting
parameters for slave operation into it has
On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I maintain that if someone else whacked around one of your commits the
way you whacked this around, you'd bite their head off.
:) Yes, he would.
On Sun, Sep 26, 2010 at 9:14 PM, Gurjeet Singh singh.gurj...@gmail.com wrote:
On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I maintain that if someone else whacked around one of your commits the
On Mon, Sep 27, 2010 at 3:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Sep 26, 2010 at 9:14 PM, Gurjeet Singh singh.gurj...@gmail.com
wrote:
On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas robertmh...@gmail.com
wrote:
On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane t...@sss.pgh.pa.us
On Sun, Sep 26, 2010 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. The original design for recovery.conf envisioned that it has only
a short lifespan while you're doing an
Attached is the patch that tries to speedup prep_buildtree script, which is
used in VPATH builds, from our configure script.
The idea is to ask `find` to emit directory listing in depth-first order so
that the `mkdir -p` will create the deepest directory first and any
subsequent `mkdir -p` on an
On Sep 26, 2010, at 2:24 PM, Tom Lane wrote:
I wrote:
I think we could get that behavior fairly easily by remembering the last
tag matching one of the commits on a branch, as we chase the branch
backwards.
I find that this works just fine for the branches, but not so well for
master,
David Christensen da...@endpoint.com writes:
On Sep 26, 2010, at 2:24 PM, Tom Lane wrote:
We could perhaps fix that if there were an inexpensive way to get the
SHA1 of the master commit that each branch is sprouted from.
Particularly with PostgreSQL's linear branch history, `git merge-base`
On Sat, Sep 25, 2010 at 7:04 AM, KaiGai Kohei kai...@kaigai.gr.jp wrote:
* The dummy_esp module and regression test for SECURITY LABEL statement.
This module allows only four labels: unclassified, classified,
secret and top secret. The later two labels can be set by only
superusers. The new
All,
While working on some database maintenance, I was just tripped up by the
fact that there is no good way to query reloptions for tables. By no
good way I mean no way which does not involve UNNEST and regexps or
procedural code.
This puts us in the wierd place that while one can ALTER
On Mon, Sep 27, 2010 at 2:19 PM, Josh Berkus j...@agliodbs.com wrote:
While working on some database maintenance, I was just tripped up by the
fact that there is no good way to query reloptions for tables. By no good
way I mean no way which does not involve UNNEST and regexps or procedural
64 matches
Mail list logo
