Attached is a patch implementing RETURN QUERY, per earlier discussion,
and based on a patch from Pavel Stehule. Like RETURN NEXT, RETURN QUERY
doesn't immediately return from the function, allowing RETURN NEXT and
RETURN QUERY to be intermixed in a single function.
Barring any objections, I'll
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 still needs
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? Hey, be
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.
Cool
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 some
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 looked
+para
+ Asynchronous commit provides different behaviour to setting
+ varnamefsync/varname = off, which is a server-wide
+ setting that will alter the behaviour of all transactions,
+ overriding the setting of varnamesynchronous_commit/varname,
+ as well as risking much
On Tue, 2007-07-24 at 10:51 +0200, Florian Weimer wrote:
+para
+ Asynchronous commit provides different behaviour to setting
+ varnamefsync/varname = off, which is a server-wide
+ setting that will alter the behaviour of all transactions,
+ overriding the setting of
* 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 wanting to
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=vaquitadt=2007-07-23%20200011stg=make)
Attached patch removes this by disabling the warning specifically for
plperl
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=vaquitadt=2007-07-23%20200011stg=make)
Huh, what's actually in your
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
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 generate the
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=vaquitadt=2007-07-23%20200011stg=make)
Attached patch removes this by disabling the
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 it
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 that the
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
endif
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
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 contains /* within comment
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.
Sure: the
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
backend do the
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 they not get
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
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, if it
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 underlying issue?
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
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
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.
---
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 other
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 ... any useful warning
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 useless.
+1 ... any
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 a
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 ability to
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 it so?
If
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 really
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 commonly
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?
40 matches
Mail list logo
