Hi, i have run into the following problem.
Let me describe the context first.
When i joined the company(ies) i work for (a group of Shipping Mgmt/
Owenship/Agent companies), the only thing i was told when i started
designing the DB/Apps was just one company.
So i built everything into one single
Hi, Achilleus,
Achilleus Mantzios wrote:
> Now i am thinking of restructuring the whole architecture as:
> - Create one EAR app for every mgmt company
> - Create one DB USER for every mgmg company
> - Create one SCHEMA (same as the USER) for every mgmt company
> (mgmtcompany1,mgmtcompany2,etc...
how about having a company table, and company_code column across all relevant table, although you'll have to modify your application also, which would be an additional clause in the WHERE condition e.g where company_code = 'which company user has logged in'.
The user has to specify while logging u
PGSQL I’m sure has a global variable
for the current user that you can use in an SQL statement – e.g. “SELECT
* FROM TABLE WHERE CompanyUser = ‘%CURRENTUSER%’”
You’ll have to substitute
%CURRENTUSER% with the correct global variable as I can’t think what it
is at the moment.
Andy
O Markus Schaber έγραψε στις Apr 18, 2006 :
> Hi, Achilleus,
>
> Achilleus Mantzios wrote:
>
> > Now i am thinking of restructuring the whole architecture as:
> > - Create one EAR app for every mgmt company
> > - Create one DB USER for every mgmg company
> > - Create one SCHEMA (same as the USER
O Luckys έγραψε στις Apr 18, 2006 :
> how about having a company table, and company_code column across all
> relevant table, although you'll have to modify your application also, which
> would be an additional clause in the WHERE condition e.g where company_code
> = 'which company user has logged
Hi, Achilleus,
Achilleus Mantzios wrote:
[schema trickery]
> Why do you think its ugly after all?
It is not ugly to split such things via schemas per se, but it is ugly
to use this schema trick together with a bunch of views, rules and
triggers to "upgrade" a legacy single-deployment application
Le lundi 17 avril 2006 à 19:23 +0100, Guido Barosio a écrit :
> Dunno, but it sounds like a "no" at a first sight.
>
> What about dumping with INSERTS instead of COPY ?
> That should work tho.
INSERTS in a heap of data then blocks the CPU at 90% abd just sits
there...
I'm thinking up a better pl
Le lundi 17 avril 2006 à 19:23 +0100, Guido Barosio a écrit :
> Dunno, but it sounds like a "no" at a first sight.
>
> What about dumping with INSERTS instead of COPY ?
> That should work tho.
Something is preventing the creation of all the tables, about three key
tables are missing...
Back to t
Nothing to do with file size limitations is there?
What are your system specs?
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-admin-
> [EMAIL PROTECTED] On Behalf Of tony
> Sent: 18 April 2006 2:16 pm
> To: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] downward dump comp
Le mardi 18 avril 2006 à 14:18 +0100, Andy Shellam a écrit :
> Nothing to do with file size limitations is there?
Not to my knowledge
> What are your system specs?
The public server has about 20 Gb free. It is a RHEL3 system with 1Gb
RAM.
I think that I am running up against the impossibility t
The source isn't too difficult to build for Redhat - I've done it on Fedora
3, 4 and 5 - I sometimes prefer to build the source so I can rule out
compatibility with my system if I come across any problems in the future.
What app are you using for the dump? The built-in pg_dump? What version?
If
Le mardi 18 avril 2006 à 14:32 +0100, Andy Shellam a écrit :
> If you're using your 8.1 already, try the 7.3, to rule out the possibility
> of anything in your DB causing a problem to the 8.1 pg_dump.
Something along the line of creating a ssh tunnel to the intranet server
from the public server.
I've got a database that reported this error yesterday morning after
an UPDATE statement:
ERROR: invalid page header in block 34 of relation "pg_toast_167245"
Later in the day, it reported this one:
ERROR: invalid page header in block 199 of relation "_pkey"
this time after a SELECT.
Befo
On Apr 18, 2006, at 12:30 PM, Thomas F. O'Connell wrote:
So there are currently three separate relations exhibiting invalid
page errors.
This box is a Debian 3.1 box running a custom Linux 2.6.10 #6 SMP
kernel. Postgres 8.1.3 was compiled from source. pgpool 3.0.1, also
built from source
On Tue, 2006-04-18 at 14:32 +0300, Achilleus Mantzios wrote:
> Thanx for your thoughts, but this would require touching
> 173 tables +
> 2,594 SQL statements in a sum of 324 programs (which sum into 125,085
> lines of code)
We did a very similar conversion to the one proposed here a couple of
ye
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> I would've expected the RAID to protect postgres from the possibility
> of data corruption, but I guess not.
Ooops :-(. It might be interesting to get pg_filedump dumps of the
corrupted pages, just to see what the failure pattern looks like.
I
On Apr 18, 2006, at 2:15 PM, Tom Lane wrote:
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
I would've expected the RAID to protect postgres from the possibility
of data corruption, but I guess not.
Ooops :-(. It might be interesting to get pg_filedump dumps of the
corrupted pages, just
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> In the meantime, should I leave the database online while I attempt
> to recover? It's still unclear to me whether postgres will restart
> with invalid page headers. I certainly can't run pg_dumpall, for
> instance.
Has the database success
On Apr 18, 2006, at 2:57 PM, Tom Lane wrote:
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
In the meantime, should I leave the database online while I attempt
to recover? It's still unclear to me whether postgres will restart
with invalid page headers. I certainly can't run pg_dumpall, for
Is anyone aware of documentation that describes what the valid parameters for
the PGOPTS variable
are and how they are used?
Regards,
Richard
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql
Richard Broersma Jr wrote:
> Is anyone aware of documentation that describes what the valid parameters for
> the PGOPTS variable
> are and how they are used?
I see it mentioned in the configuration and libpq sections of the
manual. It allows you to pass parameters to the startup of the backend.
All I could find similar to PGOPTS was PGOPTIONS. Are they equivalent? If they
are, would it be
safe to use PGOPTIONS in-place of PGOPTS in the /etc/conf.d/postgresql conf
file?
--- Bruce Momjian wrote:
> Richard Broersma Jr wrote:
> > Is anyone aware of documentation that describes what the
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
> All I could find similar to PGOPTS was PGOPTIONS. Are they equivalent? If
> they are, would it be
> safe to use PGOPTIONS in-place of PGOPTS in the /etc/conf.d/postgresql conf
> file?
There is no such animal as PGOPTS referenced anywhere in the
24 matches
Mail list logo
