On 8/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Personally, my only complaint regarding either choice is the
> assumption that a 'WIN32' guy is stupid, and that 'WIN32' itself is
> deficient. As long as the default is well documented, I don't have a
> problem with either 'faster but less
On Tue, Aug 09, 2005 at 11:01:36PM -0400, Tom Lane wrote:
> 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..
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
implem
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 sur
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 al
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
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 grain
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.
-
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
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
>
>
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 postm
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 S
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 friendl
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 e
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
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
c
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 opt
Joshua D. Drake wrote:
> Tom Lane wrote:
> > Bruce Momjian 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 f
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
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
Richard Huxton 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 sorts
of mechan
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
> > > 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:
> > > > 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
"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:
> > > 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-back
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 duri
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, Jake
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 er
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,
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
>
> > > 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 dat
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.
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 postgres
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.
>
> > 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
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 dr
> > 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 *
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.
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.
> > > 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
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: [EMA
> > > 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.
Y
On Mon, Aug 08, 2005 at 08:04:44PM -0400, Tom Lane wrote:
> Bruce Momjian 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 Unix as
> > > > Currently, here are the options available for wal_sync_method:
> > > >
> > > > #wal_sync_method = fsync# the default
> varies across platforms:
> > > > # fsync,
> fdatasync, fsync_writethrough,
> > > >
45 matches
Mail list logo
