Heck, you're already pushing the performance envelope with 3,000 users,
might as well go for the faster of the two and you'll have one less
scheduled upgrade ahead of you.
When do you need to go live? If it's 1 month, then I'd definitely
recommend 7.4.
heh... ;)
PostgreSQL 7.4 is so
On 06 Nov 2003 15:21:03 +0100
Marek Florianczyk [EMAIL PROTECTED] wrote:
fsync = false
HOLD THE BOAT THERE BATMAN!
I would *STRONGLY* advise not running with fsync=false in production as
PG _CANNOT_ guaruntee data consistancy in the event of a hardware
failure. It would
W licie z czw, 06-11-2003, godz. 15:37, Jeff pisze:
On 06 Nov 2003 15:21:03 +0100
Marek Florianczyk [EMAIL PROTECTED] wrote:
fsync = false
HOLD THE BOAT THERE BATMAN!
I would *STRONGLY* advise not running with fsync=false in production as
PG _CANNOT_ guaruntee
Rudi Starcevic [EMAIL PROTECTED] writes:
ERROR: _mdfd_getrelnfd: cannot open relation virtualusertable: Cannot
allocate memory
Hm, that's a rather odd error code, but I suppose it must mean that you
have run out of kernel memory for file descriptor slots or inodes.
I'd like to try limiting
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Geoffrey) wrote:
I've got a client who is following my suggestion that they replace a
set of excel spreadsheets with a database solution. They are
looking at two proposals, postgresql solution or an Access solution.
The
On Thu, 6 Nov 2003, Jeff wrote:
On 06 Nov 2003 15:21:03 +0100
Marek Florianczyk [EMAIL PROTECTED] wrote:
fsync = false
HOLD THE BOAT THERE BATMAN!
I would *STRONGLY* advise not running with fsync=false in production as
PG _CANNOT_ guaruntee data consistancy in
On Thu, Nov 06, 2003 at 12:27:03AM +0100, Oli Sennhauser wrote:
If somebody is telling me now, I have to do this several times a year
(how can I sell this to a customer???)... It is not a problem handling a
micky-mouse database. dump/load 100 GB I would gess it takes me more
than 12 h, 2
Marek Florianczyk wrote, on Thursday, 11/06/03:
... And my management says, that there is no good support for Open
Source, heh... ;)))
In my experience, there is better support for Open Source than
Closed Source when it comes to development (and usually all around).
David Green
Sage
I'm receiving an error from pg_dumpall while trying to backup my
database. To explain, this database used to be 7.2.1 but we have
upgraded the server and I just used pg_dumpall and then reloaded that
data into the new system which runs on 7.3.3 The problem is I get an
error when using
On 6 Nov 2003, Marek Florianczyk wrote:
... And my management says, that there is no good support for Open
Source, heh... ;)))
That's because your support needs are different. A developer wants
answers and solutions, a manager often wants someone to blame. :-)
86 this request. I've found my problem. It seems that Dell had an old
version (7.2.2) of PostgreSQL installed. It was using pg_dump from that
version instead of the new version.
The database dump worked great with the new version.
Dave
David C. Brown wrote:
I'm receiving an error from
David Green wrote:
Marek Florianczyk wrote, on Thursday, 11/06/03:
... And my management says, that there is no good support for Open
Source, heh... ;)))
In my experience, there is better support for Open Source than
Closed Source when it comes to development (and usually all around).
Here's my config file...
pg_hba.conf
local all all
trust
PostgreSQL Users...
test=#
\du
List of database usersUser name | User ID
|
Attributes---+-+aaron
| 100 | superuser, create
databasepostgres | 1 |
superuser, create databasetesting
|
Epps, Aaron M. writes:
pg_hba.conf
localallalltrust
why when I run the following command does authentication fail (Yes, password is
correct)?
You don't need a password in this setup.
[EMAIL PROTECTED] aaron]$ psql test -U testing -W
Password:
psql: FATAL: IDENT
Thanks Tom,
Hm, that's a rather odd error code, but I suppose it must mean that you
have run out of kernel memory for file descriptor slots or inodes.
Yep, after checking with the co-location techs the limit of open file on
my Virtual Server is 2479. They've upped the limit to 3718 for me.
This
Already asked, I try again:
7.4 give the feature to have transaction in
read only mode, is it possible give permission
to an user to perform db connection in read only
mode ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 5: Have you checked
On Thu, Nov 06, 2003 at 23:59:29 +0100,
Gaetano Mendola [EMAIL PROTECTED] wrote:
Already asked, I try again:
7.4 give the feature to have transaction in
read only mode, is it possible give permission
to an user to perform db connection in read only
mode ?
Not by connection, but if they
I need to close all connections from one database and keep all
connection from the other databases in my postgresql server.
Can some body help me?
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Hi,
I am running pg 7.3.4 on linux red hat 9.0.
If I try to execute vacuum full analyze verbose, the pg vacuum some
tables and hang after this lines:
INFO: --Relation pg_toast.pg_toast_16408--
INFO: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0,
Keep/VTL 0/0, UnUsed 0, MinLen 0,
19 matches
Mail list logo
