andrea gelmini <[EMAIL PROTECTED]> writes:
> debian unstable, i386.
> upgrade libreadline 4.2
> postgres doesn't compile.
Seems strange. Did you re-run PG's configure after installing libreadline?
Are you sure that the include (.h) files found by configure match the
library (.a or .so) file?
Mark Butler <[EMAIL PROTECTED]> writes:
> Using the head branch, when I execute the following in psql on Redhat 6.2
> i386, the postmaster process dies gives an error message about corrupted
> shared memory:
Works for me ... when was your last update?
regards, tom lane
-
Mark Butler wrote:
>
> Using the head branch, when I execute the following in psql on Redhat 6.2
> i386, the postmaster process dies gives an error message about corrupted
> shared memory:
I just updated to REL7_1 and recompiled and the problem has gone away.
- Mark Butler
Ok, the 7.1-1 RPMset for Red Hat 6.2 has been uploaded. The Source RPM is up,
in RPM 3 format. Red Hat 7.0 RPMs are on their way. (whew). 28.8K is slow
when uploading 8MB worth of binary RPMset -- as it was when downloading the
source RPM from my 6.2 build machine, located at work and hung off
I wrote:
> ... how could we see reports like this:
> tab-complete.c:734: `filename_completion_function' undeclared (first use in this
>function)
> when the code makes a point of providing a declaration for
> filename_completion_function if configure didn't see it in the headers?
Never mind ...
> We've gotten several different reports lately of peculiar compilation
> errors and warnings involving readline in 7.1. They look like configure
> is actively doing the wrong thing --- for example, how could we see
> reports like this:
>
> tab-complete.c:734: `filename_completion_function' unde
Using the head branch, when I execute the following in psql on Redhat 6.2
i386, the postmaster process dies gives an error message about corrupted
shared memory:
--begin---
create function bug1(integer) returns numeric as '
begin
return $1;
end;'
language 'plpgsql';
select bug1(5);
---end---
We've gotten several different reports lately of peculiar compilation
errors and warnings involving readline in 7.1. They look like configure
is actively doing the wrong thing --- for example, how could we see
reports like this:
tab-complete.c:734: `filename_completion_function' undeclared (firs
I wrote:
> I think this is indisputably a bug in (some versions of) NetBSD. If I
> can seek past the end of file, read() shouldn't consider it a hard error
> to read there --- and in any case, EFAULT isn't a very reasonable error
> code to return. Since it seems not to be a widespread problem, I
On Fri, 13 Apr 2001, Peter Eisentraut wrote:
> Lamar Owen writes:
> > In the postgresql-docs subpackage, along with the SGML source.
> Why would you want to ship the source?
For those with SGML tools and viewers, who might like to build hardcopy of
their own. Frankly, it was an easy thing to d
On Sat, Apr 14, 2001 at 11:44:18AM +1000, Philip Warner allegedly wrote:
> At 01:14 14/04/01 +0200, Mathijs Brands wrote:
> ...
> >sol2:~$ pg_dump -b -Fc -f blaat.bk blaat
> >sol2:~$ pg_restore -l blaat.bk
> ...
> >;
> >; Archive created at Sat Apr 14 01:03:02 2001
> ...
>
> This all looks fine.
Lamar Owen writes:
> In the postgresql-docs subpackage, along with the SGML source.
Why would you want to ship the source?
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 5: Have you checked
Thomas Lockhart writes:
> Did we get all of the ancillary plain text documents generated?
Yes, unless you have changes for the installation instructions, the
release history, or the regression test procedure.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---
At 01:14 14/04/01 +0200, Mathijs Brands wrote:
...
>sol2:~$ pg_dump -b -Fc -f blaat.bk blaat
>sol2:~$ pg_restore -l blaat.bk
...
>;
>; Archive created at Sat Apr 14 01:03:02 2001
...
This all looks fine.
>sol2:~$ pg_dump -b -Ft -f blaat.tar blaat
>zsh: segmentation fault (core dumped) pg_dump
At 21:15 13/04/01 -0400, Bruce Momjian wrote:
>> At 17:34 13/04/01 -0400, Tom Lane wrote:
>> >
>> >A possible kluge answer is to make pg_dump's OID-ordering of views
>> >depend on the OID of the view rule rather than the view relation.
>> >I am not sure if that would break any cases that work now,
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> + ERROR: cannot read block 3 of hash_i4_index: Bad address
>>
>> "Bad address"? That seems pretty bizarre.
> This is obviously some
Thomas Lockhart wrote:
> Hi Lamar. What are the plans for RPMs? Do we have an "integrated RPM"
> which will work with Mandrake, or should I keep carrying along my
> patches to make the spec file work for now?
I haven't addressed that as yet. Is it safe to assume that -ffast-math
should be Consid
>
> Here is what we've always sent to to date ... anyone have any good ones
> to add?
>
>
> Addresses : [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
>
> At 17:34 13/04/01 -0400, Tom Lane wrote:
> >
> >A possible kluge answer is to make pg_dump's OID-ordering of views
> >depend on the OID of the view rule rather than the view relation.
> >I am not sure if that would break any cases that work now, however.
> >
>
> This seems good to me; it should
On Wed, 11 Apr 2001, Marcin Wasilewski wrote:
> hello everybody,
> Can you help me?
>
> I have POSTGRESQL 7.0.3,
> I try to create simple view by typing.
>
> create view "xx" as select "aa.yy", "bb.yy" from "yy" order by "bb.yy"
>
> the problem is that parameter order is not implemented with
> Well folks, I just fixed the CVS tags (renamed REL7_1 to REL7_1_BETA and
> moved REL7_1 to today) and packaged up the release ... this is it, any new
> fixes go into v7.1.1 ... :)
OK, I have some (small) patches for documentation, but afaicr it is not
critical.
Postscript docs should be comple
At 17:34 13/04/01 -0400, Tom Lane wrote:
>
>A possible kluge answer is to make pg_dump's OID-ordering of views
>depend on the OID of the view rule rather than the view relation.
>I am not sure if that would break any cases that work now, however.
>
This seems good to me; it should be based on the
>
> Here is what we've always sent to to date ... anyone have any good ones
> to add?
>
>
> Addresses : [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
>
>> Lamar Owen writes:
>>
>> > One quick note -- since 'R' < 'b', the RC RPM's must be forced to
>> > install with --oldpackage, as RPM does a simple strcmp of version
>> > numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
>> > --oldpackage if you have a 7.1beta RPM already installed.
Hi
I've been experimenting with 7.1rc4 for a couple of hours. I was messing with
blobs, and the new toast setup worked quite nicely. One thing I especially
liked was the fact that by having pg_dump create a dumpfile in the custom or
tar format, I could also backup all blobs in one go.
Unfortunat
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Here is what we've always sent to to date ... anyone have any good ones
> to add?
I think that this is still the moderator's address for comp.os.linux.announce:
[EMAIL PROTECTED]
--
matthew rice <[EMAIL PROTECTED]>
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
>
> > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> >
> > > Here is what we've always sent to to date ... anyone have any good ones
> > > to add?
> > >
> > >
> > > Addresses : [EMAIL PROTE
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
>
> > Here is what we've always sent to to date ... anyone have any good ones
> > to add?
> >
> >
> > Addresses : [EMAIL PROTECTED],
> > [EMAIL PROTECTED],
> > [EMAIL
On Fri, Apr 13, 2001 at 06:32:26PM -0400, Trond Eivind Glomsr?d wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
>
> > Here is what we've always sent to to date ... anyone have any good ones
> > to add?
> >
> >
> > Addresses : [EMAIL PROTECTED],
> > [EMAIL PROTECTED],
> >
Freshmeat updated, Linuxtoday bookmarked ... thanks ;)
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
>
> > On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
> >
> > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > >
> > > >
email added, thanks ...
On 13 Apr 2001, Matthew Rice wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Here is what we've always sent to to date ... anyone have any good ones
> > to add?
>
> I think that this is still the moderator's address for comp.os.linux.announce:
>
> [EMAIL
Mark Butler wrote:
> I did several tests with functions designed to sum the number 12345 a million
> times. The results are as follows (Pentium II 450, Redhat 6.2):
>
> Postgres PL/PGSQL original numeric:14.8 seconds
> Postgres PL/PGSQL modified numeric:11.0 seconds
> Postgres PL/PGSQL
On Fri, 13 Apr 2001, Bruce Momjian wrote:
> >
> > Here is what we've always sent to to date ... anyone have any good ones
> > to add?
> >
> >
> > Addresses : [EMAIL PROTECTED],
> > [EMAIL PROTECTED],
> > [EMAIL PROTECTED],
> > [EMAIL PROTECTED],
> >
Hi Lamar. What are the plans for RPMs? Do we have an "integrated RPM"
which will work with Mandrake, or should I keep carrying along my
patches to make the spec file work for now?
How are you planning on packaging the hardcopy docs? They are not yet
available, but will be Real Soon Now :(
debian unstable, i386.
upgrade libreadline 4.2
postgres doesn't compile.
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../src/interfaces/libpq -I../../../src/include -c -o tab-complete.o
tab-complete.c
tab-complete.c: In function `initialize_readline':
tab-complete.c:103:
On Wed, Apr 11, 2001 at 02:57:16AM +, Thomas Lockhart wrote:
> > Alright man, you've got me confused. Are you saying that despite the
> > existance of INT8 as a column type, and PreparedStatement.setLong(), that
> > these ought not be used? If so, there is a really big warning missing
> > fr
Hello, everybody
I have a new question to you. ;-)))
1. I wrote a database in access an I put there some Polish words like ±¶¿¼.
2. Migrate the base using PGADMIN to Postgresql.0.3 on Solaris 8.
3. What can I do to see that Polish words.
Maybe set a codepage or any standard.
I need help
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Here is what we've always sent to to date ... anyone have any good ones
> to add?
>
>
> Addresses : [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTED],
> [EMAIL PROTECTE
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> => create view testview as select relname, 'Constant'::text from pg_class;
I assume you meant SELECT DISTINCT there...
> => \d testview
>View "testview"
> Attribute | Type | Modifier
> ---+--+--
> relname | name |
>
hello everybody,
Can you help me?
I have POSTGRESQL 7.0.3,
I try to create simple view by typing.
create view "xx" as select "aa.yy", "bb.yy" from "yy" order by "bb.yy"
the problem is that parameter order is not implemented with create view.
so how can I create such simple query??
Best regards
Here is what we've always sent to to date ... anyone have any good ones
to add?
Addresses : [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED]
Well folks, I just fixed the CVS tags (renamed REL7_1 to REL7_1_BETA and
moved REL7_1 to today) and packaged up the release ... this is it, any new
fixes go into v7.1.1 ... :)
I'm preparing a formal PR/Announce, and will send that out later on this
evening, but want to give some of the mirror si
[EMAIL PROTECTED] (Nathan Myers) writes:
> On Fri, Apr 13, 2001 at 04:27:15PM -0400, Tom Lane wrote:
>> Have you thought about simply increasing NAMEDATALEN in your
>> installation? If you really are generating names that aren't unique
>> in 31 characters, that seems like the way to go ...
> We
Olivier PRENANT <[EMAIL PROTECTED]> writes:
> I have noticed that pg_dump and pg_dumpall could'nt generate correctly
> CREATE FUNCTION when function has been created using the form
> CREATE FUNCTION foo(x) RETURNS type AS '/foo.so','foo2' LANGUAGE C;
> pg_dumps "forgets" the 'foo2' part: tha
I see the problem. Your 7.0.3 dump contains several instances of this
pattern:
CREATE TABLE "users_alertable" (
"user_id" int4,
"email" character varying(100),
"first_names" character varying(100),
"last_name" character varying(100),
"password" character v
Tom Lane wrote:
> A more significant point is that you have presented no evidence to back
> up your claim that this would be materially faster than the existing
> type. I doubt that the extra pallocs are all that expensive. (I think
> it'd be far more helpful to reimplement numeric using base-1
On Fri, 13 Apr 2001, Tom Lane wrote:
> Obviously, these objections are not strong enough to keep us from
> increasing the standard value of NAMEDATALEN if it seems that many
> people are running into the limit. But AFAICT relatively few people
> have such problems, and I'm hesitant to make every
Hi all,
I've read pg_dump threads with great interest as I plan to upgrade from
703 to 71 on next monday if 71 final is out.
Although I did'nt have any of the ploblems listed in threads durin my
tests from 7.0.3 to 7.1betas and 7.1RCs.
I have noticed that pg_dump and pg_dumpall could'nt gen
Joel Burton <[EMAIL PROTECTED]> writes:
>> Have you thought about simply increasing NAMEDATALEN in your
>> installation? If you really are generating names that aren't unique
>> in 31 characters, that seems like the way to go ...
> Other than (a) it wastes a bit of space in the pg_ tables, and (
On Fri, Apr 13, 2001 at 04:27:15PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > We are thinking about working around the name length limitation
> > (encountered in migrating from other dbs) by allowing "foo.bar.baz"
> > name syntax, as a sort of rudimentary namespace mec
On Fri, 13 Apr 2001, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> >> Seems to me that if you want a bunch of CREATEs to be mutually
> >> dependent, then you wrap them all in a BEGIN/END block.
>
> > Yes, but... The second and third commands weren't supposed to be
> > related to
Tom,
> > dump), anyone interested may have them for testing.
>
> Please. Philip Warner would likely want to see them too.
I don't have his email address... but I am quite willing to send it.
Pascal.
---(end of broadcast)---
TIP 4: Don't 'kill
[EMAIL PROTECTED] (Nathan Myers) writes:
>> Seems to me that if you want a bunch of CREATEs to be mutually
>> dependent, then you wrap them all in a BEGIN/END block.
> Yes, but... The second and third commands weren't supposed to be
> related to the first at all, never mind dependent on it. Th
On Fri, Apr 13, 2001 at 02:54:47PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > Sorry, false alarm. When I got the test case, it turned out to
> > be the more familiar problem:
>
> > create table foo_..._bar1 (id1 ...);
> > [notice, "foo_..._bar1" truncated to "foo
[EMAIL PROTECTED] (Nathan Myers) writes:
> Sorry, false alarm. When I got the test case, it turned out to
> be the more familiar problem:
> create table foo_..._bar1 (id1 ...);
> [notice, "foo_..._bar1" truncated to "foo_..._bar"]
> create table foo_..._bar (id2 ...);
> [error, foo_.
> The appropriate way to do this given a LOCK TABLE option would be like
>
> BEGIN;
> LOCK TABLE foo IN ROW EXCLUSIVE MODE WITH TIMEOUT n;
> UPDATE foo SET ...;
> COMMIT;
>
> which restricts the scope of the timeout behavior to just the specific
> lock that the user is th
Pascal Scheffers <[EMAIL PROTECTED]> writes:
> Some five functions are used in views before their definitions. In the
> original (7.0) dump they were in the correct order, but rc2/4 (the only
> ones I tried) got it wrong. The original OIDs for the
> functions in the 7.1 dump are lower than those o
On Fri, Apr 13, 2001 at 01:16:43AM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > We have noticed here also that object (e.g. table) names get truncated
> > in some places and not others. If you create a table with a long name,
> > PG truncates the name and creates a tabl
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was thinking SET because UPDATE does an auto-lock.
Not to mention a ton of implicit locks acquired on various system tables
during parsing/planning. You really want auto timeout on all of those?
I sure don't.
The appropriate way to do this given a L
I was thinking SET because UPDATE does an auto-lock.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I can imagine some people wanting this. However, 7.1 has new deadlock
> > detection code, so I would you make a 7.1 version and send it over. We
> > can get it into 7.2.
>
> I object strongly
On Fri, Apr 13, 2001 at 01:25:45PM +, Thomas Lockhart wrote:
> > Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's
> > patch should be applied?
>
> I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD
> seems to insist on calling every Intel proces
Lehel Gyuro <[EMAIL PROTECTED]> writes:
> I've tried to write a plpgsql function, and noticed the following
> problem : (7.1RC2 rpm from postgresql.org)
Perhaps this is a bug, but you have not given a complete example that
would allow someone else to try to reproduce it. Please see the
guideline
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Btw., it would really seem like a neat feature if a given pg_dump suite
> would also handle the respective previous version. Otherwise we're in a
> situation like now where we've got a shiny new pg_dump but people that
> want to upgrade are still stu
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I can imagine some people wanting this. However, 7.1 has new deadlock
> detection code, so I would you make a 7.1 version and send it over. We
> can get it into 7.2.
I object strongly to any such "feature" in the low-level form that
Henryk proposes, b
Nat Irons <[EMAIL PROTECTED]> writes:
> Regression tests for Yellow Dog Linux (PPC RedHat derivative) failed all
> over the place with 7.0.3. Passed smoothly with 7.1RC3, though.
Unsurprising if you compiled with any optimization level higher than -O0.
regards, tom lane
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can you give me specific text? I though 7.1 was a little better about
> preserving the metadata.
Not in the least --- 7.1's CLUSTER is just as bad as ever.
regards, tom lane
---(end of broadcast)---
Mark Butler <[EMAIL PROTECTED]> writes:
> By the way, is alignment padding really a good use of disk space? Surely
> storage efficiency trumps minor CPU overhead in any I/O bound database.
Weren't you just complaining about excess palloc's ;-) ? Seriously,
I have no idea about the costs/benefit
> Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's
> patch should be applied?
I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD
seems to insist on calling every Intel processor a "i386". In this case,
are you suggesting that this patch covers all N
=> create view testview as select relname, 'Constant'::text from pg_class;
=> \d testview
View "testview"
Attribute | Type | Modifier
---+--+--
relname | name |
?column? | text |
View definition: SELECT DISTINCT pg_class.relname, 'Constant'::text FROM
pg_class ORD
[EMAIL PROTECTED] (Nathan Myers) writes:
> Yacc and yacc-like programs are most useful when the target grammar (or
> your understanding of it) is not very stable. With Yacc you can make
> sweeping changes much more easily; big changes can be a lot of work in
> a hand-coded parser.
And, in fac
Tom Lane wrote:
>
> Mark Butler <[EMAIL PROTECTED]> writes:
> > Surely if we have an write exclusive table lock we can rewrite tuples
> > in place rather than creating new versions with its corresponding 2x
> > space requirement.
>
> Nyet. Consider transaction rollback.
Well, the first thing t
Tom Lane wrote:
> Yawn ... given row overhead, alignment padding, etc, this is not nearly
> as big a deal as you make it ...
For a table with ten decimal columns with an average of 5 significant digits
apiece, each row could be reduced from ~170 bytes to about ~90 bytes, which
could be rather si
72 matches
Mail list logo
