Andrew Dunstan schrieb:
Tom Lane wrote:
Andrew Dunstan writes:
Marko Kreen wrote:
On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote:
Couple thoughts here --- one, someone upthread suggested
cyg$(NAME)$(DLSUFFIX as the proper value for shlib.
.exe's in different directories than
Currently, here are the options available for wal_sync_method:
#wal_sync_method = fsync# the default
varies across platforms:
# fsync,
fdatasync, fsync_writethrough,
#
On Mon, Aug 08, 2005 at 08:04:44PM -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Marko Kreen wrote:
On same topic:
http://archives.postgresql.org/pgsql-general/2005-07/msg00811.php
Why does win32 PostgreSQL allow data corruption by default?
It behaves the same on
I think we should offer the reliable option by default,
and mention
the fast option for those who have battery-backed cache
in the manual.
But only on Win32?
We should do what's possible with what's given to us.
On Win32:
1. We can write through cache.
Yes.
2. We have
FYI, issue (1) applies to postgresql as well. It's fixed by
http://archives.postgresql.org/pgsql-patches/2005-07/msg00529.php.
//Magnus
-Original Message-
From: Team SHATTER [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 09, 2005 12:42 AM
To: bugtraq@securityfocus.com
Cc: [EMAIL
Also, why can't win32 be safe without battery-backed cache?
I can't see such requirement on other platforms.
It can, you just need to learn how to configure your
system. There are
two different options to make it safe on win32 without
battery backed
cache:
I personally do
On Tue, Aug 09, 2005 at 10:02:44AM +0200, Magnus Hagander wrote:
It behaves the same on Unix as Win32, and if you have
battery-backed
cache, you don't need writethrough, so we don't have it as
default. I
Correction, if you have bbwc, you *should not* have writethrough. Not
only
On Tue, Aug 09, 2005 at 10:08:25AM +0200, Magnus Hagander wrote:
That can definitly be debated. Properly maintaned on proper hardware,
it's quite reliable these days.
Most filesystem corruptions that happen on windows are because people
enable write caching on drives without battery backup.
That can definitly be debated. Properly maintaned on proper
hardware,
it's quite reliable these days.
Most filesystem corruptions that happen on windows are
because people
enable write caching on drives without battery backup. The
same issue
we're facing here, it's *not* a
On Tue, Aug 09, 2005 at 12:14:09PM +0200, Magnus Hagander wrote:
That can definitly be debated. Properly maintaned on proper
hardware,
it's quite reliable these days.
Most filesystem corruptions that happen on windows are
because people
enable write caching on drives without
I dunno about workstation OS, but on the server OSes it certainly
isn't default.
At least on XP Pro it is default.
Yuck.
The professional probably tests it on his own desktop. I don't
think PostgreSQL reaches the data center before passing
the run on
desktop.
I can't
On Mon, 2005-08-08 at 19:50 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2005-08-08 at 16:55 -0400, Tom Lane wrote:
Considering we don't even have code to do this, much less have expended
one day of beta testing on it, back-patching seems a bit premature.
You
Well we have a CRM package that does ERP/project
management/ticketing/file sharing etc as well, called EGS
http://egs.sourceforge.net. Although the sf.net page is out of date we
are about to release 1.0 on 1st september to great fanfare! With a new
website et al. It works out of the box on
On Tue, Aug 09, 2005 at 12:58:31PM +0200, Magnus Hagander wrote:
Now thinking about it, the guy had corrupt table, not WAL log.
How is WAL-tables synched? Does the 'wal_sync_method'
affect it or not?
I *think* it always fsyncs() there as it is now, but I'm not 100% sure.
No. If fsync
Now thinking about it, the guy had corrupt table, not WAL log.
How is WAL-tables synched? Does the 'wal_sync_method'
affect it or not?
I *think* it always fsyncs() there as it is now, but I'm
not 100% sure.
No. If fsync is off, then no fsync is done to the data files
on
On Tue, Aug 09, 2005 at 04:05:28PM +0200, Magnus Hagander wrote:
Now thinking about it, the guy had corrupt table, not WAL log.
How is WAL-tables synched? Does the 'wal_sync_method'
affect it or not?
I *think* it always fsyncs() there as it is now, but I'm
not 100% sure.
On Tue, Aug 09, 2005 at 12:25:36PM +0300, Marko Kreen wrote:
On Tue, Aug 09, 2005 at 10:08:25AM +0200, Magnus Hagander wrote:
Most filesystem corruptions that happen on windows are because people
enable write caching on drives without battery backup. The same issue
we're facing here, it's
Simon Riggs [EMAIL PROTECTED] writes:
We either need to have a special routine for each catalog table, or we
scan all tables, all of the time. The latter is a disaster, so lets look
at the former: spicing the code with appropriate catalog checks would be
a lot of work and probably very error
I think the point Denis is trying to make is that postgresql will get
much more exposure if SugarCRM works with
it out of the box.
Not taking away from any of these other great projects, but to get
mindshare postgresql needs to work with existing projects.
Dave
On 9-Aug-05, at 7:55 AM,
Magnus Hagander wrote:
Now thinking about it, the guy had corrupt table, not WAL log.
How is WAL-tables synched? Does the 'wal_sync_method'
affect it or not?
I *think* it always fsyncs() there as it is now, but I'm not 100% sure.
wal_sync_method is also used to flush pages during a
Magnus Hagander wrote:
I dunno about workstation OS, but on the server OSes it certainly
isn't default.
At least on XP Pro it is default.
Yuck.
I see enable write caching as enabled by default on my XP Pro laptop,
though laptops can be said to already have battery-backed disks.
--
Magnus Hagander [EMAIL PROTECTED] writes:
FYI, issue (1) applies to postgresql as well. It's fixed by
http://archives.postgresql.org/pgsql-patches/2005-07/msg00529.php.
Note that the equivalent exploit in Postgres would require superuser
privilege (since it requires creating a C function).
Magnus Hagander wrote:
Now thinking about it, the guy had corrupt table, not WAL log.
How is WAL-tables synched? Does the 'wal_sync_method'
affect it or not?
I *think* it always fsyncs() there as it is now, but I'm
not 100% sure.
wal_sync_method is also used to flush
Now thinking about it, the guy had corrupt table, not WAL log.
How is WAL-tables synched? Does the 'wal_sync_method'
affect it or not?
I *think* it always fsyncs() there as it is now, but I'm
not 100% sure.
wal_sync_method is also used to flush pages during a
checkpoint, so
Compiere also runs on PostgreSQL and has gotten some good press.
It previously only support Oracle.
Ken
On Tue, Aug 02, 2005 at 08:53:52PM +0300, Hannu Krosing wrote:
On L, 2005-07-30 at 22:26 -0400, Denis Lussier wrote:
Thanks, I'll check it out. I didn't see much evidence on the SugarCRM
Richard Huxton dev@archonet.com writes:
Can I ask what happens if we end up re-using a recently de-allocated
OID? Specifically, can a cached plan (e.g. plpgsql function) end up
referring to an object created after it was planned:
Definitely a potential risk, but not one to be solved by the
Tom Lane wrote:
What if there aren't any untouched chunks? With only 64K-chunk
granularity, I think you'd hit that condition a lot more than you are
hoping. Also, this seems to assume uniqueness across all tables in an
entire cluster, which is much more than we want; it makes the 32-bit
size
On Tue, 2005-08-09 at 16:01 +0100, Richard Huxton wrote:
Tom Lane wrote:
What if there aren't any untouched chunks? With only 64K-chunk
granularity, I think you'd hit that condition a lot more than you are
hoping. Also, this seems to assume uniqueness across all tables in an
entire
Joshua D. Drake wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Peter Eisentraut wrote:
The correct lingo would be standard_conforming_strings. I'm going to
change
that.
Sounds good.
No problem here either.
So does that mean for 8.1 it will
Currently, pg_config will tell about the configure options that were
used, but it does not let you find out if any environment variables were
used to determine CC, CFLAGS, etc. More than once I've found myself
wanting to verify that information about an installation. So I'm
considering adding
Tom Lane wrote:
Currently, pg_config will tell about the configure options that were
used, but it does not let you find out if any environment variables were
used to determine CC, CFLAGS, etc. More than once I've found myself
wanting to verify that information about an installation. So I'm
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
pg_config --cc
pg_config --cppflags
pg_config --cflags
pg_config --cflags_sl
pg_config --ldflags
pg_config --ldflags_sl
pg_config --libs
I would be tempted to have one flag called, say, --build-env which has
all the interesting
On 2005-08-09, Magnus Hagander [EMAIL PROTECTED] wrote:
... or iDE disks with write cache enabled. I've certainly seen more than
what I'd call 1% (though I haven't studied it to be sure) that's because
of write-cached disks...
Every SCSI disk I've looked at recently has had write cache enabled
Tom Lane wrote:
I wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I would be tempted to have one flag called, say, --build-env which has
all the interesting settings from the build environment in one hit.
The one-flag way would be human readable but not program
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2005-08-09, Magnus Hagander [EMAIL PROTECTED] wrote:
... or iDE disks with write cache enabled. I've certainly seen more than
what I'd call 1% (though I haven't studied it to be sure) that's because
of write-cached disks...
Every SCSI disk I've
Andrew Dunstan [EMAIL PROTECTED] writes:
--all would be fine. In fact, why not make it the default?
We could do that. Any objections out there?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the
On Tue, Aug 09, 2005 at 03:25:16PM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
pg_config --cc
pg_config --cppflags
pg_config --cflags
pg_config --cflags_sl
pg_config --ldflags
pg_config --ldflags_sl
pg_config --libs
I would be tempted to
I wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I would be tempted to have one flag called, say, --build-env which has
all the interesting settings from the build environment in one hit.
The one-flag way would be human readable but not program friendly.
OTOH there's nothing saying we
Just to chime in --- I have been surprised how _few_ complaints we have
gotten about oid wraparound hitting system table oid conflicts. I agree
that telling people to retry their CREATE statements isn't really an
ideal solution, and the idea of looping to find a free oid is a good one.
Dear Hackers,
In the early days of savepoints (then nested transactions), it was
possible to push and pop sub-transactions in a kind of FIFO stack.
While the savepoint method certainly has its advantages, there are some
things I really miss about the old behavior, mostly because you had
finer
On Tue, Aug 09, 2005 at 04:10:08PM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
--all would be fine. In fact, why not make it the default?
We could do that. Any objections out there?
+1 in favor of making '--all' the default behavior :)
Cheers,
D
--
David Fetter [EMAIL
On Mon, Aug 08, 2005 at 11:28:54PM +0100, Simon Riggs wrote:
As I mentioned, as time goes on, this is very likely to occur with older
installations before it occurs with newer ones. Older databases tend to
have older releases, hence the comment to backpatch. I regard this as a
Well, as an
On 2005-08-09, Tom Lane [EMAIL PROTECTED] wrote:
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2005-08-09, Magnus Hagander [EMAIL PROTECTED] wrote:
... or iDE disks with write cache enabled. I've certainly seen more than
what I'd call 1% (though I haven't studied it to be sure) that's
Andrew - Supernews [EMAIL PROTECTED] writes:
If a SCSI drive reports write complete when it hasn't actually put the
bits on the platter yet, then it's simply broken.
I guess you haven't read the spec much, then.
[ shrug... ] I have seen that spec before: I was making a living by
implementing
44 matches
Mail list logo
