My main disk for Postgresql crashed but I still have the database as it was
stored on a tablespace on another disk. Now the problem is how to recover from
this situation.
What I have tried is to restore the database from a backup from a few houres
before the crash and then replacing the
Hello,
There's a problem with PostgreSQL 8.0.3 SELECT. All tables exist, all
columns exist, I have no idea where's the problem :/ PostgreSQL
reports this error: ERROR: relation fieldx does not exist...
SELECT fieldx.field_id, COUNT(optionx.option_id) AS field_options
FROM c_custom_fields AS
On Sat, 16 Jul 2005, [ISO-8859-2] Ji?? N?mec wrote:
There's a problem with PostgreSQL 8.0.3 SELECT. All tables exist, all
columns exist, I have no idea where's the problem :/ PostgreSQL
reports this error: ERROR: relation fieldx does not exist...
SELECT fieldx.field_id,
Am Samstag, den 16.07.2005, 09:19 +0200 schrieb Jiří Němec:
Hello,
There's a problem with PostgreSQL 8.0.3 SELECT. All tables exist, all
columns exist, I have no idea where's the problem :/ PostgreSQL
reports this error: ERROR: relation fieldx does not exist...
SELECT fieldx.field_id,
Thanks, that looks useful. I'll investigate once I've got the servers upgraded
and replication running.
Bruno Wolff III wrote:
On Wed, Jul 13, 2005 at 18:15:12 +,
[EMAIL PROTECTED] wrote:
Many thanks Tom. Inconvenient from the point of view of the application
but still useful
I'm using postgres8 with encoding 'UNICODE'.
I have some problems with unsupported mutlibyte... e.g. with upper()
Now I know a I cannot use every lc_ctype with every encoding,
but where can I find a list of valid encoding/locale combinations?
regards
Christian
---(end
Hi!
I dumped from a 7.3.4 server on debian with kernel 2.6 using this command:
pg_dump -F c -Z 9 -f backoffice.dmp.c backoffice
I tried to restore on a similiar system using:
pg_restore -vd backoffice backoffice.dmp.c
and stepped into an error:
ERROR: copy: line 270892, Missing data for
i forgot to attach the error messages. but now!
t
On 7/16/05, Thomas Chille [EMAIL PROTECTED] wrote:
Hi!
I dumped from a 7.3.4 server on debian with kernel 2.6 using this command:
pg_dump -F c -Z 9 -f backoffice.dmp.c backoffice
I tried to restore on a similiar system using:
Stephan Szabo [EMAIL PROTECTED] writes:
On Sat, 16 Jul 2005, [ISO-8859-2] Jiøí Nìmec wrote:
There's a problem with PostgreSQL 8.0.3 SELECT. All tables exist, all
columns exist, I have no idea where's the problem :/ PostgreSQL
reports this error: ERROR: relation fieldx does not exist...
Christian Traber [EMAIL PROTECTED] writes:
Now I know a I cannot use every lc_ctype with every encoding,
but where can I find a list of valid encoding/locale combinations?
If there were a standardized way of finding that out, we'd long since
have made Postgres take advantage of it to prevent
Thomas Chille [EMAIL PROTECTED] writes:
I dumped from a 7.3.4 server on debian with kernel 2.6 using this command:
pg_dump -F c -Z 9 -f backoffice.dmp.c backoffice
I tried to restore on a similiar system using:
pg_restore -vd backoffice backoffice.dmp.c
and stepped into an error:
ERROR:
16. července 2005, 16:46:59, napsal jste:
In other words: what you probably meant here is
FROM (c_custom_fields AS fieldx CROSS JOIN
j_product_groups_fields AS join_table)
LEFT JOIN c_custom_fields_options AS optionx ON optionx.field_id =
fieldx.field_id
Thank you, your query runs but
Christian Traber wrote:
Now I know a I cannot use every lc_ctype with every encoding,
but where can I find a list of valid encoding/locale combinations?
Try something like the following:
for x in $(locale -a); do echo -n $x: ; LC_ALL=$x locale charmap; done
Unfortunately, the name of the
I have this structure:
CREATE TABLE invoicelineitemtypes (
invoicelineitemtypeid varchar(36) PRIMARY KEY,
otherstuff varchar(36)
);
CREATE TABLE invoicelineiteminventorytypes (
moresetuff varchar(36)
)
INHERITS (invoicelineitemtypes);
CREATE TABLE invoicelines (
I was faced with a similar issue. One suggestion I got from the
Internet was to create a shadow column that contains the values used in the
Index, with a dummy entry (in my case, the string NULL) for those
records in which the primary column is NULL. It works well for my
app.
Jim C. Nasby wrote:
On Thu, Jul 14, 2005 at 11:29:23PM +0200, Martijn van Oosterhout wrote:
On Thu, Jul 14, 2005 at 11:30:36AM -0500, Jim C. Nasby wrote:
On Wed, Jul 13, 2005 at 07:52:04PM -0400, Bruce Momjian wrote:
This is a good point. We have always stored data on disk that exactly
Andrus wrote:
Then redesign this as a many to many relation. ...
This means adding separate row for each department into permission table.
Not really.
You can of course store an Array of department IDs in that same table.
That would probably cause the minimum impact on your queries too.
17 matches
Mail list logo
