On Mon, 2009-08-24 at 15:25 +1000, Kushal Vaghani wrote:
Hello,
I have downloaded and built the 8.2.4 postgreSQL from source. This was
done by running the build.bat file under src\tools\msvc. I do get a
few errors with some contrib projects, but I do not care about them.
Why such an
On Sat, Aug 22, 2009 at 4:55 PM, Greg Sabino Mullaneg...@turnstep.com wrote:
A server crash is a pretty rare event in the Postgres world, so I
would not spend too many cycles on this...
I've been running pg in production since 7.0 came out. zero server crashes.
--
Sent via pgsql-general
On Mon, Aug 24, 2009 at 12:07 AM, Craig
Ringercr...@postnewspapers.com.au wrote:
On Mon, 2009-08-24 at 15:25 +1000, Kushal Vaghani wrote:
Hello,
I have downloaded and built the 8.2.4 postgreSQL from source. This was
done by running the build.bat file under src\tools\msvc. I do get a
few
Hey Craig
I am doing a research project on a particular branch of postgreSQL and we
have already had some code written on top of 8.2.4 base release few years
back. I am doing some extensions to it. So thats the reason of not using the
latest releases. There would be lot of extra patching etc.
I
On Mon, Aug 24, 2009 at 12:22 AM, Kushal Vaghanikushalvagh...@gmail.com wrote:
Hey Craig
I am doing a research project on a particular branch of postgreSQL and we
have already had some code written on top of 8.2.4 base release few years
back. I am doing some extensions to it. So thats the
On Mon, Aug 24, 2009 at 12:40 AM, Scott Marlowescott.marl...@gmail.com wrote:
On Mon, Aug 24, 2009 at 12:22 AM, Kushal Vaghanikushalvagh...@gmail.com
wrote:
Hey Craig
I am doing a research project on a particular branch of postgreSQL and we
have already had some code written on top of 8.2.4
On Sat, 2009-08-22 at 13:03 -0700, Sergey Samokhin wrote:
Hello!
To make my client application tolerant of PostgreSQL failures I first
need to be able to simulate them in a safe manner (hard reset isn't a
solution I'm looking for :)
Is there a way to disconnect all the clients as if the
On Mon, Aug 24, 2009 at 12:48 AM, Kushal Vaghanikushalvagh...@gmail.com wrote:
okay guys I will get 8.2.13, so would running the install.pl would be
different.
I will try and see if I can compile and run as mentioned from the docs. But
would there be any script after install.pl to run the
On Mon, 2009-08-24 at 16:48 +1000, Kushal Vaghani wrote:
okay guys I will get 8.2.13, so would running the install.pl would be
different.
I will try and see if I can compile and run as mentioned from the
docs. But would there be any script after install.pl to run the
postmaster, initDB
On Mon, Aug 24, 2009 at 12:49 AM, Craig
Ringercr...@postnewspapers.com.au wrote:
You should also test your client's response to the Pg server remaining
up but becoming non-responsive (eg: failed disk array causes Pg backends
to remain in uninterruptable disk I/O system calls in the kernel). A
Craig Ringer, 24.08.2009 08:51:
You'll probably want to initdb, edit the postgresql.conf created by
initdb as desired, then start the postmaster manually using pg_ctl
(making sure to point pg_ctl at the data directory you created). It's
not hard.
Yep, I have done that as well (to quickly set
Hello Tom,
Tom Lane a écrit :
Denis BUCHER dbuche...@hsolutions.ch writes:
I really don't understand what's happening here ?
\dt customers will show you the customers table that's visible
according to your search_path setting. Apparently schema import
is either not in your search path at
Hello,
Guillaume Lelarge a écrit :
I have a strange problem since I moved some tables to a schema, some
tables are missing from the list (with \d or \dt) but they are still
present anyway ???!
Example :
$ psql mybase
Bienvenue dans psql 8.1.17, l'interface interactive de PostgreSQL.
Hi,
I am using 8.3 and pgAdmin III. I have a couple of tables using 2 DATE
columns like 'startdate' and 'enddate' (just date, not interested in time in
these columns). I have some queries (some using OVERLAPS) involving both
'startdate' and 'enddate' columns. I tried to create a multi column
Hi Denis,
Le lundi 24 août 2009 à 10:21:33, Denis BUCHER a écrit :
[...]
I suppose you have something like 'rma, import, ...' for search_path, so
it only displays rma.customers and not impor.customers.
Yes that's correct. Therefore my problem is the normal behavior of
\dt. But normal
On 24 Aug 2009, at 7:50, Scott Marlowe wrote:
On Sun, Aug 23, 2009 at 11:43 PM, Juan
Backsonjuanback...@gmail.com wrote:
Hi,
Thank you for your help.
What I want to dos is as follows:
SELECT COALESCE(fieldA::text,fieldB||fieldC||fieldD) from ring where
group_id = 1
if fieldB is NULL, i
On Mon, Aug 24, 2009 at 12:54:31PM +0200, Alban Hertroys wrote:
CASE
WHEN fieldA IS NOT NULL THEN fieldA
WHEN fieldB IS NOT NULL THEN fieldB
WHEN fieldC IS NOT NULL THEN fieldC
ELSE fieldD
END
BTW, the above expression is identical to:
On Mon, Aug 24, 2009 at 2:03 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Jeff Ross jr...@wykids.org writes:
Tom Lane wrote:
heap_update is broken. Details left as an exercise for the reader
Well, as the reader that started this all ;-) should I be worried?
Should I do a pg_dump and reinstall?
Thanks Scott and Craig, I will give this a go today evening. Will let you
know if it worked.
Kushal
On Mon, Aug 24, 2009 at 4:51 PM, Craig Ringer
cr...@postnewspapers.com.auwrote:
On Mon, 2009-08-24 at 16:48 +1000, Kushal Vaghani wrote:
okay guys I will get 8.2.13, so would running the
okay guys I will get 8.2.13, so would running the install.pl would be
different.
I will try and see if I can compile and run as mentioned from the docs. But
would there be any script after install.pl to run the postmaster, initDB
Thanks.
On Mon, Aug 24, 2009 at 4:40 PM, Scott Marlowe
unsubscribe
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Denis BUCHER dbuche...@hsolutions.ch writes:
Yes that's correct. Therefore my problem is the normal behavior of
\dt. But normal means expected. But I don't find it very
secure/handy, because you expect to see all your tables. Is there a way
to change the behavior of \dt so that it lists ALL
Alvaro Herrera wrote on 24.08.2009 04:24:
I think that page is pretty much unmaintained. Feel free to add your
product, provided you don't turn it into a marketing opportunity (and be
prepared for others to edit your description).
Well, as it is a open source project, marketing doesn't really
On 24/08/2009 16:47, Thomas Kellerer wrote:
How do I get an account to edit the page?
You just sign up for a community account here:
http://www.postgresql.org/community/signup
Ray.
--
Raymond O'Donnell, Director of Music,
Tom Lane a écrit :
Denis BUCHER dbuche...@hsolutions.ch writes:
Yes that's correct. Therefore my problem is the normal behavior of
\dt. But normal means expected. But I don't find it very
secure/handy, because you expect to see all your tables. Is there a way
to change the behavior of \dt so
Hello,
Is it possible to select or otherwise view a table's primary key values?
I'm troubleshooting the following error:
ERROR: duplicate key value violates unique constraint foo_pkey
The insert that yields the error seems innocuous enough:
INSERT INTO foo (color_id,
On 24/08/2009 17:31, Scott Frankel wrote:
Is it possible to select or otherwise view a table's primary key values?
[snip]
CREATE TABLE foo (
foo_idSERIALPRIMARY KEY,
select foo_id from foo;
?
or am I missing something?
Ray.
I wasn't sure which list is better suited, so this is cross posted
from pgsql-admin.
-Thanks
On Fri, Aug 21, 2009 at 10:46 AM, james bardinjbar...@bu.edu wrote:
I have a working warm standby system, running 8.4 (thanks for urging
me to upgrade from the rehdat provided release).
One of the new
On 24/08/2009 17:31, Scott Frankel wrote:
The insert that yields the error seems innocuous enough:
INSERT INTO foo (color_id, ordinal, person_id) VALUES (1, 1019, 2);
It seems as if there's a sequence (foo_pkey) that's got some weird
values in it. The table itself looks like this:
Hi Ray,
On Aug 24, 2009, at 9:48 AM, Raymond O'Donnell wrote:
On 24/08/2009 17:31, Scott Frankel wrote:
The insert that yields the error seems innocuous enough:
INSERT INTO foo (color_id, ordinal, person_id) VALUES (1, 1019,
2);
It seems as if there's a sequence (foo_pkey) that's
Scott Frankel lekn...@pacbell.net writes:
Is there a command that lists the values for the internal,
foo_foo_id_seq, sequence?
select * from foo_foo_id_seq;
The usual way to get into this sort of trouble is to load a bunch of
data into the table while explicitly specifying ID values. It
Got it! Yes, this started happening after loading from a pg_dump.
Thanks for the explanation!
Scott
On Aug 24, 2009, at 10:52 AM, Tom Lane wrote:
Scott Frankel lekn...@pacbell.net writes:
Is there a command that lists the values for the internal,
foo_foo_id_seq, sequence?
select *
On 24/08/2009 18:37, Scott Frankel wrote:
If I understand how tables are managed internally, there are 2
sequences: my explicit foo_id and the internal sequence
foo_foo_id_seq:
public | foo_foo_id_seq | sequence | pguser |
It's this internal sequence that must be involved in the
On Mon, Aug 24, 2009 at 12:10:30AM -0600, Scott Marlowe wrote:
On Sat, Aug 22, 2009 at 4:55 PM, Greg Sabino Mullaneg...@turnstep.com wrote:
A server crash is a pretty rare event in the Postgres world, so I
would not spend too many cycles on this...
I've been running pg in production since
On Mon, Aug 24, 2009 at 12:41 PM, David Fetterda...@fetter.org wrote:
On Mon, Aug 24, 2009 at 12:10:30AM -0600, Scott Marlowe wrote:
On Sat, Aug 22, 2009 at 4:55 PM, Greg Sabino Mullaneg...@turnstep.com
wrote:
A server crash is a pretty rare event in the Postgres world, so I
would not
On Thu, 2009-08-20 at 12:16 +0100, Sam Mason wrote:
On Thu, Aug 20, 2009 at 11:24:49AM +0200, vinny wrote:
I can't really think of any real reason to put the field at a
particular position, applications don't reallty care about the order
of fields.
Because it's very convenient for ad-hoc
From: vinny vi...@xs4all.nl
Subject: Re: R: [GENERAL] Field's position in Table
To: Sam Mason s...@samason.me.uk
Cc: pgsql-general@postgresql.org
Date: Monday, August 24, 2009, 2:38 PM
On Thu, 2009-08-20 at 12:16 +0100, Sam Mason wrote:
On Thu, Aug 20, 2009 at 11:24:49AM +0200, vinny wrote:
Adam Rich wrote:
For me, saying all new fields must go at the end of the table is like
saying all new functions must go at the end of your C source file.
Not that it makes *any* difference to the end user, or other
applications using your libraries, but as developers we tend to
be more
Hello!
If, however, you mean a crash of the server machine PostgreSQL is
runnning on, which is MUCH more likely and will have different
effects/behaviour, then Ray Stell's advice to bring the interface down
is probably pretty good.
Sorry for a bit ambiguous usage of both crash and fault
Adam Rich wrote:
For me, saying all new fields must go at the end of the table is like
saying all new functions must go at the end of your C source file.
Not that it makes *any* difference to the end user, or other
applications using your libraries, but as developers we tend to
be more
Hello, Craig.
Table partitioning and table inheritance. See the manual and the list
archives.
Thanks for mentioning partitioning feature! It seems to be what I've
been looking for so far.
--
Sergey Samokhin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
Hello!
You should also test your client's response to the Pg server remaining
up but becoming non-responsive (eg: failed disk array causes Pg backends
to remain in uninterruptable disk I/O system calls in the kernel). A
possibly good way to do this is to SIGSTOP the backend(s).
I haven't
John R Pierce wrote:
otoh, reordering the fields in a table would likely require a global
exclusive access lock on the table for the duration of the
operation, which for a large table could be substantial.
Obviously you haven't read the previous proposal on how to handle it.
It doesn't
- Original Message -
From: Adam Rich
To: Sam Mason ; vinny
Cc: pgsql-general@postgresql.org
Sent: Monday, August 24, 2009 2:58 PM
Subject: Re: R: [GENERAL] Field's position in Table
From: vinny vi...@xs4all.nl
Subject: Re: R: [GENERAL] Field's
On Tue, 2009-08-25 at 00:26 +0400, Sergey Samokhin wrote:
Hello!
If, however, you mean a crash of the server machine PostgreSQL is
runnning on, which is MUCH more likely and will have different
effects/behaviour, then Ray Stell's advice to bring the interface down
is probably pretty
On Tue, 2009-08-25 at 00:26 +0400, Sergey Samokhin wrote:
Hello!
If, however, you mean a crash of the server machine PostgreSQL is
runnning on, which is MUCH more likely and will have different
effects/behaviour, then Ray Stell's advice to bring the interface down
is probably pretty
On Tue, 2009-08-25 at 00:26 +0400, Sergey Samokhin wrote:
Though I don't think there are any differences between the crash of
PosgreSQL itself and the crash of the machine PostgreSQL is running on
from the client's point of view.
There certainly are!
For one thing, if a client with an
Just to clarify a minor point - on Windows NT and newer, the COMSPEC
environment variable determines which executable runs a batch script
whether the extension is .bat or .cmd - on NT and newer this defaults to
cmd.exe.
-Original Message-
From: pgsql-novice-ow...@postgresql.org
48 matches
Mail list logo
