Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Now, that second step is not needed, but as of today it produces an
installation that won't start due to improper permissions on data
That's a bug --- evidently the "fix permissions" path of control is
wrong; can you take a look?
Here's a smal
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 the real checkpointing
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 of
> - rm old data directory
> - mkdir new data directory
> - initdb
> - load from pgdumpall
> Now, that second step is not nee
I just noticed tonight that the new initdb introduced a subtle change of
behavior. I use a shell script to automate the process of
- rm old data directory
- mkdir new data directory
- initdb
- load from pgdumpall
Now, that second step is not needed, but as of today it produces an
installation tha
Thanks to Tom Lane, Kurt Roeckx, Zeugswetter Andreas and Shigehiro.
It was solved. It reports.
On Thu, 13 Nov 2003 09:50:59 -0500 Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Hmm ... that's certainly evidence that "localhost" will resolve
> correctly on your machine, but then why is the bind() faili
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?
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
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 believe
--On Thursday, November 13, 2003 23:09:15 -0500 Tom Lane
<[EMAIL PROTECTED]> wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
I just updated to the current REL7_4_STABLE cvs, and get
a problem at line 18048 where cat isn't on the path writing
the config.status file.
If I add /usr/bin/ to the
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I just updated to the current REL7_4_STABLE cvs, and get
> a problem at line 18048 where cat isn't on the path writing
> the config.status file.
> If I add /usr/bin/ to the cat invocation, it works.
> What's broke?
Your shell?
That's hardly the only
OK.
---
Christopher Kings-Lynne wrote:
> Hey Bruce,
>
> When you get around to it, can you commit the patch I submitted that
> dumps conversions in pg_dump. I need that in to complete my COMMENT ON
> patch.
>
> I think
I just updated to the current REL7_4_STABLE cvs, and get
a problem at line 18048 where cat isn't on the path writing
the config.status file.
If I add /usr/bin/ to the cat invocation, it works.
What's broke?
(I updated using:
cvs update -rREL7_4_STABLE -P -d
)
LER
--
Larry Rosenman
Hey Bruce,
When you get around to it, can you commit the patch I submitted that
dumps conversions in pg_dump. I need that in to complete my COMMENT ON
patch.
I think it's pretty safe to apply, and I'm not 100% sure I still have a
local copy of the patch, so I can't let it drift too much :(
C
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 going
Jan checked in the ARC changes last night, and he and Tom ran into
some problems, leading to that being pulled back out, while he
revisits the code.
It's back in again, and appears to work now (at least the regression
tests pass ... no idea about performance ...)
I actually managed to hang my pro
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.
--
Peter Eisentraut [EMAIL PROTECTED]
---(en
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Barring surprises, we will institute a code freeze in the 7.4 branch
> > tonight with an eye to wrapping the release Sunday. Is anyone aware
> > of critical loose ends that still need to be dealt with?
>
> The only thing I had left was the install
Tom Lane writes:
> Barring surprises, we will institute a code freeze in the 7.4 branch
> tonight with an eye to wrapping the release Sunday. Is anyone aware
> of critical loose ends that still need to be dealt with?
The only thing I had left was the installation locations for the Informix
compa
Jan Wieck wrote:
> That is all right and as said, how often, how much and how forced we do
> the IO can all be configurable and as flexible as people see fit. But
> whether you use sync(), fsync(), fdatasync(), O_SYNC, O_DSYNC or
> posix_fadvise(), somewhere you have to do the write(). And that
Kurt Roeckx wrote:
> On Thu, Nov 13, 2003 at 05:39:32PM -0500, Bruce Momjian wrote:
> > Jan Wieck wrote:
> > > Bruce Momjian wrote:
> > > > He found that write() itself didn't encourage the kernel to write the
> > > > buffers to disk fast enough. I think the final solution will be to use
> > > > f
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 believe that they have started applying 7.5 patches, not
Christopher Browne <[EMAIL PROTECTED]> writes:
> Jan checked in the ARC changes last night, and he and Tom ran into
> some problems, leading to that being pulled back out, while he
> revisits the code.
It's back in again, and appears to work now (at least the regression
tests pass ... no idea abou
Kurt Roeckx wrote:
On Thu, Nov 13, 2003 at 05:39:32PM -0500, Bruce Momjian wrote:
Jan Wieck wrote:
> Bruce Momjian wrote:
> > He found that write() itself didn't encourage the kernel to write the
> > buffers to disk fast enough. I think the final solution will be to use
> > fsync or O_SYNC.
>
> w
On Thu, Nov 13, 2003 at 05:39:32PM -0500, Bruce Momjian wrote:
> Jan Wieck wrote:
> > Bruce Momjian wrote:
> > > He found that write() itself didn't encourage the kernel to write the
> > > buffers to disk fast enough. I think the final solution will be to use
> > > fsync or O_SYNC.
> >
> > write(
Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Kurt Roeckx wrote:
> >> On Thu, Nov 13, 2003 at 04:35:31PM -0500, 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 f
Bruce Momjian wrote:
Kurt Roeckx wrote:
On Thu, Nov 13, 2003 at 04:35:31PM -0500, 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
and the problem seen here with the order of messages sent by initdb has
been fixed by Tom in the head branch (which is the only place it would
have occurred).
cheers
andrew
Robert Treat wrote:
They are no longer in sync. Jan has started committing some of his ARC
work (though I think it might
[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 believe that they have started applying 7.5 patches, notably
including reimp
Kurt Roeckx wrote:
> On Thu, Nov 13, 2003 at 04:35:31PM -0500, 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 doe
On Thu, Nov 13, 2003 at 04:35:31PM -0500, 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 the real ch
They are no longer in sync. Jan has started committing some of his ARC
work (though I think it might be backed out currently) and Tom has
committed his cross data-type index work. Both have reported errors with
initdb so it might not be completely stable right now. generally it
should be, but not a
-- moved to -hackers
On Thu, 2003-11-13 at 11:35, Hannu Krosing wrote:
> Rod Taylor kirjutas N, 13.11.2003 kell 16:59:
> >
> > Can you please suggest a better term to use in place of TRANSFORM?
> > Perhaps UPDATE WITH?
>
> or perhaps USING, based loosely on our use of USING in CREATE INDEX ?
U
The attached diff is another attempt for distributing the write IO.
It is a separate background process much like the checkpointer. It's
purpose is to keep the number of dirty blocks in the buffer cache at a
reasonable level and try that the buffers returned by the strategy for
replacement are
Speaking from a non-profit whose enterprise data sits inside postgres,
we would be willing to invest a few thousand dollars into the pot of
synchronous multi-master replication. Postgres-r sounded absolutely
marvelous to us back in the day that it was rumored to be one of the
possible deliverab
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.
I haven't had trouble previously with cvs head or
other versions.
$ sudo make install
...
PostgreSQL installation comple
--On Thursday, November 13, 2003 13:18:31 -0500 Tom Lane
<[EMAIL PROTECTED]> wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
The only thing I'm aware of is the setsockopt() issue on OpenServer.
We have no proposed patch for that, either, so it will also have to
wait for 7.4.1.
modulo the unac
Larry Rosenman <[EMAIL PROTECTED]> writes:
> The only thing I'm aware of is the setsockopt() issue on OpenServer.
We have no proposed patch for that, either, so it will also have to
wait for 7.4.1.
regards, tom lane
---(end of broadcast)---
Robert E. Bruccoleri writes:
> I have compiled and tested Postgresql-7.4beta4 on SGI Irix
> 6.5.20 using the MIPS Pro 7.4 compilers and on SGI Altix using the gcc
> 2.96 compilers and both ports passed all tests within the limits of
> numerical accuracy.
I've added the Irix port. Altix is
Patrick Welche writes:
> All 93 tests passed.
>
> with 7.4rc2 on NetBSD-1.6ZE/acorn32.
Added, thanks. I put it under CPU "arm32", because that's the actual CPU,
which PostgreSQL depends on, and acorn32 is just the system type. Let me
know if this is grossly incorrect.
--
Peter Eisentraut [
--On Thursday, November 13, 2003 12:43:37 -0500 Tom Lane
<[EMAIL PROTECTED]> wrote:
Barring surprises, we will institute a code freeze in the 7.4 branch
tonight with an eye to wrapping the release Sunday. Is anyone aware
of critical loose ends that still need to be dealt with?
The only thing o
Barring surprises, we will institute a code freeze in the 7.4 branch
tonight with an eye to wrapping the release Sunday. Is anyone aware
of critical loose ends that still need to be dealt with?
The only thing on my own radar screen is a couple of reports of the
stats collector failing to start on
Jan Wieck <[EMAIL PROTECTED]> writes:
> Yeah, adding a buffer multiple times to the list of unused buffers
> ensures that it later on gets used for multiple contents simultaneously.
Hm. Looking at the patch last night, I was wondering why you had
removed all the guard logic from BufTableInsert
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Yeah, adding a buffer multiple times to the list of unused buffers
ensures that it later on gets used for multiple contents simultaneously.
Hm. Looking at the patch last night, I was wondering why you had
removed all the guard logic from BufT
Tom Lane <[EMAIL PROTECTED]> writes:
> The other idea I had was to somehow create associations of opclasses,
> so that you could say that "int2_ops, int4_ops, and int8_ops all sort
> values compatibly, so it's okay to go find the operator you need in
> int4_ops or int2_ops". I don't have any co
Bruce Momjian wrote:
Hans-J?rgen Sch?nig wrote:
Meanwhile we seem to be in a situation where PostgreSQL is rather
competing against Oracle than against MySQL. In our case there are more
people asking for Oracle -> Pg migration than for MySQL -> Pg. MySQL
does not seem to be the great enemy beca
Jan Wieck wrote:
> I would like to add that there is a good reason why they aren't in the
> same league. As a rule of thumb one can say that the smaller a software
> company, the faster some development must turn into revenue. That is why
> Oracle and Microsoft have the "time" to do things right
Jan Wieck wrote:
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
That's strange, if I reverse apply my patch I have buffer leak's and all
kinds of crap. Can't even initdb. Who else applied patches tonight?
FWIW, I can initdb --- that seems fine --- but the regression tests spew
lots of smal
Jan Wieck <[EMAIL PROTECTED]> writes:
> This all has changed. The freelist in ARC really contains clean and
> unused buffers. I think I should write up a README.freelist explaining
> the new bufmgr<->strategy interface and how the algorithm works.
Yes, I was going to complain about the lack of a
On Wed, Nov 12, 2003 at 04:43:03PM -0500, Andrew Sullivan wrote:
> People often like to say they need hot-fail-capable, five
BTW, this was not a rant at the person posting -- he was just
reporting what he has heard. I've heard it plenty, too, and the
people whence I've heard it are the rant targ
On Wed, Nov 12, 2003 at 07:46:11PM -0500, James Robinson wrote:
> Speaking from a non-profit whose enterprise data sits inside postgres,
> we would be willing to invest a few thousand dollars into the pot of
> synchronous multi-master replication. Postgres-r sounded absolutely
> marvelous to us
Lamar Owen <[EMAIL PROTECTED]> writes:
> The biggest issue is going to be 'will it build' on those releases. The tcl
> version deal (with tcl prior to 8.1) will prevent building on Red Hat 6.2
FYI, we have put in a patch that should allow building with Tcl 8.0.* again.
Kiyoshi Sawada <[EMAIL PROTECTED]> writes:
> $ /usr/local/bin/nslookup localhost
> Note: nslookup is deprecated and may be removed from future releases.
> Consider using the `dig' or `host' programs instead. Run nslookup with
> the `-sil[ent]' option to prevent this message from appearing.
> Serv
On Thu, 13 Nov 2003, Lamar Owen wrote:
> On Wednesday 12 November 2003 11:51 pm, Marc G. Fournier wrote:
> > On Wed, 12 Nov 2003, Lamar Owen wrote:
> > > The biggest issue is going to be 'will it build' on those releases.
> > > The tcl version deal (with tcl prior to 8.1)
>
> > Tom applied a pat
On Thursday 13 November 2003 12:09 am, Matthew T. O'Connor wrote:
> On Wed, 2003-11-12 at 23:44, Lamar Owen wrote:
> > My hands are somewhat tied at the present to only supporting what I
> > actively run. That is currently RHL 8.0 and Fedora Core 1. (not 1.0,
> > incidentally; there is no minor ve
On Wednesday 12 November 2003 11:51 pm, Marc G. Fournier wrote:
> On Wed, 12 Nov 2003, Lamar Owen wrote:
> > The biggest issue is going to be 'will it build' on those releases.
> > The tcl version deal (with tcl prior to 8.1)
> Tom applied a patch so that the build will continue to work on 8.0.x .
54 matches
Mail list logo
