Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Greg Smith wrote:
On Wed, 23 Jul 2008, Kevin Grittner wrote:
I've been working on an improved archive_command shell script that I
expect to submit for comments and potential inclusion in the
documentation as a better base for other people to
Andrew Dunstan wrote:
Greg Smith wrote:
On Wed, 23 Jul 2008, Kevin Grittner wrote:
In our scripts we handle this by copying to a temp directory on the
same mount point as the archive directory and doing a mv to the
archive location when the copy is successfully completed. I think
that this
Andrew Dunstan wrote:
Kevin Grittner wrote:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
We really need a more reliable way of detecting that a file has been
fully copied.
In our scripts we handle this by copying to a temp directory on the
same mount point as the archive
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
- or maybe provide a .bat file or perl script that would work as na
archive_command on Windows.
We're not talking about archive_command. We're talking about the thing
that copies files to the directory that pg_standby polls.
Er, that's
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
- or maybe provide a .bat file or perl script that would work as na
archive_command on Windows.
We're not talking about archive_command. We're talking about the thing
that copies files to the directory that pg_standby
On Wed, 23 Jul 2008, Kevin Grittner wrote:
In our scripts we handle this by copying to a temp directory on the
same mount point as the archive directory and doing a mv to the
archive location when the copy is successfully completed. I think
that this even works on Windows. Could that just be
Greg Smith wrote:
On Wed, 23 Jul 2008, Kevin Grittner wrote:
In our scripts we handle this by copying to a temp directory on the
same mount point as the archive directory and doing a mv to the
archive location when the copy is successfully completed. I think
that this even works on Windows.
On Fri, 2008-07-25 at 16:31 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 17:19 -0700, Martin Zaun wrote:
reviewing your patch
Current status is this:
* My understanding is that Dave and Andrew (and therefore Simon) think
the approach proposed
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-07-25 at 16:31 -0400, Tom Lane wrote:
I thought the latest conclusion was that changing the behavior of
pg_standby itself wouldn't address the problem anyway, and that what we
need is just a docs patch recommending that people use safe copying
On Fri, 2008-07-25 at 16:58 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-07-25 at 16:31 -0400, Tom Lane wrote:
I thought the latest conclusion was that changing the behavior of
pg_standby itself wouldn't address the problem anyway, and that what we
need is
maxwaittime = 0;/* how long are we prepared to wait for? */
As you say, unrelated to the patch.
7. Question: benefits of separate holdtime option from sleeptime?
Simon Riggs wrote:
* provide holdtime delay, default 0 (on all platforms)
Going back on the hackers+patches emails
Simon Riggs wrote:
On Tue, 2008-07-22 at 17:19 -0700, Martin Zaun wrote:
8. Unresolved question of implementing now/later a cp replacement
The patch implements what's been agreed.
I'm not rewriting cp, for reasons already discussed.
Not a comment to you Martin, but it's fairly clear that
Heikki Linnakangas [EMAIL PROTECTED] wrote:
We really need a more reliable way of detecting that a file has been
fully copied.
In our scripts we handle this by copying to a temp directory on the
same mount point as the archive directory and doing a mv to the
archive location when the
Kevin Grittner wrote:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
We really need a more reliable way of detecting that a file has been
fully copied.
In our scripts we handle this by copying to a temp directory on the
same mount point as the archive directory
On Wed, 2008-07-23 at 21:38 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Tue, 2008-07-22 at 17:19 -0700, Martin Zaun wrote:
8. Unresolved question of implementing now/later a cp replacement
The patch implements what's been agreed.
I'm not rewriting cp, for reasons
This crashes the backend:
WITH RECURSIVE t(n) AS (
VALUES (1)
UNION ALL
SELECT n+1 FROM t WHERE n 5 ORDER BY 1
)
SELECT n FROM t;
apparently because of the ORDER BY 1
Thanks for the report. I think ORDER BY in this case is useless
anyway. ORDER BY affects (VALUES (1) UNION
Tatsuo Ishii [EMAIL PROTECTED] writes:
Thus I think we should avoid this kind of ORDER BY. Probably we should
avoid LIMIT/OFFSET and FOR UPDATE as well.
What of index-optimized SELECT max(...) ?
regards, tom lane
--
Sent via pgsql-patches mailing list
Thus I think we should avoid this kind of ORDER BY. Probably we should
avoid LIMIT/OFFSET and FOR UPDATE as well.
What of index-optimized SELECT max(...) ?
Aggregate functions in a recursive term is prohibited by the
standard. For example,
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL
On Mon, Jul 21, 2008 at 08:19:35AM +0900, Tatsuo Ishii wrote:
Thus I think we should avoid this kind of ORDER BY. Probably we should
avoid LIMIT/OFFSET and FOR UPDATE as well.
What of index-optimized SELECT max(...) ?
Aggregate functions in a recursive term is prohibited by the
On Mon, Jul 21, 2008 at 08:19:35AM +0900, Tatsuo Ishii wrote:
Thus I think we should avoid this kind of ORDER BY. Probably we should
avoid LIMIT/OFFSET and FOR UPDATE as well.
What of index-optimized SELECT max(...) ?
Aggregate functions in a recursive term is prohibited by
On Fri, July 18, 2008 03:41, Tatsuo Ishii wrote:
Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
I tried this patch vs. CVS HEAD used my usual configure option with
only --with-prefix set, then tried to make, and
Updated: http://www.sigaev.ru/misc/fast_insert_gin-0.9.gz
need more review of fast_insert yet? It looked like a number of people
commented on it already.
I still havn't clearness of acceptability for suggested aminsertcleanup
calling.
--
Teodor Sigaev
I've committed the multicolumn one with minor revisions (fix some poor
English in docs and comments, add regression-test coverage). Do you
Thank you very much.
need more review of fast_insert yet? It looked like a number of people
commented on it already.
I should modify it to
On Tue, 2008-07-08 at 14:51 -0400, Tom Lane wrote:
I'd still like to take a look.
I was tasked with reviewing this for the current commit fest, although
so far I've just been working on grokking the rest of the GIN code. But
if you'd like to review it instead, that's fine with me.
-Neil
--
Neil,
I was tasked with reviewing this for the current commit fest, although
so far I've just been working on grokking the rest of the GIN code. But
if you'd like to review it instead, that's fine with me.
I have plenty of other stuff I could assign you if you're not needed on
GIN.
--
I looked this over and it looks good in general.
May I think that patch passed review and commit it?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list
Teodor Sigaev [EMAIL PROTECTED] writes:
I looked this over and it looks good in general.
May I think that patch passed review and commit it?
I'd still like to take a look.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Freitag, 4. Juli 2008 schrieb Tom Raney:
Regarding the XML datum, in order to support that, will all users need
to compile with libxml? Are there any lighter weight solutions to
serialize other than libxml?
You can create XML without libxml.
Tom,
I think this patch is plenty complicated enough without adding useless
restrictive options.
+1 for no additonal GUC options.
--Josh Berkus
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Couldn't we just have it pay attention to the existing
max_stack_depth?
Recursive query does not consume stack. The server enters an infinite
loop without consuming stack. Stack-depth error does not happen.
Hans-Juergen Schoenig wrote:
Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
i don't think statement_timeout is a good idea at all.
it is not deterministic. depending on the load on the server some
queries will execute while others fail.
a separate GUC is needed.
I
[ catching up on back email ]
Gregory Stark [EMAIL PROTECTED] writes:
Yoshiyuki Asaba [EMAIL PROTECTED] writes:
Recursive query does not consume stack. The server enters an infinite
loop without consuming stack. Stack-depth error does not happen.
We could have a separate guc variable which
On Sat, May 24, 2008 at 05:01:11AM +0900, Yoshiyuki Asaba wrote:
Hi,
From: David Fetter [EMAIL PROTECTED]
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Fri, 23 May 2008 11:26:30 -0700
Where is the new patch?
I will create the revised patch on June. This is a patch for this
Hi,
From: David Fetter [EMAIL PROTECTED]
Subject: Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
Date: Mon, 19 May 2008 04:36:30 -0700
I think it's the other way around. The server should not emit
infinite number of records.
How about adding new GUC parameter max_recursive_call
Couldn't we just have it pay attention to the existing
max_stack_depth?
Recursive query does not consume stack. The server enters an infinite
loop without consuming stack. Stack-depth error does not happen.
We could have a separate guc variable which limits the maximum number of
Joshua D. Drake [EMAIL PROTECTED] writes:
Couldn't we just have it pay attention to the existing
max_stack_depth?
Recursive query does not consume stack. The server enters an infinite
loop without consuming stack. Stack-depth error does not happen.
We could have a separate guc
Merlin Moncure wrote:
On Sun, May 18, 2008 at 5:22 PM, Zoltan Boszormenyi [EMAIL PROTECTED] wrote:
Can we get the rows in tree order, please? I.e. something like this:
Is ordering by tree order defined in the standard when no explicit
order is given? If not, it probably returns them
Bruce Momjian [EMAIL PROTECTED] writes:
Guillaume Smet wrote:
I understand your point of view but I really think it's more a
regression fix than a behavior change.
If I can get other hackers to say we should backpatch we can consider
it.
Well, 8.3 is already different from 8.2, and a lot of
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Guillaume Smet wrote:
I understand your point of view but I really think it's more a
regression fix than a behavior change.
If I can get other hackers to say we should backpatch we can consider
it.
Well, 8.3 is already
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, 8.3 is already different from 8.2, and a lot of people will see
this particular aspect of it as a regression. I'm okay with
backpatching to 8.3 ... though the patch needed rather more testing
than you gave it.
OK, so Alvaro and
Heikki Linnakangas [EMAIL PROTECTED] writes:
Simon Riggs wrote:
* We've said here http://www.postgresql.org/docs/faqs.TODO.html that we
Don't want hints. If that's what we really think, then this patch must
surely be rejected because its a hint... That isn't my view. I *now*
think we do need
On Fri, 2008-05-02 at 12:01 -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Simon Riggs wrote:
* We've said here http://www.postgresql.org/docs/faqs.TODO.html that we
Don't want hints. If that's what we really think, then this patch must
surely be rejected because its
On Fri, 2008-05-02 at 12:01 -0400, Tom Lane wrote:
I see this as being basically another cost parameter, and as such
I don't think it needs more documentation than any of those have.
(Now admittedly you could argue that they could all use a ton more
documentation than they now have, but it's
; pgsql-patches@postgresql.org;
[EMAIL PROTECTED]
Subject: Re: [HACKERS] [PATCHES] GUC parameter cursors_tuple_fraction
Simon Riggs [EMAIL PROTECTED] writes:
OK, if that's the view then the patch is ready for commit, AFAICS.
Use of the plural in the name seems a bit odd to me. Anyone have a
problem
On Fri, 2008-05-02 at 16:36 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
OK, if that's the view then the patch is ready for commit, AFAICS.
Use of the plural in the name seems a bit odd to me. Anyone have a
problem with calling it cursor_tuple_fraction instead?
Agreed.
--
Hell, Robert [EMAIL PROTECTED] writes:
You're right - that's just a typo in the subject of the post.
It's called cursor_tuple_fraction in the submitted patch.
Ah, I hadn't actually read the patch yet ;-). As penance for the noise,
I will do so now.
regards, tom lane
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Brendan Jurd escribi�:
Here's my attempt to remove the typename field from A_Const. There
were a few places (notably flatten_set_variable_args() in guc.c, and
typenameTypeMod() in parse_type.c) where the code expected to see an
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
They're logically different things, and after I get done putting a parse
location field into A_Const, they'll still be physically different too.
Aha. Are you working from Brendan's patch? I was going to commit it.
Sure, go ahead.
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
They're logically different things, and after I get done putting a parse
location field into A_Const, they'll still be physically different too.
Aha. Are you working from Brendan's patch? I was going to
Alvaro Herrera escribió:
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
They're logically different things, and after I get done putting a parse
location field into A_Const, they'll still be physically different too.
Aha. Are you working from
Alvaro Herrera [EMAIL PROTECTED] writes:
I came up with the attached patch.
I wasn't envisioning anything anywhere near this invasive. We only
need locations on constants in a few contexts, I think.
BTW, you broke _equalAConst() ... it was a bad idea anyway to recast
it on the assumption that
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
I came up with the attached patch.
I wasn't envisioning anything anywhere near this invasive. We only
need locations on constants in a few contexts, I think.
Aha. OK, I'll commit the original patch and let you deal with the rest
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, I'm now wondering if the location should be added to Value as well,
so that it can be passed down to Const?
Just for the record, we don't want it in Const. Parse locations are
only useful in the raw grammar output, mainly because they aren't
Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Feb 23, 2008 at 01:13:38PM +0100, Mathias Hasselmann wrote:
[...]
Avahi/Bonjour/DNS-SD support[1] is very important, for integrating
Postgresql with modern
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 01, 2008 at 09:35:56AM +0200, Mathias Hasselmann wrote:
Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]:
[...]
Sorry for a dumb question, but I couldn't figure that out from your
references [1]..[4]: does that mean
Am Dienstag, den 01.04.2008, 12:02 + schrieb [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 01, 2008 at 09:35:56AM +0200, Mathias Hasselmann wrote:
Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]:
[...]
Sorry for a dumb question, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 01, 2008 at 05:07:31PM +0200, Mathias Hasselmann wrote:
[...]
Personally, I'be rather scared than delighted ;-)
So in data centers you don't even trust the machines in your broadcast
domain?
Kind of. Put it another way: never have
On Tue, 2008-04-01 at 15:34 +, [EMAIL PROTECTED] wrote:
I would really prefer a more loosely coupled system.
The functionality will be much the same. The implementation would be
more difficult and obscure and there would be more points of failure and
more things to configure, but it wouldn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Feb 23, 2008 at 01:13:38PM +0100, Mathias Hasselmann wrote:
[...]
Avahi/Bonjour/DNS-SD support[1] is very important, for integrating
Postgresql with modern desktop environments like OSX, GNOME, KDE: It's
very convenient to choose active
Zdenek Kotala wrote:
But how it was mentioned in this thread maybe
somethink like this CREATE TABLESPACE name LOCATION '/my/location'
SEGMENTS 10GB should good solution. If segments is not mentioned then
default value is used.
I think you would need a tool to resegmentize a table or
On Wed, Mar 19, 2008 at 09:38:12AM +0100, Peter Eisentraut wrote:
Another factor I just thought of is that tar, commonly used as part of a
backup procedure, can on some systems only handle files up to 8 GB in size.
There are supposed to be newer formats that can avoid that restriction, but
On Wed, Mar 19, 2008 at 10:51:12AM +0100, Martijn van Oosterhout wrote:
On Wed, Mar 19, 2008 at 09:38:12AM +0100, Peter Eisentraut wrote:
Another factor I just thought of is that tar, commonly used as part of a
backup procedure, can on some systems only handle files up to 8 GB in size.
Tom Lane wrote:
I think this needs to be treated as experimental until it's got a few
more than zero miles under its belt.
OK, then maybe we should document that.
I wouldn't be too surprised to
find that we have to implement it as a run-time switch instead of
compile-time, in order to not
Why is this not the default when supported? I am wondering both
from the
point of view of the user, and in terms of development direction.
Also it would get more buildfarm coverage if it were default. If it
breaks something we'll notice earlier.
No we don't, because the buildfarm does
On Mon, 10 Mar 2008, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Applied with minor corrections.
Why is this not the default when supported?
Fear.
Maybe eventually, but right now I think it's too risky.
One point that I already found out the hard way is
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think this needs to be treated as experimental until it's got a few
more than zero miles under its belt.
OK, then maybe we should document that.
Agreed, but at this point we don't even know what hazards we need to
document.
Zeugswetter Andreas OSB SD [EMAIL PROTECTED] writes:
Exactly, e.g. AIX is one of those. jfs (not the newer jfs2) has an
option
to enable large files, which is not the default and cannot be changed
post crfs.
And even if it is enabled, jfs has a 64 Gb filesize limit !
Anybody know others that
Tom Lane napsal(a):
Zeugswetter Andreas OSB SD [EMAIL PROTECTED] writes:
Exactly, e.g. AIX is one of those. jfs (not the newer jfs2) has an
option
to enable large files, which is not the default and cannot be changed
post crfs.
And even if it is enabled, jfs has a 64 Gb filesize limit !
Anybody
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
These examples suggest that maybe what we want is not so much a no
segments ever mode as a segment size larger than 1GB.
PS: ZFS is happy with 2^64bit size and UFS has 1TB file size limit
(depends on solaris version)
So even on
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
These examples suggest that maybe what we want is not so much a no
segments ever mode as a segment size larger than 1GB.
PS: ZFS is happy with 2^64bit size and UFS has 1TB file size limit
(depends on solaris
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
These examples suggest that maybe what we want is not so much a no
segments ever mode as a segment size larger than 1GB.
PS: ZFS is happy with 2^64bit size and UFS has 1TB file size limit
(depends on solaris
Zdenek Kotala [EMAIL PROTECTED] writes:
I think current patch could stay in CVS and I will rip out non segment
code path in a new patch.
Sure, I feel no need to revert what's applied. Have at it.
regards, tom lane
--
Sent via pgsql-patches mailing list
Zdenek Kotala wrote:
Yes, agree. It seems only ZFS is OK at this moment and if somebody sets
32TB he gets nonsegment mode anyway.
Surely if you set the segment size to INT64_MAX, you will get nonsegmented
behavior anyway, so two code paths might not be necessary at all.
I looked into posix
Peter Eisentraut [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
Maybe we can put additional test into configure and collect appropriate
data from buildfarm.
It might be good to just check first if it returns realistic values for the
example cases that have been mentioned.
Yeah, please just
Zdenek Kotala [EMAIL PROTECTED] writes:
There is latest version of nonsegment support patch. I changed
LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
-disable-segmented-files switch to configure. I kept tuplestore behavior
and it still split file in both mode.
Applied with minor
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
There is latest version of nonsegment support patch. I changed
LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
-disable-segmented-files switch to configure. I kept tuplestore behavior
and it still split file in both mode.
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Applied with minor corrections.
Why is this not the default when supported?
Fear.
Maybe eventually, but right now I think it's too risky.
One point that I already found out the hard way is that sizeof(off_t) = 8
does not guarantee
Peter Eisentraut wrote:
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
There is latest version of nonsegment support patch. I changed
LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
-disable-segmented-files switch to configure. I kept tuplestore behavior
and it
Alvaro Herrera [EMAIL PROTECTED] writes:
Also it would get more buildfarm coverage if it were default. If it
breaks something we'll notice earlier.
Since nothing the regression tests do even approach 1GB, the odds that
the buildfarm will notice problems are approximately zero.
: [HACKERS] [PATCHES] 2WRS [WIP]
For the joy of all of you: that's the correct WIP patch.
At the moment it only tries to create runs uding two heaps. Hope you can
help me with writing those runs on tapes.
I'd be very pleased to give you more details.
Thenks for your time.
Regards, Manolo
.
--
From: Jaime Casanova [EMAIL PROTECTED]
Sent: Friday, February 22, 2008 5:30 AM
To: [EMAIL PROTECTED]
Cc: Decibel! [EMAIL PROTECTED]; Manolo _ [EMAIL PROTECTED];
David Fetter [EMAIL PROTECTED]; pgsql-patches@postgresql.org;
[EMAIL PROTECTED]
Subject: Re: [HACKERS] [PATCHES] 2WRS
.
--
From: Jaime Casanova [EMAIL PROTECTED]
Sent: Friday, February 22, 2008 5:30 AM
To: [EMAIL PROTECTED]
Cc: Decibel! [EMAIL PROTECTED]; Manolo _ [EMAIL PROTECTED];
David Fetter [EMAIL PROTECTED]; pgsql-patches@postgresql.org;
[EMAIL PROTECTED]
Subject: Re: [HACKERS] [PATCHES] 2WRS
Mathias Hasselmann wrote:
The patches were in my initial mail, but now I've also uploaded them to
my personal site for convenience:
http://taschenorakel.de/files/pgsql-avahi-support/
Hmm, a quick look at the third patch reveals that it is using the
threaded Avahi client. That's a
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Well if we are going to continue to support money (which I am against)
we should support the casting to numeric as that is by far a more
common implementation of money and we will have mixed environments.
So, you don't use MONEY,
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
Can you make 0 and -1 both valid disabled values? That way it will be
compatible with previous releases.
Heh, sure, we can do that too and it doesn't seem like anybody would
object. I will patch the documentation so that that the
Alvaro Herrera [EMAIL PROTECTED] writes:
Matthew T. O'Connor wrote:
Can you make 0 and -1 both valid disabled values? That way it will be
compatible with previous releases.
Heh, sure, we can do that too and it doesn't seem like anybody would
object. I will patch the documentation so that
Matthew T. O'Connor wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
But this is misleading (started postmaster with good value, then edited
postgresql.conf and entered -2):
17903 LOG: received SIGHUP, reloading configuration files
17903 LOG: -2 is
XML is now more stabilized in the backend than when the patch appeared,
and it doesn't make sense to add features to a /contrib interface that
is to be used only for backward compatability.
Patch rejected. You can put the patch on pgfoundry if you are worried
others might need this
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
My first thought is that the cycle_ctr just adds extra complexity. The
canceled-flag really is the key in Takahiro-san's patch, so we don't
need the cycle_ctr anymore.
We don't have to have it in the sense of the code not working
Heikki Linnakangas [EMAIL PROTECTED] writes:
I believe Itagaki-san's motivation for tackling this in the LDC patch
was the fact that it can fsync the same file many times, and in the
worst case go to an endless loop, and adding delays inside the loop
makes it much more likely. After that is
Tom Lane wrote:
I wrote:
Actually, on second look I think the key idea here is Takahiro-san's
introduction of a cancellation flag in the hashtable entries, to
replace the cases where AbsorbFsyncRequests can try to delete entries.
What that means is mdsync() doesn't need an outer retry loop at
Heikki Linnakangas [EMAIL PROTECTED] writes:
My first thought is that the cycle_ctr just adds extra complexity. The
canceled-flag really is the key in Takahiro-san's patch, so we don't
need the cycle_ctr anymore.
We don't have to have it in the sense of the code not working without it,
but
I wrote:
This patch looks fairly sane to me; I have a few small gripes about
coding style but that can be fixed while applying. Heikki, you were
concerned about the cycle-ID idea; do you have any objection to this
patch?
Actually, on second look I think the key idea here is Takahiro-san's
I wrote:
Actually, on second look I think the key idea here is Takahiro-san's
introduction of a cancellation flag in the hashtable entries, to
replace the cases where AbsorbFsyncRequests can try to delete entries.
What that means is mdsync() doesn't need an outer retry loop at all:
I fooled
I wrote:
I fooled around with this idea and came up with the attached patch.
It seems to do what's intended but could do with more eyeballs and
testing before committing. Comments please?
Earlier I said that I didn't want to back-patch this change, but on
looking at the CVS history I'm
On 4/6/07, Tatsuo Ishii [EMAIL PROTECTED] wrote:
BTW, is anybody working on enabling the fill factor to the tables used
by pgbench? 8.3 will introduce HOT, and I think adding the feature
will make it easier to test HOT.
Please see if the attached patch looks good. It adds a new -F option
Patch committed. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
On 4/6/07, Tatsuo Ishii [EMAIL PROTECTED] wrote:
BTW, is anybody working on enabling the fill factor to the tables used
by pgbench? 8.3 will introduce HOT, and I think adding the feature
will make it easier to test HOT.
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.
---
Applying newest version of this patch now; still needs documentation.
---
Nikolay Samokhvalov wrote:
On 3/5/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
On 3/4/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
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.
I was hoping that we're deprecating contrib/xml2, so I
1 - 100 of 660 matches
Mail list logo
