"Tom Lane" <[EMAIL PROTECTED]> writes:
> I wrote:
>> (BTW, in case you can't tell from the drift of my questions, I've
>> separated the patch into "add background wal writer" and "add async
>> commit", and am working on the first half.)
>
> I've committed the first half of that. Something that st
On Mon, 2007-07-23 at 20:02 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > Autovac is the most clean implementation of a special process, so seemed
> > like a good prototype. I'd thought I'd combed out any pointless code
> > though.
>
> What, you mean there's pointless code in autovac?
On Tue, 2007-07-24 at 00:58 -0400, Tom Lane wrote:
> I wrote:
> > (BTW, in case you can't tell from the drift of my questions, I've
> > separated the patch into "add background wal writer" and "add async
> > commit", and am working on the first half.)
>
> I've committed the first half of that.
On Mon, 2007-07-23 at 21:06 -0400, Tom Lane wrote:
> I came across another point worthy of mention: as given, the patch turns
> XLogWrite's "flexible write" logic into dead code, because there are no
> callers that pass flexible = true. We could rip that out, but it seems
> to me there's still so
On Mon, 2007-07-23 at 21:11 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > What's the thing about doing the flush twice in a couple of comments in
> > calls to XLogBackgroundFlush? Are they just leftover comments from
> > older code?
>
> I was wondering that too --- they
+
+ Asynchronous commit provides different behaviour to setting
+ fsync = off, which is a server-wide
+ setting that will alter the behaviour of all transactions,
+ overriding the setting of synchronous_commit,
+ as well as risking much wider data loss. With fsync
+
On Tue, 2007-07-24 at 10:51 +0200, Florian Weimer wrote:
> +
> + Asynchronous commit provides different behaviour to setting
> + fsync = off, which is a server-wide
> + setting that will alter the behaviour of all transactions,
> + overriding the setting of synchronous_commit,
* Simon Riggs:
>> I think fsync=off also endagers metadata, while synchronous_commit=off
>> should be perfectly safe as far as the metadata is concerned.
>> Wouldn't this be worth mentioning as well?
>
> Well, I think "wider data loss" covers it for me, but I don't have a
> problem with people wan
When building with MingW, we get a ton of warnings of the type:
C:/Perl/lib/CORE/config.h:39:20: warning: "/*" within comment
(see
http://pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=vaquita&dt=2007-07-23%20200011&stg=make)
Attached patch removes this by disabling the warning specifically for
plp
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> When building with MingW, we get a ton of warnings of the type:
> C:/Perl/lib/CORE/config.h:39:20: warning: "/*" within comment
>
> (see
> http://pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=vaquita&dt=2007-07-23%20200011&stg=make)
Huh, what's actu
On Tue, Jul 24, 2007 at 12:42:38PM +0100, Gregory Stark wrote:
>
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>
> > When building with MingW, we get a ton of warnings of the type:
> > C:/Perl/lib/CORE/config.h:39:20: warning: "/*" within comment
> >
> > (see
> > http://pgbuildfarm.org/cgi-bin/
MSVC generates a number of const warnings, that's been discussed before
(http://archives.postgresql.org/pgsql-hackers/2007-01/msg01214.php).
Attached patch adds a pragma to get rid of the warnings. Again, not sure if
it's worth it?
I think I need to #ifdef the pragma - gcc generates a warning if
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> /*#define HAS_BCMP/**/
>
> The difference is in the space. This is with perl 5.8.8.819 from
> ActiveState - the latest is 5.8.8.820, and I doubt they've changed
> that there.
Huh, I'm on 5.8.8 here as well. I suppose ActiveState has to generat
Magnus Hagander wrote:
When building with MingW, we get a ton of warnings of the type:
C:/Perl/lib/CORE/config.h:39:20: warning: "/*" within comment
(see
http://pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=vaquita&dt=2007-07-23%20200011&stg=make)
Attached patch removes this by disabling the w
Magnus Hagander <[EMAIL PROTECTED]> writes:
> override CPPFLAGS += -DPLPERL_HAVE_UID_GID
> + # Perl on win32 contains /* within comment all over the header file,
> + # so disable this warning.
> + override CFLAGS += -Wno-comment
> endif
If you insist you can apply that in some way that makes i
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Stefan mentioned that the warning may be one that shows up in a different
> compiler somewhere as well, thouh, which might indicate that we should fix
> the underlying issue? (Even if the code is correct, if it confuses multiple
> compilers...)
I th
Gregory Stark <[EMAIL PROTECTED]> writes:
> Without async commits? Do we really want the walwriter doing the
> majority of the wal-flushing work for normal commits? It seems like
> that's not going to be any advantage over just having some random
> backend do the commit.
Sure: the advantage is tha
On Tue, Jul 24, 2007 at 09:55:57AM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > override CPPFLAGS += -DPLPERL_HAVE_UID_GID
> > + # Perl on win32 contains /* within comment all over the header file,
> > + # so disable this warning.
> > + override CFLAGS += -Wno-comment
On Tue, 24 Jul 2007, Gregory Stark wrote:
Do we really want the walwriter doing the majority of the wal-flushing
work for normal commits? It seems like that's not going to be any
advantage over just having some random backend do the commit.
Might there be some advantage in high-throughput/mul
Magnus Hagander wrote:
On Tue, Jul 24, 2007 at 09:55:57AM -0400, Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
override CPPFLAGS += -DPLPERL_HAVE_UID_GID
+ # Perl on win32 contains /* within comment all over the header file,
+ # so disable this warning.
+ override CFLA
On Tue, Jul 24, 2007 at 10:11:52AM -0400, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
> >On Tue, Jul 24, 2007 at 09:55:57AM -0400, Tom Lane wrote:
> >
> >>Magnus Hagander <[EMAIL PROTECTED]> writes:
> >>
> >>> override CPPFLAGS += -DPLPERL_HAVE_UID_GID
> >>>+ # Perl on win32 contain
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Without async commits? Do we really want the walwriter doing the
>> majority of the wal-flushing work for normal commits? It seems like
>> that's not going to be any advantage over just having some random
>> backend do the commit.
>
>
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Without async commits? Do we really want the walwriter doing the
>> majority of the wal-flushing work for normal commits? It seems like
>> that's not going to be any advantage over just having some random
>> back
On Tue, 2007-07-24 at 10:01 -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Without async commits? Do we really want the walwriter doing the
> > majority of the wal-flushing work for normal commits? It seems like
> > that's not going to be any advantage over just having some
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Sure: the advantage is that the backends (ie, user query processing)
>> don't get blocked on fsync's. This is not really different from the
>> rationale for having the bgwriter.
> I'm puzzled though. How do th
Magnus Hagander wrote:
On Tue, Jul 24, 2007 at 09:55:57AM -0400, Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
override CPPFLAGS += -DPLPERL_HAVE_UID_GID
+ # Perl on win32 contains /* within comment all over the header file,
+ # so disable this warning.
+ override CFLA
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> Stefan mentioned that the warning may be one that shows up in a different
>> compiler somewhere as well, thouh, which might indicate that we should fix
>> the underlying issue? (Even if the code is correct,
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>>> Stefan mentioned that the warning may be one that shows up in a different
>>> compiler somewhere as well, thouh, which might indicate that we should fix
>>> the u
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Tue, Jul 24, 2007 at 09:55:57AM -0400, Tom Lane wrote:
>> If you insist you can apply that in some way that makes it Windows-only.
> Uh, it's already inside a win32-only block. So it'll only affect mingw.
Doh ... not enough caffeine yet ... sorry f
Gregory Stark <[EMAIL PROTECTED]> writes:
> Can we just disable const checking for MSVCC in general without using the
> #pragmas? It clearly doesn't understand how const works making that warning
> from it useless.
+1 ... any useful warning of this kind will be had from other compilers.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> An alternative might be to provide a perl script in the tools directory
> which would fix the perl header file.
Seems like more work than it's worth. I'm OK with Magnus' proposed
Makefile hack --- though someone should also complain to ActiveState
so
Am Dienstag, 24. Juli 2007 17:24 schrieb Gregory Stark:
> Can we just disable const checking for MSVCC in general without using the
> #pragmas? It clearly doesn't understand how const works making that warning
>
> >from it useless.
That was my thought.
--
Peter Eisentraut
http://developer.postgr
Florian Weimer wrote:
> I think fsync=off also endagers metadata, while synchronous_commit=off
> should be perfectly safe as far as the metadata is concerned.
> Wouldn't this be worth mentioning as well?
Is it true that a transaction is turned into sync commit as soon as it
writes on a system cat
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Te
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Can we just disable const checking for MSVCC in general without using the
>> #pragmas? It clearly doesn't understand how const works making that warning
>> from it useless.
>
> +1 ... any useful warning of this kind will be had from ot
Magnus Hagander wrote:
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
Can we just disable const checking for MSVCC in general without using the
#pragmas? It clearly doesn't understand how const works making that warning
from it useless.
+1 ... any useful warning of
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Gregory Stark <[EMAIL PROTECTED]> writes:
>>> Can we just disable const checking for MSVCC in general without using the
>>> #pragmas? It clearly doesn't understand how const works making that warning
>>> from it useless.
>>
>> +1 ...
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Gregory Stark <[EMAIL PROTECTED]> writes:
Can we just disable const checking for MSVCC in general without using the
#pragmas? It clearly doesn't understand how const works making that warning
from it
On Tue, Jul 24, 2007 at 02:08:00PM -0400, Alvaro Herrera wrote:
> Florian Weimer wrote:
>
> > I think fsync=off also endagers metadata, while synchronous_commit=off
> > should be perfectly safe as far as the metadata is concerned.
> > Wouldn't this be worth mentioning as well?
>
> Is it true that
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, Jul 24, 2007 at 02:08:00PM -0400, Alvaro Herrera wrote:
>> Is it true that a transaction is turned into sync commit as soon as it
>> writes on a system catalog? Is it desirable to make it so?
> If we don't do that then regular users have the ab
On Tue, 2007-07-24 at 16:25 -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Tue, Jul 24, 2007 at 02:08:00PM -0400, Alvaro Herrera wrote:
> >> Is it true that a transaction is turned into sync commit as soon as it
> >> writes on a system catalog? Is it desirable to make i
"Tom Lane" <[EMAIL PROTECTED]> writes:
>> If we don't do that then regular users have the ability to put the
>> catalog (and by extension everything else) at risk...
>
> How do you arrive at that conclusion? The point of the async commit
> patch is that transactions might be lost, as in not reall
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> There is an explicit test for whether the transaction has modified
> files; if so the commit is always synchronous, even if explicitly
> requested otherwise. Also, utility commands never perform async commits,
> so overall there aren't that many of the co
On Mon, 2007-23-07 at 23:57 -0700, Neil Conway wrote:
> Attached is a patch implementing RETURN QUERY, per earlier discussion
Applied to HEAD.
-Neil
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.po
Hi Magnus, and Dave.
Sorry, I'm a somewhat late reaction... This is the present correspondence.
However, VC6 does not support SSAPI. Therefore, the next release makes
VC6 the outside of an object.
-- VC6
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp
45 matches
Mail list logo
