Hi,
I have strange stability problems.
I can't access a table (the table is different each time I get the
problem, it could be a system table (pg_am), or a user defined one):
Can't select * the whole table but can select * limit x offset y, so
it appears that only a tuple is in bad status. I can't
Nicolas VERGER [EMAIL PROTECTED] writes:
2002-11-05 14:46:44 [5768] FATAL 2: failed to add item with len = 191
to page 150 (free space 4294967096, nusd 0, noff 0)
template1=# select version();
PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.96
Hmm. This looks a lot like the bug
Another tiny question:
Is there a way to set more than one shared regions?
Thanks and regards
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Luis Alberto Amigo Navarro [EMAIL PROTECTED] writes:
Is there a way to set more than one shared regions?
No, there isn't.
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 4: Don't 'kill -9'
I supposed it, but I've not seen 7.3.
A small patch for low performance on NUMA arquitectures could be the chance
of using more than one shared region.
Several months away there was a brief talk about low performance on IRIX, it
was not real, it's low performance on Origin servers, they use ccNUMA
[EMAIL PROTECTED] (Marc G. Fournier) writes:
On Tue, 5 Nov 2002, Thomas Lockhart wrote:
...
to pull in those changes that were made to the REL7_3_STABLE branch ...
Right.
But, if I did:
cvs checkout -rREL7_3_STABLE pgsql
What would I use as BRANCHNAME in the -j to
Peter updated the man.tar.gz file for me, and I got Bruce to tag it as
beta5 just so that there was no confusion ...
Sizes all look right, in comparison to past betas ... can a few ppl
download and take a peak at this one ... if all goes well, this should be
the last beta, with RC1 out next week
Hannu Krosing [EMAIL PROTECTED] wrote:
Exactly. When user send the COMMIT command to the master server, the
master.talks to the slaves to process precommit-vote-commit using the
2PC. The 2PC cycle is hidden from user application. User application
just talks the normal FE/BE protocol.
Hi everyone,
Thanks to Adrian Maier [EMAIL PROTECTED], the Romanian translation of the
PostgreSQL Advocacy and Marketing site is now completed and ready for
public use:
http://advocacy.postgresql.org/?lang=ro
:-)
Dutch is presently being worked upon, and will hopefully be ready soon.
:)
Hannu Krosing wrote:
Bruce Momjian kirjutas K, 06.11.2002 kell 08:19:
I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
Win32, and SRA's port to Win32, and permission to generate a merged
patch that can be applied to 7.4.
Great!
Now that 7.3 is almost complete, I
Bruce Momjian wrote:
Hannu Krosing wrote:
Bruce Momjian kirjutas K, 06.11.2002 kell 08:19:
I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
Win32, and SRA's port to Win32, and permission to generate a merged
patch that can be applied to 7.4.
Great!
Now
Jan Wieck wrote:
Actually, I will be doing all the coding on BSD/OS. I am more merging
patches than actual coding, though. This will guarantee that the
patches will not affect the Unix platforms. I will need help from
others to check the various Win32 compilers.
I was wondering about
Bruce Momjian wrote:
Jan Wieck wrote:
Actually, I will be doing all the coding on BSD/OS. I am more merging
patches than actual coding, though. This will guarantee that the
patches will not affect the Unix platforms. I will need help from
others to check the various Win32 compilers.
I was
Joe Conway wrote:
Bruce Momjian wrote:
Jan Wieck wrote:
Actually, I will be doing all the coding on BSD/OS. I am more merging
patches than actual coding, though. This will guarantee that the
patches will not affect the Unix platforms. I will need help from
others to check the various
Jan Wieck writes:
To Hannu: the Windows port we did here depends on MS VC++ features like
the ability to specify in the project to substitute header files. I
don't know much about MingW and if you can do things like that with it.
Before long someone will port the Windows port to MinGW, so we
Peter Eisentraut wrote:
Jan Wieck writes:
To Hannu: the Windows port we did here depends on MS VC++ features like
the ability to specify in the project to substitute header files. I
don't know much about MingW and if you can do things like that with it.
Before long someone will port
-Original Message-
From: Joe Conway [mailto:mail;joeconway.com]
Sent: 06 November 2002 16:16
To: Bruce Momjian
Cc: Jan Wieck; Hannu Krosing; PostgreSQL-development; Tatsuo Ishii
Subject: Re: [HACKERS] Win32 port
Bruce, I can compile on VC++ (VS .Net) for you. Let me know
Here is a list of patch areas that I will address with the Win32 port:
fork/exec
loop rename test
handle \r in COPY
copydir for cp -r
backslash tests
rmdir not recursive for rm -r
shared memory could map to new address in exec child
Bruce Momjian wrote:
Peter Eisentraut wrote:
Jan Wieck writes:
To Hannu: the Windows port we did here depends on MS VC++ features like
the ability to specify in the project to substitute header files. I
don't know much about MingW and if you can do things like that with it.
Bruce Momjian wrote:
Here is a list of patch areas that I will address with the Win32 port:
fork/exec
loop rename test
handle \r in COPY
copydir for cp -r
backslash tests
rmdir not recursive for rm -r
shared memory could map to
Jan Wieck wrote:
Bruce Momjian wrote:
Here is a list of patch areas that I will address with the Win32 port:
fork/exec
loop rename test
handle \r in COPY
copydir for cp -r
backslash tests
rmdir not recursive for rm -r
Jan Wieck wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Jan Wieck writes:
To Hannu: the Windows port we did here depends on MS VC++ features like
the ability to specify in the project to substitute header files. I
don't know much about MingW and if you can do things
I would recommend checking your memory (look for memtest86 online
somewhere. Good tool.) Anytime a machine seems to act flakely there's a
better than even chance it has a bad bit of memory in it.
On Wed, 6 Nov 2002, Nicolas VERGER wrote:
Hi,
I have strange stability problems.
I can't
make[2]: Entering directory
`/data/aja96/postgresql-7.3b3/src/backend/utils/mb/conversion_procs'
make[3]: Entering directory
`/data/aja96/postgresql-7.3b3/src/backend/utils/mb/conversion_procs/
ascii_and_mic'
gcc -shared -h libascii_and_mic.so.0 ascii_and_mic.o
-L../../../../../../src/port
Tom Lane writes:
I'm guessing that what we need to do is -D_GNU_SOURCE somewhere in the
Makefiles; the $64 question is exactly where (can we restrict it to
src/pl/plperl?) and what conditions should cause the Makefiles to add
it? Do we want a configure test?
The simplest choice would be to
Hello Bruce,
Wednesday, November 6, 2002, 3:19:35 AM, you wrote:
BM I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
BM Win32, and SRA's port to Win32, and permission to generate a merged
BM patch that can be applied to 7.4.
BM Now that 7.3 is almost complete, I am going to
Steve Howe wrote:
Hello Bruce,
Wednesday, November 6, 2002, 3:19:35 AM, you wrote:
BM I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
BM Win32, and SRA's port to Win32, and permission to generate a merged
BM patch that can be applied to 7.4.
BM Now that 7.3 is
I saw this when compiling 7.3b4 as well and also with 7.3b5
cd contrib
make
...
make[1]: Leaving directory
`/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/rtree_gist'
make[1]: Entering directory
`/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg'
sed
Hello Bruce,
Wednesday, November 6, 2002, 8:33:32 PM, you wrote:
BM Steve Howe wrote:
Hello Bruce,
Wednesday, November 6, 2002, 3:19:35 AM, you wrote:
BM I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
BM Win32, and SRA's port to Win32, and permission to generate a
Wow, that is strange. I have bison 1.75 here and it compiles fine.
What version of bison do you have?
bison --version
---
Laurette Cisneros wrote:
I saw this when compiling 7.3b4 as well and also with 7.3b5
pgman wrote:
I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
Win32, and SRA's port to Win32, and permission to generate a merged
patch that can be applied to 7.4.
Now that 7.3 is almost complete, I am going to start work on that. I
will post patches that deal with
bison --version
GNU Bison version 1.28
Should I update it?
This just started with 7.3b4.
Thanks,
L.
On Wed, 6 Nov 2002, Bruce Momjian wrote:
Wow, that is strange. I have bison 1.75 here and it compiles fine.
What version of bison do you have?
bison --version
I think bison 1.75 will fix it. I am just not sure why earlier releases
fail that way.
---
Laurette Cisneros wrote:
bison --version
GNU Bison version 1.28
Should I update it?
This just started with 7.3b4.
Oh, I see it now, I think there was a change on November 1st to rule
generation, but I can't see how that would cause your problem.
If you 'patch -R' the attached patch, does it fix the problem?
---
Bruce Momjian wrote:
On Wed, Nov 06, 2002 at 08:20:16PM -0500, Bruce Momjian wrote:
Let me map out the calendar. I think we are very close on the
point-in-time recovery patch. I am hoping to get that in during
November, and I _was_ hoping for the Win32 port too, so we could have
another two months of
Alvaro Herrera wrote:
On Wed, Nov 06, 2002 at 08:20:16PM -0500, Bruce Momjian wrote:
Let me map out the calendar. I think we are very close on the
point-in-time recovery patch. I am hoping to get that in during
November, and I _was_ hoping for the Win32 port too, so we could have
I am including a set of 4 small patches that enable PostgreSQL 7.3b3 to build
successfully on OpenUnix 8.0. These same patches should also work for UnixWare
7.x. I will confirm that tomorrow (Nov 7, 2002).
Here is an explanation of the patches:
1. An update of the FAQ_SCO file.
2. This patch
I will be applying outstanding 7.4 patches on Friday:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
If anyone wants those rejected/modified, please let me know.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
Hi,
Can I still send in translation patches so that they
get into 7.4 or is it too late already? If it's not
late, what would be the 'deadline' then?
Thanks,
--
Serguei A. Mokhov
---(end of broadcast)---
TIP 6: Have you searched our list
Bruce Momjian [EMAIL PROTECTED] writes:
I have talked to Jan, and PeerDirect wants to submit a complete working
Win32 patch, rather than the piece-by-piece merged patch I was working
on.
Is there a reason you're doing the actual merging with CVS? ISTM it
might be more straight-forward to just
News to me ...
On Wed, 6 Nov 2002, Bruce Momjian wrote:
Are we still on schedule for RC1 on Friday?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+
Neil Conway wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have talked to Jan, and PeerDirect wants to submit a complete working
Win32 patch, rather than the piece-by-piece merged patch I was working
on.
Is there a reason you're doing the actual merging with CVS? ISTM it
might be more
Marc G. Fournier wrote:
News to me ...
On Wed, 6 Nov 2002, Bruce Momjian wrote:
Are we still on schedule for RC1 on Friday?
I am asking. We almost got to RC1 last Friday, so I figured we could do
RC1 this Friday. The changes between betas is minimal.
--
Bruce Momjian
successfully compiled on OpenUnix 8
and it passed all the regression tests.
Content-Description: ou8.patch.20021106
[ Attachment, skipping... ]
| Billy G. Allie| Domain: [EMAIL PROTECTED]
| /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED]
|-/-|- | Dearborn
Hello all,
Just wondering if the datetime type was dropped on purpose from
PostgreSQL 7.3 ?
This is not an issue of course, I'll be using timestamp, but it's
weird having that dropped.
---
-- On PostgreSQL 7.2:
---
howe=# select version();
Bruce Momjian wrote:
snip
What do others want, a regular 4-6 month cycle or a shorter one?
Whilst having a regular 4-6 month cycle (er... when was the last time
THAT happened?) is alright, we should get the *Windows* native version
out to the world ASAP. This (and secondly PITR) will greatly
Steve Howe [EMAIL PROTECTED] writes:
Just wondering if the datetime type was dropped on purpose from
PostgreSQL 7.3 ?
Yes. Ad-hoc name translations in the parser create bogosities with
respect to schemas --- I forget the details, but it was either drop
datetime or make it a reserved keyword.
Hello Tom,
Thursday, November 7, 2002, 1:17:00 AM, you wrote:
TL Steve Howe [EMAIL PROTECTED] writes:
Just wondering if the datetime type was dropped on purpose from
PostgreSQL 7.3 ?
TL Yes. Ad-hoc name translations in the parser create bogosities with
TL respect to schemas --- I forget the
Laurette Cisneros [EMAIL PROTECTED] writes:
bison --version
GNU Bison version 1.28
Should I update it?
Yes.
It's interesting that bison 1.28's output is sufficiently different to
cause a problem, but we are not going to worry about supporting use of
old bisons.
Laurette Cisneros [EMAIL PROTECTED] writes:
bison --version
GNU Bison version 1.28
Should I update it?
Yes.
It's interesting that bison 1.28's output is sufficiently different to
cause a problem, but we are not going to worry about supporting use of
old bisons.
Do I have to install
Justin Clift [EMAIL PROTECTED] writes:
Whilst having a regular 4-6 month cycle (er... when was the last time
THAT happened?) is alright, we should get the *Windows* native version
out to the world ASAP.
We don't have a Windows native version, and it sounds like it'll be
awhile before we have
Bruce Momjian [EMAIL PROTECTED] writes:
I am fine with this because it only touches unixware-specific stuff,
except the change to Tom's inline function:
[static] inline Datum
myFunctionCall2(FmgrInfo *flinfo, Datum arg1, Datum arg2)
Tom will have to comment on that.
That change would
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Do I have to install the CVS version of Bison to get the new compile to
work?
No, you can use their current release, 1.75. (Reportedly 1.50 works
too, but I never tried it.)
regards, tom lane
Ross J. Reedstrom [EMAIL PROTECTED] wrote:
Because the postgres backend must detect a type of incomming connection
(from the client app or the master).
If it is comming from the client, the backend relays the queries to the
slaves (act as the master).
But if it is comming from
Tom Lane wrote:
Laurette Cisneros [EMAIL PROTECTED] writes:
bison --version
GNU Bison version 1.28
Should I update it?
Yes.
It's interesting that bison 1.28's output is sufficiently different to
cause a problem, but we are not going to worry about supporting use of
old bisons.
Bruce Momjian [EMAIL PROTECTED] writes:
I will be applying outstanding 7.4 patches on Friday:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
If anyone wants those rejected/modified, please let me know.
array upper/lower bound: missing doc updates, otherwise seems okay.
\pset pager
Hello Bruce,
Thursday, November 7, 2002, 12:56:57 AM, you wrote:
BM I have thrown out the idea and some felt that if we could get PITR and
BM Win32, that would be enough for a release, even if we could get it done
BM in a month or two.
BM However, I see your point that releasing too often
We already have success messages from Olivier Prenant for 7.3B4 on 8.0.0,
and me for 7.1.3.
I don't believe your changes are necessary.
--On Wednesday, November 06, 2002 22:57:26 -0500 Billy G. Allie
[EMAIL PROTECTED] wrote:
I am including a set of 4 small patches that enable PostgreSQL
Bruce Momjian [EMAIL PROTECTED] writes:
Just to clarify, do the tarballs for /contrib/seg have the pre-processed
bison output, or are people required to have more current bisons to
compile the code?
AFAIK we do not provide prebuilt bison or flex output for any of the
contrib modules.
Tom Lane [EMAIL PROTECTED] writes:
CREATE SEQUENCE syntax changes: did we decide whether SQL99's notion of
a sequence is close enough to ours that migrating to their syntax would
be a good idea, and not just a source of confusion? I seem to recall
some doubts being voiced about this (by
I said:
It's interesting that bison 1.28's output is sufficiently different to
cause a problem, but we are not going to worry about supporting use of
old bisons.
Well, it turned out to be reasonably easy to fix this, so I did. It
seems that bison 1.28 generates a .h file that cannot be
Billy G. Allie [EMAIL PROTECTED] writes:
Here is the error messages generated during the compile:
cc -K pentium_pro,host,inline,loop_unroll -I../../../../src/include
-I/usr/local/include -I/usr/local/ssl/include -c -o tuplesort.o tuplesort.c
UX:acomp: ERROR: tuplesort.c, line 1854: inline
On Wed, 6 Nov 2002, Achilleus Mantzios wrote:
Hi i think a hit a major problem on 7.2.1.
I run 3 systems with postgresql 7.2.1.
Its a redhat 7.1 for development, a redhat 7.3 for production
and a FreeBSD 4.6.1RC2 for testing.
After long runs (with periodic (daily) vacuum analyze's)
i
Tom Lane wrote:
Billy G. Allie [EMAIL PROTECTED] writes:
Here is the error messages generated during the compile:
cc -K pentium_pro,host,inline,loop_unroll -I../../../../src/include
-I/usr/local/include -I/usr/local/ssl/include -c -o tuplesort.o tuplesort.
c
UX:acomp: ERROR:
...
In the long run, seems like it would be a good idea for type TIME
WITHOUT TIME ZONE's input converter to accept and ignore a timezone
field, just as type TIMESTAMP WITHOUT TIME ZONE does:
...
Thomas, what do you think --- was this behavior deliberate or an
oversight?
The behavior was
Larry Rosenman [EMAIL PROTECTED] writes:
I don't believe your changes are necessary.
The static-inline change was obsoleted by a recent fix, per discussion.
But the rpath changes seem possibly useful (or maybe my thoughts are
just colored by the fact that I'm currently trying to persuade OpenSSL
66 matches
Mail list logo
