Koichi Suzuki wrote:
Pg_readahead is a tool to prefetch data pages before redoing, based on
the contents of archive/active WAL segment. For 8.3 and 8.4 without
sync.rep, this works together with restore_command. Pg_readahead
analyze WAL segment, schedule and issue posix_fadvise() to
Pg_readahead uses posix_fadvise, which is included in Greg's patch and
I've already posted pg_readahead patch integrated into the core.
Integration with snc.rep. will be a separate patch which will be
posted in a couple of days.
2009/1/14 Bruce Momjian br...@momjian.us:
Koichi Suzuki wrote:
On Tue, 2009-01-13 at 13:21 +0900, Koichi Suzuki wrote:
I have no intention to make pglesslog to conflict to PostgreSQL
license. Any advice is welcome to make pglesslog available without
any license concern.
I understand, no part of my comments were against you or your work.
I've a
Koichi Suzuki wrote:
Hi,
I have no intention to make pglesslog to conflict to PostgreSQL
license. Any advice is welcome to make pglesslog available without
any license concern.
I certainly have no concerns.
I've a question and ideas.
Bruce's modification directly points to my
Pg_readahead is a tool to prefetch data pages before redoing, based on
the contents of archive/active WAL segment. For 8.3 and 8.4 without
sync.rep, this works together with restore_command. Pg_readahead
analyze WAL segment, schedule and issue posix_fadvise() to prefetch
data pages quickly
Bruce Momjian wrote:
In thinking about how to communicate to users about reducing continuous
archiving storage requirements, I realized we don't mention pglesslog in
our official documentation.
The attached patch documents how to use pglesslog and gzip/gunzip to
reduce storage requirements.
Hi,
I have no intention to make pglesslog to conflict to PostgreSQL
license. Any advice is welcome to make pglesslog available without
any license concern.
I've a question and ideas.
Bruce's modification directly points to my pgfoundry page. I'm not
sure what it means. Does it mean that I
On Sat, 2009-01-10 at 23:38 -0500, Bruce Momjian wrote:
It is BSD licensed. I don't see any copyright issues:
http://pglesslog.projects.postgresql.org/
A licence and copyright are different things. Why do we insist on
changing copyright on our code if it is unimportant?
--
Simon
On Sun, 2009-01-11 at 03:12 +, Simon Riggs wrote:
On Sat, 2009-01-10 at 21:09 -0500, Bruce Momjian wrote:
Comments?
If this is for backpatching, it makes sense. We should at least wait
until sync rep is accepted or rejected and docs written.
Why? Even if sync rep is accepted,
Simon Riggs wrote:
On Sat, 2009-01-10 at 23:38 -0500, Bruce Momjian wrote:
It is BSD licensed. I don't see any copyright issues:
http://pglesslog.projects.postgresql.org/
A licence and copyright are different things. Why do we insist on
changing copyright on our code if it is
On Sun, 2009-01-11 at 09:47 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Sat, 2009-01-10 at 23:38 -0500, Bruce Momjian wrote:
It is BSD licensed. I don't see any copyright issues:
A licence and copyright are different things. Why do we insist on
changing copyright on our
In general, IMHO, I don't think it's a good direction to go in to
include links to works of other copyright holders.
I think it's a great idea. IMHO, one of the major selling points of
PostgreSQL is its awesome documentation. However, one of its
weaknesses is that contrib module, pgfoundry
In thinking about how to communicate to users about reducing continuous
archiving storage requirements, I realized we don't mention pglesslog in
our official documentation.
The attached patch documents how to use pglesslog and gzip/gunzip to
reduce storage requirements. Comments?
Also, I assume
On Sat, 2009-01-10 at 21:09 -0500, Bruce Momjian wrote:
Comments?
If this is for backpatching, it makes sense. We should at least wait
until sync rep is accepted or rejected and docs written.
In general I don't think we should refer/link to other companies'
copyrighted materials in our
Simon Riggs wrote:
On Sat, 2009-01-10 at 21:09 -0500, Bruce Momjian wrote:
Comments?
If this is for backpatching, it makes sense. We should at least wait
until sync rep is accepted or rejected and docs written.
No, it is not for backpatching.
In general I don't think we should
15 matches
Mail list logo
