Using pg_control to get checkpoint position speed up things but
to handle possible pg_control corruption we obviously should
implement reading existent log segments (from the last one -
newest - to oldest) to get last checkpoint.
I think this would be *very* important :-)
Andreas
Quoting Bruce Momjian [EMAIL PROTECTED]:
I have trickled the emails as I reviewed them, asking for comments. It
was not one big email.
I haven't seen them either, although my Inbox is big again, and I'm filtering
out mails by their subject line, so it's possible I've missed them.
I'm
Bruce Momjian [EMAIL PROTECTED] writes:
Here are my open 7.1 items. Thanks for shrinking the list so far.
SELECT cash_out(1) crashes all backends
This isn't a "must fix for 7.1", any more than it was for 7.0, 6.5,
or any other release back to the beginning of time. It's always been
possible
On Thu, Jan 25, 2001 at 12:42:45AM +0100, Peter Eisentraut wrote:
Frank Joerdens writes:
[randomly varying set of regression tests fail]
Running the tests on my Linux box gives no failed tests. Must I assume
that those failed tests indicate some issue that is is detrimental to
the
El Mi 24 Ene 2001 17:56, Ned Lilly escribi:
Adam, FYI, according to Rasmus Lerdorf, your patches have been
committed. From the changelog:
2001-01-18 Derick Rethans [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
* ext/pgsql/pgsql.c
ext/pgsql/php_pgsql.h:
-
My email address has been changed. From now on, please write to
[EMAIL PROTECTED] The "tip" user at the same host no
longer exists. Sorry for the inconvenience if you tried to send a message
to the "tip" user this week.
Have a nice day, :^)
Zoltan
--
Kov\'acs, Zolt\'an
Worked fine for me...
% uname -a
SunOS lancelot 5.7 Generic_106541-14 sun4m sparc SUNW,SPARCstation-4
% ls -l
-rw-r--r-- 1 bpalmer staff32860160 Jan 23 16:45
postgresql-snapshot.tar
...
...
...
transactions ... ok
random ... failed (ignored)
yup :-) Maybe this could even be raised to the SQL level,
so applications could use this ? I have not seen this elsewhere,
but why actually not ?
Yes please :-) if someone is to code this quicker than me (I suppose
so, since I have other projects to deal with concurrently).
--
Tout n'y
When Postgresql 6.5 came out it, it was VERY MUCH better ( many many
thanks
to the developers and all involved). And I'm waiting for a solid 7.1 to
fix
that 8KB issue.
Technically..
= BLCKSZ (can be up to 32k)
I've been using PostgreSQL with a 32k BLCKSZ since 7.0 (on a productions
server)
Bruce Momjian writes:
FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation"
You're certainly not going to want to fix this now after having stared at
it for a year? It's not trivial.
Usernames limited in length
Yeah, they are. ;-)
If this is referring to pg_passwd, I just
Mark,
we prepared new version of contrib-intarray -
index support for 1-D integer arrays using GiST.
Changes:
- Improved regression test
- Current implementation provides index support for one-dimensional
array of int4's - gist__int_ops, suitable for small and medium size
of arrays,
Mikheev, Vadim writes:
Yes, there should be permission checking - I'll add it later (in 7.1)
if no one else.
Should be simple enough. Is this okay:
Index: utility.c
===
RCS file:
Bruce Momjian writes:
I have added all possible config options to postgresql.conf.sample.
It was actually fully intentional that there was *no* list of all possible
config options in the sample file, because
1) Who's going to maintain this?
2) People should read the documentation before
It has been requested that I ship prebuilt contrib items in the 7.1
RPMset. Currently, the source code of the whole contrib tree is being
shipped in the main RPM as documentation, but only autoinc and refint
are being prebuilt (as part of the -test subpackage).
I have had three different types
On Thu, Jan 25, 2001 at 05:12:02PM +0100, Peter Eisentraut wrote:
Frank Joerdens writes:
I have experienced before that Unix sockets will cause random connection
abortions on Solaris [ . . . ]
Isn't that _really_ bad? Random connection abortions when going over
Unix sockets?? My
On Thu, Jan 25, 2001 at 05:12:02PM +0100, Peter Eisentraut wrote:
Frank Joerdens writes:
I have experienced before that Unix sockets will cause random connection
abortions on Solaris [ . . . ]
Isn't that _really_ bad? Random connection abortions when going over
Unix sockets?? My
Frank Joerdens writes:
That's bad, for sure. Maybe you can check for odd conditions surrounding
the /tmp directory, like is it on NFS, permission problems, mount options.
I don't have neither root nor physical access to this machine, hence my
options are kinda limited.
Entering 'mount'
At 1/24/2001 10:19 AM, Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
A patch to gram.y in src/backend/parser
Provides for the SQL99 expected behavior of
select * from foo where fo_num between 1 and 5
yields the same result as
select * from foo where fo_num
Could we add a flag to remove the postgres specific information from a
pg_dump?
--
UPDATE "pg_class" SET "reltriggers" = 0 WHERE "relname" ~*
'market_type';
BEGIN TRANSACTION;
CREATE TEMP TABLE "tr" ("tmp_relname" name, "tmp_reltriggers"
smallint);
INSERT INTO "tr" SELECT C."relname",
Now that pg_dump pg_restore can handle large objects, the only need
for pg_dumplo is for migrating large objects from prior versions. I
personally cannot see it being used on a day to day basis, but I'm
looking at it from a narrow perspective. If it is a separate package,
it can easily be
On Thu, Jan 25, 2001 at 12:04:40PM -0800, Ian Lance Taylor wrote:
[ . . . ]
for the /tmp directory, which looks distinctly odd to me. What kind of
device is swap (I know what swap is normally but I didn't know you could
mount stuff there . . . )??
That is a tmpfs file system which uses
I've got "backend closed" errors --- they seem to be indeterministic.
I am using 7.0.2 but I tried this with 7.1beta3 as well and the error
was similar (but not completely same).
I wrote a char* - char* conversion function. Now I would use textout()
and textin() to make it possible using my
On Thu, Jan 25, 2001 at 09:47:16PM +0100, Frank Joerdens wrote:
On Thu, Jan 25, 2001 at 12:04:40PM -0800, Ian Lance Taylor wrote:
[ . . . ]
for the /tmp directory, which looks distinctly odd to me. What kind of
device is swap (I know what swap is normally but I didn't know you could
You probably should be getting core files from this. Have you tried
recompiling with debugging and asserts on and then looking through the
core file, that might give some more information as to the details.
On Thu, 25 Jan 2001, Kovacs Zoltan wrote:
I've got "backend closed" errors --- they
I have a problem with the compilation of Postgres on Solaris with ssl
support. The error I get is this when executing make:
gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I/usr/local/include
-I/usr/local/ssl//include -I../../../src/include -c nodeTidscan.c -o
nodeTidscan.ogcc -g
Fix for pg_dump of bad system tables
Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates. Could someone please review and
commit them if they look ok? (I'm now in US and have
Randy Hall wrote:
I think the cleanest way to provide the contrib programs is to build a
postgresql-contrib with _everything_ in it. Those people who need a
specific binary will be able to get it from /usr/lib/pgsql (or wherever)
and the distiction between core and contrib programs will
On Thu, 25 Jan 2001, Lamar Owen wrote:
But, in the instance of pg_dumplo -- can I get some ideas on it? Should
it be shipped as a separate package, or in the -server subpackage, or??
..ignore it. Not needful for 7.1, but can be interesting for 7.1
(old DB users can found it directly on
Oliver Elphick wrote:
Randy Hall wrote:
I think the cleanest way to provide the contrib programs is to build a
postgresql-contrib with _everything_ in it. Those people who need a
specific binary will be able to get it from /usr/lib/pgsql (or wherever)
and the distiction between
At 14:48 24/01/01 -0500, Rod Taylor wrote:
Could we add a flag to remove the postgres specific information from a
pg_dump?
It's easy enough to do, but removing all PG-specific information is
probably undesirable since, eg, pg_dump does not dump foreign key
constraints in a standard way (it just
Frank Joerdens [EMAIL PROTECTED] writes:
I just did that and ran make check 4 times. 3 times went completely
smoothly, once I had random fail. This is the same behaviour that I saw
when running make installcheck (76 successful most of the time,
sometimes you get 75 out of 76 with random being
Peter Eisentraut wrote:
Bruce Momjian writes:
FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation"
You're certainly not going to want to fix this now after having stared at
it for a year? It's not trivial.
What does this item mean ?
Usernames limited in length
Thomas Swan [EMAIL PROTECTED] writes:
select * from foo where fo_num between 1 and 5
yields the same result as
select * from foo where fo_num between 5 and 1
This is NOT correct under either SQL92 or SQL99. Read the spec again.
After sending it... I realized that it was not correct
Sorry for my previous incomplete posting.
Peter Eisentraut wrote:
Bruce Momjian writes:
FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation"
You're certainly not going to want to fix this now after having stared at
it for a year? It's not trivial.
What does this item
Lamar Owen [EMAIL PROTECTED] writes:
I think the cleanest way to provide the contrib programs is to build a
postgresql-contrib with _everything_ in it.
This is what I do for the Debian release.
Precedent set; precedent followed. I'll be hopefully packaging the
_entire_ contrib tree :-)
Peter Eisentraut [EMAIL PROTECTED] writes:
But, in the instance of pg_dumplo -- can I get some ideas on it? Should
it be shipped as a separate package, or in the -server subpackage, or??
It shouldn't be packaged at all because it's not necessary. (pg_dump
dumps large objects.)
The reason
Peter Eisentraut [EMAIL PROTECTED] writes:
Mikheev, Vadim writes:
Yes, there should be permission checking - I'll add it later (in 7.1)
if no one else.
Should be simple enough. Is this okay:
Actually, I think a more interesting question is "should CHECKPOINT
have permission restrictions?
Just a quick patch to make the geometry test on Sparc/Linux
regression tests for Pgsql 7.1beta3 pass. This is very similr to the one I
submitted back in July for Linux/Alpha. Apparently non-x86 Linux machines
like to compute nth place float point digits like Sun/Solaris does?
Hi all,
Re-posting this to -hackers. Will PQprint() remain/disappear/be replaced
in the future?
Thx
Ed
--
ÌĤ¯Ç¤ÏÁͤòÊá¤é¤Ì
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Mikheev, Vadim writes:
Yes, there should be permission checking - I'll add it later (in 7.1)
if no one else.
Should be simple enough. Is this okay:
Actually, I think a more interesting question is "should CHECKPOINT
40 matches
Mail list logo
