I just posted a source rpm for beta2, along with binary rpms for
fc1-i386, fc2-i386, and fc2-x86_64.
http://www.joeconway.com/postgresql-8.0.0beta/
BTW, I've been naming these similar to the "official" rpms (e.g.
Postgresql-8.0.0*PGDG.*.rpm) mainly just to be consistent. No one has
complained a
I am traveling September 5-24, leaving this Sunday night, EDT. The trip
is 19 days:
9/5 leave for London
9/6 London, afternoon/evening meeting
9/7 leave for Shanghai
9/8 Shanghai
9/9 Shanghai
Yes, I just realized the problem myself. The cause is that you ran
win32.mak, creating the SYSCONFDIR-only file, then went to build ecpg
using MinGW.
We really should have a way to prevent such problems. The issue is that
Unix and MinGW builds use port/pg_config_paths.h with full values, while
hi,
I m a M.Tech student of IIT Bombay. I am working on Implementation of
Main Memory DBMS. Plz let me know, if any1 of u is working on similar kind
of project.
Regards,
Ameya.
-
| Ameya S Sakhalkar,|
| M.Tech(II), CSE, |
| C-7
You are going to have to give us more information than that? Why do it?
Do what exactly? Patch?
---
Dann Corbit wrote:
> Include the file:
> src\backend\port\dynloader\win32.h
> in dynloader.c
>
> Possibly with #ifdef fo
Jan Wieck wrote:
Which is another point I was about to ask. How do these people, running
those huge and horribly important databases, ever test a single
application change? Or any schema changes for that matter. Do they
really type "psql -c 'alter table ...' proddb" and believe they are
profes
Tom Lane wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
ERROR: invalid string enlargement request size 1476395004
DEBUG: AbortCurrentTransaction
WARNING: AbortTransaction and not in in-progress state
ERROR: could not send data to client: Broken pipe
PANIC: error during error recovery, givi
Fabien COELHO wrote:
>
> Dear hackers,
>
> > I'm happy to do the pg_dump changes, assuming Tom gets the SET stuff sorted
> > out.
>
> ISTM that the tablespace handling or ignoring in pg_dump/pg_restore is
> still an open issue in current CVS head... waiting for a proper
> implementation after t
Reini Urban wrote:
> Is it possible to test for plperl and add some plperl tests to the
> regression suite?
>
> I see the pg_regress installs and runs with_perl=no.
> The problem is that cygwin postgres builds and runs fine, only the perl
> extensions fails (IPC problem when loading the huge per
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> ERROR: invalid string enlargement request size 1476395004
> DEBUG: AbortCurrentTransaction
> WARNING: AbortTransaction and not in in-progress state
> ERROR: could not send data to client: Broken pipe
> PANIC: error during error recovery, giving up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
this morning I perform an upgrade 7.4.2 -> 7.4.5 and
after 6 months without errors this night a backend
crashed:
ERROR: invalid string enlargement request size 1476395004
DEBUG: AbortCurrentTransaction
WARNING: AbortTransaction and not in in-
Dann Corbit wrote:
I installed PostgreSQL under an account named postgres, using the
installer project.
[EMAIL PROTECTED] ~
$ psql -h localhost -U postgres -W template1
psql.exe: FATAL: Password authentication failed for user "postgres"
"-h localhost" is redundant on Windows - it's the default
I installed PostgreSQL under an account named postgres, using the
installer project.
[EMAIL PROTECTED] ~
$ psql -h localhost -U postgres -W template1
psql.exe: FATAL: Password authentication failed for user "postgres"
---(end of broadcast)---
TIP 2
On Wed, Sep 01, 2004 at 02:31:27PM -0700, Dann Corbit wrote:
> grep "administrative permissions" *.html
> In the pgsql/doc/html directory turns up nothing.
I think the relevant documentation should be here:
http://developer.postgresql.org/docs/postgres/runtime.html
Note that it talks about a Uni
grep "administrative permissions" *.html
In the pgsql/doc/html directory turns up nothing.
Administrator all seems to be linked to database administrator:
admin.html (107): > database administrator. This includes
app-ipcclean.html (153): > Only the database administrator should
execute this progra
Sorry to be such a pest. Since an administrator will get this error:
creating template1 database in u:/msys/1.0/local/pgsql/data/base/1 ...
execution of PostgreSQL by a user with administrative permissions is not
permitted.
The server must be started under an unprivileged user ID to prevent
possi
I put the following at the bottom of /msys/1.0/etc/profile:
POSTGRESHOME=/usr/local/pgsql
export MANPATH=$MANPATH:$POSTGRESHOME/man
export PATH=$PATH:$POSTGRESHOME/bin::$POSTGRESHOME/lib
export LD_LIBRARY_PATH=$POSTGRESHOME/lib
export PGDATA=$POSTGRESHOME/data
export PGLIB=$POSTGRESHOME/lib
And e
Dann Corbit wrote:
Is it normally necessary to manually export the paths:
/usr/local/pgsql/bin
/usr/local/pgsql/lib
After installation of PostgreSQL under MINGW?
Usually, after:
make install
I can run an application, but PostgreSQL's installation does not seem to
have exported the paths for me.
Is it normally necessary to manually export the paths:
/usr/local/pgsql/bin
/usr/local/pgsql/lib
After installation of PostgreSQL under MINGW?
Usually, after:
make install
I can run an application, but PostgreSQL's installation does not seem to
have exported the paths for me.
--
On Wed, 2004-09-01 at 11:34, David Parker wrote:
> I am not currently working on z/OS, and don't have access to a z/OS
> environment, but I did a little work with getting OpenLDAP ported to
> z/OS at my previous company. I assume you mean Unix System Services
> (USS) under z/OS, rather than zLinux.
It seems that there are two identically named include files:
U:\postgresql-8.0.0beta2\src\interfaces\libpq>type pg_config_paths.h
#define SYSCONFDIR ""
U:\postgresql-8.0.0beta2\src\port>type pg_config_paths.h
#define PGBINDIR "/usr/local/pgsql/bin"
#define PGSHAREDIR "/usr/local/pgsql/share"
#def
I see that these symbols are found in src\port\pg_config_paths.h
I will try to find out why that file did not get included in path.c
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dann Corbit
> Sent: Wednesday, September 01, 2004 1:26 PM
> To: Pos
Probably an error on my part. I assume that there is some configuration
script that is supposed to define the following:
INCLUDEDIR
INCLUDEDIRSERVER
LIBDIR
LOCALEDIR
PGBINDIR
PGSHAREDIR
PKGINCLUDEDIR
PKGLIBDIR
Because of this:
make
Title: Message
So I thought I would take this opportunity to
congratulate the PostgreSQL team on a fantastic job with the PostgreSQL 8.0
beta.
Amazing in its scope. It's almost a
miracle.
Title: Message
Include the file:
src\backend\port\dynloader\win32.h
in
dynloader.c
Possibly with #ifdef for OS type, if that is needed.
-Original Message-From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Dann CorbitSent: Wednesday, September 01, 2004
1:10 P
Title: Message
Include prototypes
at the top of the file:
extern
char *dlerror(void);extern
int dlclose(void *);extern
void *dlsym(void *, const char *);extern
void *dlopen(const char *, int);
Title: Message
Known issue, and the patch is in cvs already. You need to
change include/port/win32.h, it has a spelling mistake for
stat.
There was talk of re-wrapping beta-2 with this included,
but I guess it wasn't done. That leaves beta-2 unusable on win32 without
manually applying that
Dann Corbit wrote:
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 01, 2004 12:31 PM
To: Dann Corbit
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Also cannot build the postgresql
server under Mingw using 8.0 beta 2
Dann Corbit wrote:
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 01, 2004 12:31 PM
> To: Dann Corbit
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Also cannot build the postgresql
> server under Mingw using 8.0 beta 2
>
> Dann Corbit wrote:
>
>
Dann Corbit wrote:
Adding this to the c.h file solved most of the problems for the libpq DLL:
#if defined(HAVE_STRINGS_H) && !defined(_MSC_VER)
#include
#endif
...
#if defined(WIN32) && defined(_MSC_VER)
#include
#define snprintf _snprintf
#endif
Since I ran configure for MINGW (which has stri
Title: Message
Adding
this to the c.h file solved most of the problems for the libpq
DLL:
#if
defined(HAVE_STRINGS_H) && !defined(_MSC_VER)#include
#endif...
#if defined(WIN32) &&
defined(_MSC_VER)#include #define snprintf
_snprintf#endif
Since
I ran configure for MINGW (which has strin
On Wed, 2004-09-01 at 13:50, Jan Wieck wrote:
> On 9/1/2004 1:51 PM, Serguei A. Mokhov wrote:
>
> > Date: Tue, 31 Aug 2004 23:35:18 -0400
> >
> > On 8/31/2004 9:38 PM, Andrew Rawnsley wrote:
> >
> >> On Aug 31, 2004, at 6:23 PM, Marc G. Fournier wrote:
> >>
> >>> On Tue, 31 Aug 2004, Josh Berkus
Title: Message
Also
cannot build the PostgreSQL server under Mingw
dlltool --dllname postgres.exe --output-exp postgres.exp --def
postgres.defgcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -L../../src/port -o postgres.exe
-Wl,--base-file,postgres.base post
On 9/1/2004 1:51 PM, Serguei A. Mokhov wrote:
Date: Tue, 31 Aug 2004 23:35:18 -0400
On 8/31/2004 9:38 PM, Andrew Rawnsley wrote:
On Aug 31, 2004, at 6:23 PM, Marc G. Fournier wrote:
On Tue, 31 Aug 2004, Josh Berkus wrote:
Andrew,
If I were loony enough to want to make an attempt at a version
update
Date: Tue, 31 Aug 2004 23:35:18 -0400
On 8/31/2004 9:38 PM, Andrew Rawnsley wrote:
> On Aug 31, 2004, at 6:23 PM, Marc G. Fournier wrote:
>
>> On Tue, 31 Aug 2004, Josh Berkus wrote:
>>
>>> Andrew,
>>>
If I were loony enough to want to make an attempt at a version
updater
(i.e. mig
On Wed, 1 Sep 2004, Richard Huxton wrote:
> Date: Wed, 01 Sep 2004 09:45:56 +0100
>
> Serguei A. Mokhov wrote:
> > Hello,
> >
> > Just poking around to see if anyone is working on resurrecting the concept
> > of pg_upgrade after all these years?
>
> You probably want to join the (very recent) thre
I am not currently working on z/OS, and don't have access to a z/OS
environment, but I did a little work with getting OpenLDAP ported to
z/OS at my previous company. I assume you mean Unix System Services
(USS) under z/OS, rather than zLinux. Since zLinux is essentially Suse
ported to the Z archite
On Sep 1, 2004, at 12:19 PM, Josh Berkus wrote:
From my perspective, anyone who is running a 100GB,
can't-be-down-for-a-day
database and does not have more than 100GB free and/or a hot swap
server has
some *serious* priority problems.
Well, 100GB maybe excessive for this example. but I'm sure the
On Wed, Sep 01, 2004 at 09:47:02AM -0400, Jeff wrote:
>
> On Aug 31, 2004, at 6:30 PM, Josh Berkus wrote:
>
> >Huh? You can replicate onto the same server. Kicks your
> >performance in the teeth but it works fine. Heck, I did it on my
> >laptop as a demo.
>
> Doesn't work If you have say, a 1
Folks,
> Doesn't work If you have say, a 100GB db and only 50GB free space.
> Not nearly enough to duplicate. But plenty of breathing room for normal
> operation.
>From my perspective, anyone who is running a 100GB, can't-be-down-for-a-day
database and does not have more than 100GB free and/or a
Folks,
At Linuxworld Expo/SF, I got a chance to talk a bit with one Andrew
Schmidt of IBM about the possibility of porting PostgreSQL to z/OS.
Here's what he asked about. Any z/OS developers in the house who can
address it?
Cheers,
D
- Forwarded message from Andrew Schmidt <[EMAIL PROTECTE
On K, 2004-09-01 at 01:30, Josh Berkus wrote:
> Marc,
>
> > Slony is not an upgrade utility, and falls short in one big case ..
> > literally .. a very large database with limited cash resources to
> > duplicate it (as far as hardware is concerned). In small shops, or those
> > with 'free budget'
On Wed, 1 Sep 2004, Jan Wieck wrote:
On 9/1/2004 10:29 AM, Joe Conway wrote:
Jeff wrote:
On Aug 31, 2004, at 6:30 PM, Josh Berkus wrote:
Huh?You can replicate onto the same server.Kicks your performance
in
the teeth but it works fine. Heck, I did it on my laptop as a demo.
Doesn't work I
I think I see the real issue behind the recent argument about the
datatype of the timezone variable. I don't think the datatype matters,
but the name certainly does. In pgtz.c we have
#if defined(HAVE_STRUCT_TM_TM_ZONE)
return tm->tm_gmtoff;
#elif defined(HAVE_INT_TIMEZONE)
#ifdef HAVE_U
Thanks for the reply,
Been reading hackers of Aug 2004 and found the threads. It's a common habit to
create two lines on the configuration files, in order to maintain the copy of the
default conf file. I guess this should be the worst scenery for a freshly incoming DBA
trying to put things in
On Mon, Aug 30, 2004 at 02:19:49PM -0400, Tom Lane wrote:
> This particular issue is just a simple oversight in xact_redo, and it's
> easily fixed: make sure nextXID gets advanced past all of the committed
> or aborted subXIDs too.
Certainly this is the right thing to do.
> [...] but I think the
On 9/1/2004 10:29 AM, Joe Conway wrote:
Jeff wrote:
On Aug 31, 2004, at 6:30 PM, Josh Berkus wrote:
Huh?You can replicate onto the same server.Kicks your
performance in
the teeth but it works fine. Heck, I did it on my laptop as a demo.
Doesn't work If you have say, a 100GB db and only 5
Jeff wrote:
On Aug 31, 2004, at 6:30 PM, Josh Berkus wrote:
Huh?You can replicate onto the same server.Kicks your
performance in
the teeth but it works fine. Heck, I did it on my laptop as a demo.
Doesn't work If you have say, a 100GB db and only 50GB free space.
Not nearly enough to dup
Greg Stark <[EMAIL PROTECTED]> writes:
> One of the things I think has to change with postgres is the default
> selectivity assumptions for inequality operators. They're way to high
> currently.
Maybe so, but 5% is grossly too low. We'd just be throwing ourselves
into a different set of badly mis
On Aug 31, 2004, at 6:30 PM, Josh Berkus wrote:
Huh?You can replicate onto the same server.Kicks your
performance in
the teeth but it works fine. Heck, I did it on my laptop as a demo.
Doesn't work If you have say, a 100GB db and only 50GB free space.
Not nearly enough to duplicate. But
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> This is important for point-in-time recovery also, since there would always
> be clog entries ahead of the recovery target.
Not really, because they'd not have gotten applied. AFAICS only crash
recovery really has an issue here.
At 10:51 PM 1/09/2004, Philip Warner wrote:
Won't be 'till beta2.
...sorry, beta3
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@)
At 08:53 PM 1/09/2004, Christopher Kings-Lynne wrote:
Did you deal with the pg_get_indexdef problem where it automaticlaly adds
the tablespace in index definitions?
No; the SET stuff is not there, and Tom said he'd deal with the backend
side of things when he gets a chance. Won't be 'till beta2.
G u i d o B a r o s i o wrote:
Conclusion:
If you comment a line on the conf file, and reload it, will remain in
the last state. (either wast true or false, while I expected a
default)
Yes, that's correct. No, you're not the only one to have been caught out
by this.
--
Richard Huxton
Archonet
Again me,
To make it easier.
Situation A:
log_something = true
Situation B:
# log_something =
Situation C:
log_something = false
After the pg_ctl reload:
Situation B = Situation A
Situation C <> (Situation A || Situation B)
Is this the expected behavior?
Conclusion:
If you comment a
Sounds good; I've implemented using SET in pg_dump/restore, just waiting
for the command to work. If it's not there by beta3, I'll just use ALTER
commands.
Did you deal with the pg_get_indexdef problem where it automaticlaly
adds the tablespace in index definitions?
Chris
--
On Aug 31, 2004, at 11:35 PM, Jan Wieck wrote:
On 8/31/2004 9:38 PM, Andrew Rawnsley wrote:
On Aug 31, 2004, at 6:23 PM, Marc G. Fournier wrote:
On Tue, 31 Aug 2004, Josh Berkus wrote:
Andrew,
If I were loony enough to want to make an attempt at a version
updater
(i.e. migrate a
7.4 database to 8
At 06:31 PM 1/09/2004, Fabien COELHO wrote:
I've noticed that the item does not seem to appear in Bruce's list, thus
I'm afraid it might be lost for 8.0 where I think it belongs... hence this
little reminder.
Sounds good; I've implemented using SET in pg_dump/restore, just waiting
for the command
Serguei A. Mokhov wrote:
Hello,
Just poking around to see if anyone is working on resurrecting the concept
of pg_upgrade after all these years?
You probably want to join the (very recent) thread subject = "version
upgrade" started by Andrew Rawnsley.
--
Richard Huxton
Archonet Ltd
--
Dear hackers,
> I'm happy to do the pg_dump changes, assuming Tom gets the SET stuff sorted
> out.
ISTM that the tablespace handling or ignoring in pg_dump/pg_restore is
still an open issue in current CVS head... waiting for a proper
implementation after the brain-storming on what seemed to be
> Tom Lane wrote
> This is already true at the page level: when advancing into a new page
> we zero it instead of reading anything from disk. I am thinking of
> adding code to StartupCLOG to zero the remaining portion of the
> "current" page too.
>
> Thoughts?
>
That sounds like the right thing
61 matches
Mail list logo
