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 esta
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 p
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 p
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
[mailto:pgs
- 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
Subject: Re: R: [GENERAL] Field's position in Table
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 requ
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
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 ch
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 organi
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 "faul
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
From: vinny
Subject: Re: R: [GENERAL] Field's position in Table
To: "Sam Mason"
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:
> > I can't really think of any r
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 fo
On Mon, Aug 24, 2009 at 12:41 PM, David Fetter 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 Mullane
>> wrote:
>> > A server crash is a pretty rare event in the Postgres world, so I
>> > would not spend too many cycles on th
On Mon, Aug 24, 2009 at 12:10:30AM -0600, Scott Marlowe wrote:
> On Sat, Aug 22, 2009 at 4:55 PM, Greg Sabino Mullane 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 ou
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 c
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 writes:
Is there a command that lists the values for the internal,
foo_foo_id_seq, sequence?
select * from foo_foo_id_seq;
Scott Frankel 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 will
take the data (a
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 got
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
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 bardin 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 requirements
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.
--
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, ordi
Tom Lane a écrit :
> Denis BUCHER 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
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, Galw
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
Denis BUCHER 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 tables present
unsubscribe
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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 wrote:
> O
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
wrote:
> 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
> > differ
On Mon, Aug 24, 2009 at 2:03 AM, Tom Lane wrote:
> Jeff Ross 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? Roll back to 8.3.7? Or ju
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:
COALESCE(fiel
On 24 Aug 2009, at 7:50, Scott Marlowe wrote:
On Sun, Aug 23, 2009 at 11:43 PM, Juan
Backson 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 will want it to return f
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. Bu
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 index
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
Hello Tom,
Tom Lane a écrit :
> Denis BUCHER 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 all, or behin
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 up
38 matches
Mail list logo
