Christopher Kings-Lynne writes:
I anyone going to email the people who last reported the unsupported
platforms to see if they'll re-test?
Shall I? Or should someone more official?
From the latest list, all but the few odd NetBSD ports are known not to
work. And I've posted a request to
Bruce Momjian schrieb:
Peter Eisentraut wrote:
Bruce Momjian writes:
Oh, I forgot about that. This leaves datetime.h and decimal.h in
/pgsql/include. I don't see how 7.4.1 can fix that because people will
not be using initdb.
This has nothing to do with initdb.
Right. I mean install isn't
Hi Everyone,
This is my first post here so please tell me to go somewhere else if this
is the wrong place to post questions like this.
I am using PostgreSQL 7.3.2 and have used earlier versions (7.1.x onwards)
and with all of them I noticed same problem with INSERTs when there is a
large data
Hi,
what use pure XML Docbook (non-SGML) for 7.5 PostgreSQL docs?
XML advantage:
- more clean and simple conversion into printable
formats by FO (Formatting Objects),
- needn't huge TeX stuff (!),
- Java based XSLT/FO processors like FOP (support PDF, PCL, PS, SVG, Print,
AWT, MIF
Le Vendredi 14 Novembre 2003 10:19, Karel Zak a crit :
KDE project use XML docbook and I think they have same problems and
maybe already solutions too :-)
http://i18n.kde.org/translation-howto/doc-translation.html
Karel
Dear Karel,
Nice link with detailed information.
This is a valid reason
Karel Zak writes:
XML advantage:
All very true.
XML disadvantage:
- no arbitrary parameter entities
If someone can solve this for me, I'm ready to switch.
Follow-up to [EMAIL PROTECTED] please.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
On Fri, Nov 14, 2003 at 10:32:10AM +0100, Peter Eisentraut wrote:
XML disadvantage:
- no arbitrary parameter entities
I unsure if I understand, can you show some example of this problem?
I think there is a lot of XML Docbook docs in a lot of projects and I
will wonder if in the
+ if (!chmod(pg_data,0700))
Out of curiosity, what was the rationale for using 0700? I know it was a pain
for me when I had a script to monitor the tmp usage. Surely read access to
privileged users isn't really a problem? I'm thinking more of loosening the
paranoia check elsewhere
Greg Stark writes:
Wouldn't at least 0750 be safe? That way putting a user in the postgres group
would grant him access to be able to browse around and read the files in
pg_data.
That assumes that there is a restricted postgres group, which is not
guaranteed.
--
Peter Eisentraut [EMAIL
The shell script said this:
$ECHO_N fixing permissions on existing directory $PGDATA...
$ECHO_C
chmod go-rwx $PGDATA || exit_nicely
There's no more rationale than that for this patch.
I'm inclined to agree with you, though.
cheers
andrew
Greg Stark wrote:
+ if
On Fri, 2003-11-14 at 10:32, Jan Wieck wrote:
Bruce Momjian wrote:
Jan Wieck wrote:
Christopher Browne wrote:
[EMAIL PROTECTED] (elein) writes:
What is the status of CVS head? Isn't it in sync with 7.4.RC2? I
just upgraded from CVS and rebuilt clean and initdb now gives this
Shridhar Daithankar wrote:
On Friday 14 November 2003 03:05, Jan Wieck wrote:
For sure the sync() needs to be replaced by the discussed fsync() of
recently written files. And I think the algorithm how much and how often
to flush can be significantly improved. But after all, this does not
change
Greg Stark [EMAIL PROTECTED] writes:
I'm not suggesting making that the default setup, just loosening the
paranoia check so that if an admin sets the directory to be group
readable the database doesn't refuse to start up.
In previous discussions of this point, paranoia was considered
Should the jdbc driver compile ok with 7.4RC2?
I configure like so
./configure --with-perl --with-java --with-libs=/sw/lib
--with-includes=/sw/include
But it fails with this
compile:
BUILD FAILED
file:/usr/local/install/postgresql-7.4RC2/src/interfaces/jdbc/build.xml:114:
Old driver was
Robert Treat wrote:
On Fri, 2003-11-14 at 10:32, Jan Wieck wrote:
Bruce Momjian wrote:
Jan Wieck wrote:
Christopher Browne wrote:
[EMAIL PROTECTED] (elein) writes:
What is the status of CVS head? Isn't it in sync with 7.4.RC2? I
just upgraded from CVS and rebuilt clean and initdb now
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
I'm not suggesting making that the default setup, just loosening the
paranoia check so that if an admin sets the directory to be group
readable the database doesn't refuse to start up.
In previous discussions of this point, paranoia was
Shridhar Daithankar wrote:
On Friday 14 November 2003 03:05, Jan Wieck wrote:
For sure the sync() needs to be replaced by the discussed fsync() of
recently written files. And I think the algorithm how much and how often
to flush can be significantly improved. But after all, this does not
Dear,
I'd like to make new system catalog table.Could you let me know how to do
about that?
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that
Hi Everyone,
This is my first post here so please tell me to go somewhere else if this
is the wrong place to post questions like this.
I am using PostgreSQL 7.3.2 and have used earlier versions (7.1.x onwards)
and with all of them I noticed same problem with INSERTs when there is a
large data
I find such strange thing in my postgres server
---
distance= \d cities;
* QUERY **
SELECT c.oid,
n.nspname,
c.relname
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE
Good morning,
I am new to Postgres, so excuse for such question, but I can't find it
in dokumentation.
I have table cities. I can insert into it, select from it, but cat run such
command
distance= \d cities
ERROR: parser: parse error at or near .
distance= \d cities;
ERROR: parser: parse
I think I have some more information on the statistics collector startup
problem on Solaris.
I inserted the following into pgstat.c:
if (bind(pgStatSock, addr-ai_addr, addr-ai_addrlen) 0)
{
/* what type of socket are we trying to bind? */
fprintf(stderr, Address family is %d\n,
Jan Wieck wrote:
Yeah, there was a problem with *extreme* sharing ... the code tried to
use the same buffer for multiple disk blocks at the same time, and
somehow the backends did not agree on the correct content. But it's
fixed and back in. You can see ARC working by setting
On Thu, Nov 13, 2003 at 04:04:23PM -0500, Derek Morr wrote:
the
machine I'm using (a V880 running 2.8) has no IPv6 address on any of its
interfaces.
So the for loop over the addresses that are returned should go
over both socket() and bind() instead of only socket(). And
probably
On Fri, Nov 14, 2003 at 02:04:56PM +0200, Petro Pelekh wrote:
I find such strange thing in my postgres server
---
distance= \d cities;
ERROR: parser: parse error at or near .
You are using psql from a 7.3 version to talk to an older server. This
is not
On Fri, Nov 14, 2003 at 06:36:41PM +1100, Slavisa Garic wrote:
Rows Present Start Time Finish Time
100 1068790804.12 1068790804.12
1000 1068790807.87
-Original Message-
From: Slavisa Garic [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 11:37 PM
To: [EMAIL PROTECTED]
Subject: [HACKERS] INSERT extremely slow with large data sets
Hi Everyone,
This is my first post here so please tell me to go somewhere
else if
Bruce Momjian wrote:
Jan Wieck wrote:
Yeah, there was a problem with *extreme* sharing ... the code tried to
use the same buffer for multiple disk blocks at the same time, and
somehow the backends did not agree on the correct content. But it's
fixed and back in. You can see ARC working by
On Fri, Nov 14, 2003 at 14:04:56 +0200,
Petro Pelekh [EMAIL PROTECTED] wrote:
So my database doesn't have pg_namespace system catalog, and doesn't
understand such pg_catalog.pg_class c, but understand pg_class c. May be
some of you have such problems with postgres and can help.
It looks
Bruce Momjian [EMAIL PROTECTED] writes:
Shridhar Daithankar wrote:
Having fsync for regular data files and sync for WAL segment a comfortable
compramise? Or this is going to use fsync for all of them.
I think we still need sync() for WAL because sometimes backends are
going to have to
Kurt Roeckx [EMAIL PROTECTED] writes:
So the for loop over the addresses that are returned should go
over both socket() and bind() instead of only socket(). And
probably connect() too.
The code now assumes if you create a socket of a certain type you
can actually use it.
Ah, light dawns...
Hannu Krosing writes:
AFAICT, this patch does not buy us anything at all. It's just a different
spelling of existing functionality. We have never done that before.
what about DROP COLUMN - this is also just a different spelling for
SELECT INTO, migrate all constraints, DROP OLD TABLE,
Tom,
Too bad we didn't figure this out yesterday. We are now in code freeze
for 7.4 release, and I'm hesitant to apply a fix for what is arguably a
broken platform. Core guys, time for a vote ... do we fix, or hold this
for 7.4.1?
One thing I've not seen an answer to: does Postgres run
Tom Lane wrote:
Kurt Roeckx [EMAIL PROTECTED] writes:
So the for loop over the addresses that are returned should go
over both socket() and bind() instead of only socket(). And
probably connect() too.
The code now assumes if you create a socket of a certain type you
can actually use
Josh Berkus [EMAIL PROTECTED] writes:
One thing I've not seen an answer to: does Postgres run acceptably on other
people's Solaris boxes? If this bug is preventing running on Solaris at
all, I'd say fix it ... Solaris is a major platform. If it only affects
users of one particular
Solaris (5.7, 5.8, 5.9) on many different
workstation/server types is very important to us...
I agree with Bruce
Bruce Momjian wrote:
Must fix, I believe, especially if it is the same function call sequence
used by the postmaster so we have a high probability it will work on all
platforms.
Tom Lane writes:
There is no info documentation, so you don't need this option.
Someone was complaining about this just recently. We don't need the
option and don't have it implemented, but configure --help advertises
it anyway (and fails to advertise the --docdir option that we do have).
Peter Eisentraut [EMAIL PROTECTED] writes:
PostgreSQL currently contains a hack that does a macro substitution
s/info/doc/ to create a --docdir option, but that evidently does not catch
all cases. Also, I'm getting reports that it breaks package builds
because they automatically provide an
[EMAIL PROTECTED] (Josh Berkus) writes:
Too bad we didn't figure this out yesterday. We are now in code freeze
for 7.4 release, and I'm hesitant to apply a fix for what is arguably a
broken platform. Core guys, time for a vote ... do we fix, or hold this
for 7.4.1?
One thing I've not seen
Christopher Browne [EMAIL PROTECTED] writes:
For what it's worth, I have been running regression on Solaris with
numerous of the betas, and RC1 and [just now] RC2, with NO problems.
It seems clear that some Solaris installations are affected and some
are not. Presumably there is some version
I can fire up our solaris machine and let you have access to it if you
want to do some destructive testing.
Tom Lane wrote:
Christopher Browne [EMAIL PROTECTED] writes:
For what it's worth, I have been running regression on Solaris with
numerous of the betas, and RC1 and [just now] RC2, with
Hmm I know it's been a while since I used patch but I seem to be having
problems applying it. Perhaps my patch is outdated??
patch -b pgstat.c patchfile
Looks like a new-style context diff.
Hunk#2failed at line 203.
Hunk#2failed at line 210.
Hunk#3failed at line 284.
3 out of 3 hunks
On Friday 14 November 2003 12:03, Jan Wieck wrote:
Robert Treat wrote:
On Fri, 2003-11-14 at 10:32, Jan Wieck wrote:
Or did you mean ARC itself? Since it replaced the old LRU code, it is
the only choice you have now. Which sort of raises the question if we
would want to have multiple
This worked in 7.3:
regression=# select '1999-jan-08'::date;
ERROR: date/time field value out of range: 1999-jan-08
HINT: Perhaps you need a different datestyle setting.
Setting DateStyle to YMD doesn't help, and in any case I'd think that
this ought to be considered an unambiguous input
I said:
This worked in 7.3:
regression=# select '1999-jan-08'::date;
ERROR: date/time field value out of range: 1999-jan-08
HINT: Perhaps you need a different datestyle setting.
Setting DateStyle to YMD doesn't help, and in any case I'd think that
this ought to be considered an
On Fri, 14 Nov 2003, Josh Berkus wrote:
Tom,
Too bad we didn't figure this out yesterday. We are now in code freeze
for 7.4 release, and I'm hesitant to apply a fix for what is arguably a
broken platform. Core guys, time for a vote ... do we fix, or hold this
for 7.4.1?
One thing
On Fri, 14 Nov 2003, Alvaro Herrera wrote:
On Fri, Nov 14, 2003 at 06:36:41PM +1100, Slavisa Garic wrote:
Rows PresentStart Time Finish Time
100 1068790804.12
Hi Dann
Here is the schema and also could you just be more specific on COPY
command. ALso does talking dirrectly to API speed things up ? (I am new to
databases but i am learning quickly)
-- NimrodEnfJob --
create table NimrodEnfJob(
exp_id INTEGER not null
On Fri, 14 Nov 2003, Tom Lane wrote:
I said:
This worked in 7.3:
regression=# select '1999-jan-08'::date;
ERROR: date/time field value out of range: 1999-jan-08
HINT: Perhaps you need a different datestyle setting.
Setting DateStyle to YMD doesn't help, and in any case I'd think
Tom Lane wrote:
I said:
This worked in 7.3:
regression=# select '1999-jan-08'::date;
ERROR: date/time field value out of range: 1999-jan-08
HINT: Perhaps you need a different datestyle setting.
Setting DateStyle to YMD doesn't help, and in any case I'd think that
this ought to be
On Fri, 14 Nov 2003, Bruce Momjian wrote:
Tom Lane wrote:
I said:
This worked in 7.3:
regression=# select '1999-jan-08'::date;
ERROR: date/time field value out of range: 1999-jan-08
HINT: Perhaps you need a different datestyle setting.
Setting DateStyle to YMD doesn't
Marc G. Fournier wrote:
On Fri, 14 Nov 2003, Bruce Momjian wrote:
Tom Lane wrote:
I said:
This worked in 7.3:
regression=# select '1999-jan-08'::date;
ERROR: date/time field value out of range: 1999-jan-08
HINT: Perhaps you need a different datestyle setting.
Setting
-Original Message-
From: Slavisa Garic [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 5:12 PM
To: Dann Corbit
Cc: Slavisa Garic; [EMAIL PROTECTED]
Subject: Re: [HACKERS] INSERT extremely slow with large data sets
Hi Dann
Here is the schema and also could you just
On Fri, 14 Nov 2003, Andrew Dunstan wrote:
I'm confused. My understanding from what Tom said is that it affects all
configurations.
the stats collector problem, from what I've seen through this list,
affects Solaris, and only some Solaris configuration ..
---(end of
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 14 Nov 2003, Bruce Momjian wrote:
I guess the question is whether we would fix this in a minor release,
and I think the answer it yes, so we can fix it now.
Ah, so we attempt to fix a bug that affects what appears to be a small %
of
Check that you don't need to use the -p option at all.
Also, make sure you remove any ^M (DOS CR) characters from the line
endings. That always happens to me if I receive the emailon a windows
machine and save the attachment, windows sometimes likes to rewrite all
the line endings, causing
Marc G. Fournier wrote:
On Fri, 14 Nov 2003, Andrew Dunstan wrote:
I'm confused. My understanding from what Tom said is that it affects all
configurations.
the stats collector problem, from what I've seen through this list,
affects Solaris, and only some Solaris configuration ..
But the issue at
I propose the attached patch to fix the problem. It doesn't break any
regression tests, and it appears to fix the cases noted in its comment.
Opinions on whether to apply this to 7.4?
I think it should be fixed, since it could cause applications to break.
Shouldn't you also add a regression
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Shouldn't you also add a regression test to catch this in the future?
Yes, I absolutely plan to stick some regression test additions into HEAD.
There's not a need for such changes in the 7.4 branch though. Right at
the moment what we need is a
Tom Lane wrote:
The pgstat patch has already been checked to my satisfaction, but the
datetime patch needs more eyeballs on it; anyone out there have time to
look at it?
FWIW, it looks good to me, seems to work as intended, and passes all
existing regression tests.
Joe
On Fri, 14 Nov 2003, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Shouldn't you also add a regression test to catch this in the future?
Yes, I absolutely plan to stick some regression test additions into HEAD.
There's not a need for such changes in the 7.4 branch
My bad, confused two different issues in one thread :(
On Fri, 14 Nov 2003, Joe Conway wrote:
Marc G. Fournier wrote:
On Fri, 14 Nov 2003, Andrew Dunstan wrote:
I'm confused. My understanding from what Tom said is that it affects all
configurations.
the stats collector problem, from
Slavisa Garic [EMAIL PROTECTED] writes:
You didn't understand the question. Inserting ONE ROW when there are already
5000 ROWS present takes 0.01 seconds. Inserting ONE ROW when there are
already 6 ROWS present takes 0.09 secods.
The numbers you presented didn't really offer any strong
On Friday 14 November 2003 14:23, Neil Conway wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Robert Treat wrote:
people would always want to have those choices (especially for doing
development/testing/benchmarking between the different methods) the
question is is it worth the effort to give
Our philosophy has never been to give people configuration options just
in case they might be valuable to them. If we did that, we would be
like Oracle.
We give config options only if we can't decide the best default. For
testing, you can have an #ifdef and we can test it ourselves. If we can
darnit!
patch attached.
(Thinks - do we need to worry about suid sgid and sticky bits on data dir?)
andrew
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I just noticed tonight that the new initdb introduced a subtle change of
behavior. I use a shell script to automate the process
Andrew Dunstan [EMAIL PROTECTED] writes:
darnit!
patch attached.
Applied with correction (you got the return-value check backwards)
and further work to deal reasonably with error conditions occurring
in check_data_dir.
regards, tom lane
---(end
Patch applied. Thanks.
---
Andrew Dunstan wrote:
darnit!
patch attached.
(Thinks - do we need to worry about suid sgid and sticky bits on data dir?)
andrew
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED]
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
darnit!
patch attached.
Applied with correction (you got the return-value check backwards)
and further work to deal reasonably with error conditions occurring
in check_data_dir.
Tom applied it before I could.
--
Bruce Momjian
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
darnit!
patch attached.
Applied with correction (you got the return-value check backwards)
and further work to deal reasonably with error conditions occurring
in check_data_dir.
darnit again.
I'm taking a break - my head is
70 matches
Mail list logo
