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. Probably the single most frequently asked question on -performance
and -general are people asking why Postgres isn't using their index. And while
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 to do.
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
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
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
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
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
Again me,
To make it easier.
Situation A:
log_something = true
Situation B:
# log_something = anything
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
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
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.
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) | /(@)
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.
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.
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
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
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
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
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
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
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
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', Slony
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
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
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 100GB db
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
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
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) thread subject =
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. migrate a
7.4 database to
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
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
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 wrote:
Andrew,
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
strings.h#endif...
#if defined(WIN32)
defined(_MSC_VER)#include winsock2.h#define snprintf
_snprintf#endif
Since
I ran configure for MINGW
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 strings.h
#endif
...
#if defined(WIN32) defined(_MSC_VER)
#include winsock2.h
#define snprintf _snprintf
#endif
Since I ran configure for MINGW
-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:
Adding
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:
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
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
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
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.
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:
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:
It seems that there are two identically named include files:
U:\postgresql-8.0.0beta2\src\interfaces\libpqtype pg_config_paths.h
#define SYSCONFDIR
U:\postgresql-8.0.0beta2\src\porttype pg_config_paths.h
#define PGBINDIR /usr/local/pgsql/bin
#define PGSHAREDIR /usr/local/pgsql/share
#define
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.
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.
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.
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
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
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 program
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 Unix
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:
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
-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
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
do
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 perl
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 the
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
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,
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 for OS
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, |
|
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
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
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
62 matches
Mail list logo