I just tested a bug I originally fount in 7.1b4 with the new 7.1RC3 and it
still exists. I would consider this a major bug because I know of no work
around.
Basically what happens is that a dump of an existing Unicode database (from
7.03) has a double-byte hyphen character that becomes \255 in th
Poet/Joshua Drake wrote:
>
> Good day,
>
> I've been experimenting a bit with Full Text Indexing in PostgreSQL. I
> have found several conflicting sites various places on the net pertaining
> to whether or not PostgreSQL supports FTI, and I was hoping I could find
> an authoritative answer here
Bruce Momjian wrote:
>
> Well, again, I will write a performance tuning article this month, which
> hopefyully will help people.
>
> My recommendation on shared memory is that if you have a machine that is
> going to be used only for PostgreSQL, the shared memory should be
> increased to the poi
I believe that the basis for such a mechanism should be a model of the
semantic type inheritance for primitive data types. Note that type
inheritance is a completely different concept than representation inheritance,
as witnessed by the confusion over the now implemented proposal to correct the
> > >This is a new feature? Using indecies is "new"? I guess I really beg to
> > >differ. Seems like a bugfix to me (in the "workaround" category).
> > Yes they are. INT8 is not a feature/type yet supported by the driver, hence
> > it's "new".
> > Infact the jdbc driver supports no array's at t
> Furthermore, after trying to just index on a 8191-character long substring
> of the resume, I run into the following:
> ERROR: btree: index item size 3948 exceeds maximum 2713
> The only way I could actually get the index created was to substring the
> body of the resumes down to 2k. I also lat
I've tried to write a plpgsql function, and noticed the following
problem : (7.1RC2 rpm from postgresql.org)
When issuing a comand like:
DECLARE
rowvar tablaname%ROWTYPE
BEGIN
FOR rowvar IN SELECT FROM tablename t WHERE t.xxx=yyy AND t.zzz=qqq
LOOP
.
END LOOP;
or just simply issuin
On Tue, Apr 10, 2001 at 02:24:24PM +0100, Peter Mount wrote:
> At 18:30 09/04/01 -0700, Kyle VanderBeek wrote:
> >This is a new feature? Using indecies is "new"? I guess I really beg to
> >differ. Seems like a bugfix to me (in the "workaround" category).
>
> Yes they are. INT8 is not a feature
Sorry, meant to hit all of these.
On Tue, Apr 10, 2001 at 02:24:24PM +0100, Peter Mount wrote:
> >I'm going to start digging around in the optimizer code so such hacks as
> >mine aren't needed. It's really haenous to find out your production
> >server is freaking out and doing sequential scans f
Good day,
I've been experimenting a bit with Full Text Indexing in PostgreSQL. I
have found several conflicting sites various places on the net pertaining
to whether or not PostgreSQL supports FTI, and I was hoping I could find
an authoritative answer here - I tried searching the website's archiv
On Wed, 11 Apr 2001, Peter Eisentraut wrote:
> The Hermit Hacker writes:
>
> > okay, not sure how we should document this, but apparently pg_dumpall
> > doesn't work as the man page at:
> >
> > http://www.postgresql.org/users-lounge/docs/7.0/user/app-pgdumpall.htm
> >
> > appears to suggest:
>
>
The Hermit Hacker writes:
> okay, not sure how we should document this, but apparently pg_dumpall
> doesn't work as the man page at:
>
> http://www.postgresql.org/users-lounge/docs/7.0/user/app-pgdumpall.htm
>
> appears to suggest:
> Now, I swore I did a 'setenv PGHOST db.hub.org' to get around
Well, again, I will write a performance tuning article this month, which
hopefyully will help people.
My recommendation on shared memory is that if you have a machine that is
going to be used only for PostgreSQL, the shared memory should be
increased to the point where you are not seeing any swap
Bruce Momjian wrote:
>
> OK, what options would you recommend be auto-tuned in each circumstance?
> I can imagine open files and maybe sortmemory, but even then, other
> backends can affect the proper value. Share memory usually has a kernel
> limit which prevents us from auto-tuning that too mu
Hmm. The problem is as you describe, but the requirements for a solution
are more severe than you (or I) would hope.
We would like to have an extensible mechanism for type promotion and
demotion, but it is not (yet) clear how to implement it. In this case,
we must demote a constant assigned as "
On Tue, Apr 10, 2001 at 02:24:33PM -0300, The Hermit Hacker wrote:
>
> Theoretically, should one be able to do:
>
> pg_dumpall > db.out
> remove 7.0.3 bin, lib, data, etc
> install 7.1 bin, lib, etc
> initdb 7.1
> psql template1 < db.out
>
> Basically, has anyone actually tried *that* yet and c
okay, not sure how we should document this, but apparently pg_dumpall
doesn't work as the man page at:
http://www.postgresql.org/users-lounge/docs/7.0/user/app-pgdumpall.htm
appears to suggest:
==
%pg_dumpall -h pgsql
psql: No pg_hba.conf entry for host localhost, user
No errors, nothing ... here is the backend:
%bin/postmaster -D /usr/local/pgsql/data
DEBUG: database system was shut down at 2001-04-10 15:04:08 ADT
DEBUG: CheckPoint record at (0, 1522068)
DEBUG: Redo record at (0, 1522068); Undo record at (0, 0); Shutdown TRUE
DEBUG: NextTransactionId: 615
On Tue, 10 Apr 2001, The Hermit Hacker wrote:
> all I did was use pg_dumpall from v7.0.3 to dump to a text file, and
> "psql template1 < dumpfile" to load it back in again ...
>
> obviously this doesn't work like it has in the past?
Marc --
Was there an error message during restore?
I've been
v7.0.3 database:
trends_acctng=# \d
List of relations
Name | Type | Owner
-+---+---
accounts| table | pgsql
admin | table | pgsql
calls | table | pgsql
comments| table | pgsql
cookies | table | pgsql
credit_card | table | pgsql
cr
> The reason I need to compile w/ Perl
> support turned on is what I am reading
> in the README.rserv of the ERServer
> available in contrib directory.
> It says that the requirements are:
> - PostgreSQL >= 7.0.X
>A separate Makefile is required for PostgreSQL 7.0.x and earlier
> - Perl5 and t
Thomas Lockhart wrote:
> The parser does not know that your int4 constant "0" can be represented
> as an int2. Try
>
> SELECT * FROM access_log WHERE method_num = int2 '0';
>
> (note the type coersion on the constant; there are other ways of
> specifying the same thing).
Surely this is somet
> What you may not be aware of is that there are two places where Perl
> is used in the build. One is the Perl client library (the 'Pg'
> module). This should not require libperl.so as all it does is build a
> bog-standard extension module.
>
> The other usage is for Perl as an embedded procedu
Theoretically, should one be able to do:
pg_dumpall > db.out
remove 7.0.3 bin, lib, data, etc
install 7.1 bin, lib, etc
initdb 7.1
psql template1 < db.out
Basically, has anyone actually tried *that* yet and can report on whether
or not it works?
I'm just about to try it here, on >2gig of data,
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 table with the shorter name; but
> if you refer to the table by the same long name, PG repo
John Coers writes:
> Hi,
>
> My generic problem is performance when copying very large amounts of data to a db
>from multiple clients.
>
> I am writing a C program on Linux Redhat6.2 that accesses a 7.0.3 database using
>libpq. I
> would like to be able to do a printf through STDOUT (or anothe
This is what I get in Oracle 8:
SQL> CREATE TABLE test (value VARCHAR (10));
Table created.
SQL> INSERT INTO test VALUES ('Mike Mascari');
INSERT INTO test VALUES ('Mike Mascari')
*
ERROR at line 1:
ORA-01401: inserted value too large for column
SQL> quit
Of course, if the standa
Thomas Lockhart wrote:
>
> The parser does not know that your int4 constant "0" can be represented
> as an int2. Try
>
> SELECT * FROM access_log WHERE method_num = int2 '0';
hmmm, but its still a sequentiell scan:
logger=# explain SELECT * FROM access_log
WHER
Zeugswetter Andreas SB wrote:
> Yes, iirc the only thing you are allowed to do is issue a warning,
> but the truncation is allowed and must succeed.
> (checked in Informix and Oracle)
? As much as I remember, Oracle raises an error. But it's been a few
years since I last touched it, so maybe I'm
> url_idx seems OK:
>
> logger=# EXPLAIN SELECT * FROM access_log WHERE url_id = 1000;
> Index Scan using url_idx on access_log
> (cost=0.00..3618.92 rows=1002 width=89)
>
>
>
> But the others not:
>
> logger=# EXPLAIN SELECT * FROM access_log WHERE method_num = 0;
> Seq Scan
Zeugswetter Andreas SB writes:
> > Excessively long values are currently silently truncated when they are
> > inserted into char or varchar fields. This makes the entire notion of
> > specifying a length limit for these types kind of useless, IMO. Needless
> > to say, it's also not in complianc
We do have postgresql.conf. I am unsure how I would tune those based
on a single flag.
> > I can't see how any configure option would be faster or
> > better than the existing command line /config file parameters
> > -- it would only serve to make things harder to deal with IMHO.
> > "Tuning" Po
Well, what is being discussed here would require a *recompile* to change the
values, so you sure wouldn't want that! :-)
Currently you can set a lot of internal variables with the SET command in any PG
session.. It's useful for forcing index or sequential scans and such (and I'm
sure a lot more).
> I can't see how any configure option would be faster or
> better than the existing command line /config file parameters
> -- it would only serve to make things harder to deal with IMHO.
> "Tuning" PostgreSQL is pretty simple, and is explained pretty
> well throughout the manual (especially in th
Indeed, as an avid user (and tuner, I suppose) of PostgreSQL, I can't
see how any configure option would be faster or better than the existing
command line /config file parameters -- it would only serve to make things
harder to deal with IMHO. "Tuning" PostgreSQL is pretty simple, and is
expla
The problem is that I can't figure out what would be tuned by these
options. We only have 2-3 parameters that can be changed.
> I can understand why there might be some resistance to the idea of
> adding performance tuning flags into the server rather than documenting
> existing settings bette
> I have the following table, containing about 57 Rows, but some
> indexes are not used, on 7.1RC4, freshly vacuumed (analyse). It was the
> same at least in 7.1RC1
> CREATE TABLE access_log(
> access_time timestamp NOT NULL DEFAULT NOW(),
> method_num int2NO
Nathan Myers wrote:
> (Very long names may show up in machine- generated schemas.) Would
> patches for this, e.g. to refuse to create a table with an impossible
> name, be welcome?
Yes. And throw in the picture also the length of sequences coming from
SERIALs, etc.
--
Alessio F. Bragadini
> Excessively long values are currently silently truncated when they are
> inserted into char or varchar fields. This makes the entire notion of
> specifying a length limit for these types kind of useless, IMO. Needless
> to say, it's also not in compliance with SQL.
To quote Tom "paragraph an
Hi,
I have the following table, containing about 57 Rows, but some
indexes are not used, on 7.1RC4, freshly vacuumed (analyse). It was the
same at least in 7.1RC1
--- SNIP ---
CREATE TABLE access_log(
site_id int2NOT NULL DEFAULT 0,
access_time timestam
I can understand why there might be some resistance to the idea of
adding performance tuning flags into the server rather than documenting
existing settings better, but I think a compromise would be possible.
Could we develop a helper application that takes the --tuning
superserver argument and
> At 1:50 AM -0400 4/6/01, Tom Lane wrote:
> >"Henry B. Hotz" <[EMAIL PROTECTED]> writes:
> > > Bottom line: 7.1RC1 passes most of the regression tests on
> > > NetBSD/macppc.
> >
> >The only thing that surprised me here was all of the warnings from
> >libreadline calls:
> >
> > >> tab-complete.
42 matches
Mail list logo
