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
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 ef
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
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
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 bran
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
--
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
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 test
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 ha
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 the
"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 %
> o
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 o
> -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
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.
Setti
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 DateSt
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
> >
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 c
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 referen
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 1068
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?
>
>
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 u
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 fo
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 ha
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 aile
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, wit
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 versio
[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
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
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 ha
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 people those options?
To me, the question is whet
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.
--
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
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 act
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
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 T
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 daw
Tom Lane wrote:
> 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
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
Jan Wieck wrote:
> 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
>
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
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 work
> -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
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 10
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 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 conne
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
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",
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: par
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 pg_catalog.pg_table_is_visi
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 set
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 yo
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 swimmi
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.
--
Bruc
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
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
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 wa
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
---(e
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
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 detec
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 desir
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 th
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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 gro
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 ini
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
>> lovely informative initdb failed message.
>
> No, I be
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 (!chmod(pg
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
> + 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 r
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 Postg
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 broadcast)---
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 rea
On Fri, Nov 14, 2003 at 09:57:16AM +0100, Jean-Michel POURE wrote:
> Le Vendredi 14 Novembre 2003 09:26, Karel Zak a écrit :
> > What use pure XML Docbook (non-SGML) for 7.5 PostgreSQL docs?
>
> Dear Karel,
>
> For information, how do you plan to translate XML Docbook format?
KDE project use
Le Vendredi 14 Novembre 2003 09:26, Karel Zak a écrit :
> What use pure XML Docbook (non-SGML) for 7.5 PostgreSQL docs?
Dear Karel,
For information, how do you plan to translate XML Docbook format?
Is there an easy way to parse XML Docbook and import/export the text into
Gettext format? I was
There is a pgsql-performance list, which was created for questions like yours.
Your problem was brought up many times before, so searching the archives is
an alternative.
Regards, Christoph
>
> Hi Everyone,
>
> This is my first post here so please tell me to go somewhere else if this
> is
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 a
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
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 g
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
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
78 matches
Mail list logo