On Tue, 5 Aug 2003, Andrew Dunstan wrote:
(Responding to the deafening silence regarding my posts a couple of days
ago about logging dbnames and disconnections) ;-)
The dbname patch is now done. If nobody objects to the format
([db:yourdbname]) I'll submit it - I did it that way to make
On Tue, 12 Aug 2003, Christopher Kings-Lynne wrote:
rbt=3D# ALTER USER rbt SET CONSTRAINTS ALL DEFERRED;
ERROR: syntax error at or near ALL at character 32
rbt=3D# ALTER USER rbt SET CONSTRAINTS =3D DEFERRED;
ERROR: constraints is not a recognized option
SET CONSTRAINTS ALL
On Thu, 28 Aug 2003, Tom Lane wrote:
I've traced through the failure reported here by Markus Kräutner:
http://archives.postgresql.org/pgsql-hackers/2003-08/msg01132.php
What is happening is that as the UPDATE adds tuples (all with the same
hash key value) to the table, the hash bucket being
On Thu, 28 Aug 2003, Marc G. Fournier wrote:
On Thu, 28 Aug 2003, Thomas Swan wrote:
Has anyone looked at changing the default block size across the board
and what the performance improvements/penalties might be? Hardware has
changed quite a bit over the years.
I *think* that the
On Fri, 29 Aug 2003, Tom Lane wrote:
scott.marlowe [EMAIL PROTECTED] writes:
On Thu, 28 Aug 2003, Neil Conway wrote:
On Thu, Aug 28, 2003 at 05:37:39PM -0400, Tom Lane wrote:
shrug Who's to say? We've found bugs in the btree logic recently,
too.
I'd rather print a loud warning when
Would it be possible to catch an unconstrained max(id)/min(id) and rewrite
it as select id from table order by id [desc] limit1 on the fly in the
parser somewhere?
That would require fairly little code, and be transparent to the user.
I.e. low hanging fruit.
On 5 Sep 2003, Greg Stark wrote:
On Mon, 8 Sep 2003, Bruce Momjian wrote:
Dann Corbit wrote:
Mingw uses the native Win32 libraries.
Porting from a Mingw port to VC++ will be trivial compared to what we
have now.
where can I access latest dev source code and dev docs in
the/from CVS ?
Maybe you want the
On Tue, 9 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is our maximum table size limited by the maximum block number?
Certainly.
Is the 16TB number a hold-over from when we weren't sure block number
was unsigned, though now we are pretty sure it is handled as
On Fri, 19 Sep 2003, Joshua D. Drake wrote:
Hello,
I just read a rather disturbing post
PostgreSQL does not support read uncommited and repeatable read
isolation levels? If that is so... then PostgreSQL is NOT ACID compliant?
What is the real deal on this?
Postgresql
On Fri, 26 Sep 2003, Christopher Kings-Lynne wrote:
Is there any chance we could have initdb show the version of postgresql
it is running as when initdb is run?
If you install many different versions in parallel, don't you give your
installation paths some meaning that contain the
On Fri, 26 Sep 2003, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
so it appears that cygwin's echo generates a different newline style
than what got put into sql_features.txt. A possible way to fix this is
to put the \. line into
On Fri, 26 Sep 2003, Tom Lane wrote:
scott.marlowe [EMAIL PROTECTED] writes:
I'm running into issues where 7.4's pg_dump/pg_dumpall from a 7.2 database
to a 7.4beta3 database is producing some errors like this:
ERROR: literal newline found in data
HINT: Use \n to represent newline
On Fri, 26 Sep 2003, Bruce Momjian wrote:
scott.marlowe wrote:
The attached file produces this problem. Note it's a blank trailing field
that looks to be causing it. The error for this .sql file is:
ERROR: literal carriage return found in data
HINT: Use \r to represent carriage
On Fri, 26 Sep 2003, Bruce Momjian wrote:
scott.marlowe wrote:
OK, 'vi' shows it as:
COPY people2 (id, persons) FROM stdin;
59 Chance Terry--S
60 ^M
\.
which is _exactly the case the error was supposed to catch. Now, the
big question is where did
On Fri, 26 Sep 2003, Bruce Momjian wrote:
scott.marlowe wrote:
OK, 'vi' shows it as:
COPY people2 (id, persons) FROM stdin;
59 Chance Terry--S
60 ^M
\.
which is _exactly the case the error was supposed to catch. Now, the
big question is where did
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
Bruce Momjian writes:
The argument that you want a warning because you might have mixed
newlines in the file seems less likely than this case where they are
using a literal carriage return as a data value at the end of the line.
I don't
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
scott.marlowe writes:
but I get basically the same thing if I dump it to a .sql file and do:
psql dbname dbname.sql
Use psql -f dbname.sql instead.
and the output is:
psql:webport.sql:803: ERROR: function odbc_user already exists
On Fri, 26 Sep 2003, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
scott.marlowe writes:
but I get basically the same thing if I dump it to a .sql file and do:
psql dbname dbname.sql
Use psql -f dbname.sql instead.
This doesn't seem like a good argument not to add more
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
scott.marlowe writes:
table name too, like Bruce said. The bothersome bit is that in pg_dump,
it says the line, relative to just this part of the copy command, so you
don't even know which table is giving the error.
I don't see the problem
On Tue, 30 Sep 2003, Joshua D. Drake wrote:
Hello,
With the recent stint of pg_upgrade statements and the impending
release of 7.4 what
do people think about having a dedicated maintenance team for 7.3? 7.3
is a pretty
solid release and I think people will be hard pressed to upgrade
On Tue, 30 Sep 2003, Tom Lane wrote:
It seems some junior electrician in Panama pulled the wrong circuit
breaker ... and then the mail.postgresql.org server spent an
unreasonable number of hours fsck'ing. (Why is Marc a FreeBSD fan
anyway? Don't ask me, I work for Red Hat.) Anyhow, due to
On Wed, 1 Oct 2003, Joshua D. Drake wrote:
With 7.4 I'm finding upgrading to be easier. I'll likely upgrade out
production servers to 7.4.0 when it comes out and wind up skipping 7.3
altogether.
Sure but I talking about people who are running 7.3 and are happy with
it. The
On Wed, 1 Oct 2003, Darko Prenosil wrote:
Two mails with updated translations for /src/backend/po/hr.po are lost.
First time I send clear po file, second tar.gz - no result.
Is something blocking mails with attachment ? I didn't receive notification
that mail is blocked or something like
On Tue, 30 Sep 2003, Steve Yalovitser wrote:
Hello,
I'd like to know if its possible to coopt the postgres storage subsystem to
rely entirely on ram based structures, rather than disk. Any documentation
or ideas would be appreciated.
Sure, create a ram disk. Set $PGDATA to it with proper
OK, I've done some more testing on our IDE drive machine.
First, some background. The hard drives we're using are Seagate
drives, model number ST380023A. Firmware version is 3.33. The machine
they are in is running RH9. The setup string I'm feeding them on startup
right now is: hdparm -c3
On 14 Oct 2003, Greg Stark wrote:
Michael Brusser [EMAIL PROTECTED] writes:
Michael Brusser [EMAIL PROTECTED] writes:
2003-10-10 22:37:05 ERROR: cannot read block 0 of s_noteimportlinks:
Interrupted system call
Hmm. I found this hard to believe at first, but indeed my
On Wed, 22 Oct 2003, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
That said, perhaps the TODO for changing LIMIT / OFFSET to be expression
based should also mention bumping them to int8.
Can't get excited about it ... this would slow down the normal use of
the facility for what
On Wed, 22 Oct 2003, Tom Lane wrote:
Richard Huxton [EMAIL PROTECTED] writes:
On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
The idea is that you give each function its own schema search path at
creation time, and that path applies to that function for the rest of its
life.
Sounds like your drives are full.
On Thu, 23 Oct 2003, Yuval Lieberman wrote:
Hi!
I'm doing a select (from an OACS page or from psql) and I get:
ERROR: Failed to create temporary file pgsql_tmp/pgsql_tmp27212.775
The same select work ok a different database (which is on a different
On Wed, 22 Oct 2003, Jochen Westland [invigo] wrote:
Hi All,
i'm running Postgresql 2.2x, so i am not quitse sure wether the bug i am reporting
is already fixed
in newer versions or not.
In my version
select round(2.5); returns 2;
select round(2.501) returns 3;
refering to my
On Fri, 24 Oct 2003, Michael Brusser wrote:
But this seems to work correctly on 7.3.2 and 7.3.4:
psql -c select round (2.5)
Password:
round
---
3
(1 row)
=
I just tried that on my 7.2.4 and 7.4 beta 4 machines and I get 2 for
round(2.5)
Ackkk. I
On Tue, 28 Oct 2003, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
I say leave it the way it is. If you want system table tab completion,
simply:
ALTER USER ... SET search_path =3D pg_catalog,...;
Unfortunately, that *does not* affect the tab-completion behavior;
it will
On Tue, 28 Oct 2003, Tom Lane wrote:
scott.marlowe [EMAIL PROTECTED] writes:
Is it possible to remove the implicit search path of pg_catalog from a
psql session without it breaking lots of stuff?
Do you consider +, count(), etc to be important stuff?
Me, hardly ever use them :-) So I
On 29 Oct 2003, Doug McNaught wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
FreeBSD 4.9 was released today. In the release notes was:
2.2.6 File Systems
A new DIRECTIO kernel option enables support for read operations that
bypass the buffer cache and put data directly
On 30 Oct 2003, Vatsal Avasthi wrote:
Hi,
I am facing a strange problem and thats bugging me for a long time,
I am using postgres version 7.2.1.
Is it possible for you to upgrade to 7.2.4 just to make sure it's not a
problem that was fixed from 7.2.1 to 7.2.4?
On Thu, 30 Oct 2003, ivan wrote:
you can also patch your kernel and when you write cat /etc/passwd system
give you only your line , whitout any others users, so exacly what you
need ,
in pgsql i think that users dont need to know about others , and also
them
databases, i call it security
On Thu, 30 Oct 2003, Joshua D. Drake wrote:
Hello,
I know I will probably be flamed into oblivion for this but I would
like to make a suggestion about
the upcoming release.
What if we delayed until the end of the year?
The two reasons that I can come up with are:
1.
On Thu, 30 Oct 2003, Joshua D. Drake wrote:
If I understood correctly, Josh was complaining about VACUUM sucking too
much of his disk bandwidth. autovacuum wouldn't help that --- in fact
would likely make it worse, since a cron-driven vacuum script can at
least be scheduled for low-load
201 - 238 of 238 matches
Mail list logo
