Am Montag, 14. Mai 2007 03:56 schrieb David Fetter:
+For those things which productnameCVS/productname does not do
+by itself, such as letting you create patches without write access,
I don't think that is accurate.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Greg Smith [EMAIL PROTECTED] wrote:
The first patch (buf-alloc-stats) takes the two most interesting pieces of
data the original patch collected, the number of buffers allocated
recently and the number that the clients wrote out, and ties all that into
the new stats structure.
The second
Tom Lane [EMAIL PROTECTED] writes:
David Fetter [EMAIL PROTECTED] writes:
I haven't included the customary diffs. This points me to some of the
many deficiencies of CVS, namely that I would need write access in
order to have it create a diff,
Strange, it works fine for everyone else.
If
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
David Fetter [EMAIL PROTECTED] writes:
I haven't included the customary diffs. This points me to some of the
many deficiencies of CVS, namely that I would need write access in
order to have it create a diff,
Strange, it works fine for
Heikki Linnakangas [EMAIL PROTECTED] writes:
You need write-access to add files, even on anonymouse server. We often get
patches with new files as separate attachments because of that.
Oh quite right. I had forgotten but that was the original reason I switched to
using rsync. The alternative
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
So would you prefer \g as Jim Nasby suggested? I hadn't even considered that
previously since I'm not accustomed to using \g but it does seem kind of
pretty. I normally use ; but I suppose there's nothing wrong with
Heikki Linnakangas wrote:
You need write-access to add files, even on anonymouse server. We
often get patches with new files as separate attachments because of that.
This is the part that cvsutils fakes for you (by hacking the local cvs
metadata files) so you don't need write access.
On Mon, 14 May 2007, ITAGAKI Takahiro wrote:
BTW, your patch will cut LRU writes short, but will not encourage to
do more works. So should set more aggressive values to bgwriter_lru_percent
and bgwriter_lru_maxpages as defaults?
Setting a bigger default maximum is one possibility I was
Greg Smith wrote:
On Mon, 14 May 2007, ITAGAKI Takahiro wrote:
BTW, your patch will cut LRU writes short, but will not encourage to
do more works. So should set more aggressive values to
bgwriter_lru_percent
and bgwriter_lru_maxpages as defaults?
Setting a bigger default maximum is one
On Mon, 14 May 2007, Gregory Stark wrote:
Personally I find CVS so terribly slow for large trees like Postgres that it's
essential to use rsync to maintain a local CVS repository. That makes 'cvs
diff' remarkably fast.
Having recently tried to get this to work right and not quite nailed it
Greg Smith [EMAIL PROTECTED] writes:
Since the whole background writer setup is kind of complicated, the other
thing I was working on is writing a guide on how to use the new
pg_stat_bgwriter information to figure out if you need to increase
bgwriter_[all|lru]_pages (and the other
On Mon, 14 May 2007, Heikki Linnakangas wrote:
If it's safe to set it high, let's default it to infinity.
The maximum right now is 1000, and that would be a reasonable new default.
You really don't to write more than 1000 per interval anyway without
taking a break for checkpoints; the more
Jim C. Nasby [EMAIL PROTECTED] writes:
Would \c# limit us to 9 concurrent connections? Might want
\cs[witch] [session]
Hm, we kind of have a choice with \c#. Either we treat it as part of the
command in which case the way to connect to an integer-named database is to
include a space. We
Gregory Stark [EMAIL PROTECTED] writes:
But these kinds of inconsistent behaviours can be traps for users. It means
\c1 and \c 1 do different things even though \cpostgres and \c postgres
do the same thing. And it means \c1 might connect to a database named 1
today but switch sessions
Did someone come up with a bitmap compression scheme for on-disk bitmap
indexes that would help out here? Some form of compression could make a
big difference in mostly-dead pages. If nothing else, it would likely be
worth special-casing an entire page being dead, which is a common case
for queue
On Mon, May 14, 2007 at 12:51:39PM +0100, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
So would you prefer \g as Jim Nasby suggested? I hadn't even considered
that
previously since I'm not accustomed to using \g but it does seem kind
Jim C. Nasby wrote:
Did someone come up with a bitmap compression scheme for on-disk bitmap
indexes that would help out here? Some form of compression could make a
big difference in mostly-dead pages.
Yes, there's a pretty nice compression scheme there, but the requirement
for random access
Heikki Linnakangas [EMAIL PROTECTED] writes:
Jim C. Nasby wrote:
If nothing else, it would likely be
worth special-casing an entire page being dead, which is a common case
for queue tables. That could be done by making an entry in the page
number array with a special offset value.
That
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Sample output to the client (note: in this test, MAX_REPORTED_DEPS is
set to 10).
...
foo=# drop user foo;
ERROR: role foo cannot be dropped because some objects depend on it
DETAIL: owner of tablespace foo
owner of table
On Mon, May 14, 2007 at 11:03:52AM -0400, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
But these kinds of inconsistent behaviours can be traps for users. It means
\c1 and \c 1 do different things even though \cpostgres and \c
postgres
do the same thing. And it means \c1 might
Jim C. Nasby [EMAIL PROTECTED] writes:
Since this command will be getting used very frequently by anyone using
concurrent connections interactively, it'd be nice if it was lower-case.
It looks like that limits us to j, k, m, n, v, and y. In unix this idea
is about jobs, what about using \j?
On Mon, May 14, 2007 at 06:26:42PM +0100, Gregory Stark wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Since this command will be getting used very frequently by anyone using
concurrent connections interactively, it'd be nice if it was lower-case.
It looks like that limits us to j, k, m,
On May 14, 12:57 am, [EMAIL PROTECTED] (Peter Eisentraut) wrote:
Am Montag, 14. Mai 2007 03:56 schrieb David Fetter:
+For those things which productnameCVS/productname does not do
+by itself, such as letting you create patches without write access,
s/such as letting you create
David Fetter wrote:
On Mon, May 14, 2007 at 03:31:40PM +1200, Mark Kirkwood wrote:
David Fetter wrote:
cvs diff works just great until you want to add or remove a file
without write permissions to the CVS repository, i.e. when you've
checked out as anonymous.
I usually saved an
David Fetter wrote:
On Sun, May 13, 2007 at 10:06:40PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
Per Neil Conway, here's some doc patches re: the autovacuum
daemon's behavior. Should this be back-patched to 8.2x?
This fact is already documented in at least three
Chris Browne wrote:
Would the following 'maintenance' regimen be truly safe against XID
wraparound:
- Most tables are being vacuumed regularly, so that
pg_class.relfrozenxid is kept safe.
- There are some tables that periodically get TRUNCATEd so that, in
principle, they never
Alvaro Herrera [EMAIL PROTECTED] writes:
I suppose it would be pretty trivial to set the relfrozenxid to
RecentXmin or something during TRUNCATE.
I had the idea we were doing that already --- at least I'm pretty sure I
remember it being discussed. But I see it's not being done in HEAD.
Right. I will send an updated patch against the CVS head in the next
couple of days.
Jaime Casanova wrote:
On 4/4/07, FAST PostgreSQL [EMAIL PROTECTED] wrote:
Attached is a working updateable cursors patch. The core functionality
has
been implemented and the patch also contains the
Alvaro Herrera wrote:
David Fetter wrote:
On Mon, May 14, 2007 at 03:31:40PM +1200, Mark Kirkwood wrote:
David Fetter wrote:
cvs diff works just great until you want to add or remove a file
without write permissions to the CVS repository, i.e. when you've
checked out as anonymous.
I usually
URL added to TODO item.
---
Zoltan Boszormenyi wrote:
Forwarded to -patches because of the attachment.
Eredeti ?zenet
T?rgy:Re: [HACKERS] Behavior of GENERATED columns per SQL2003
D?tum:
Mark Kirkwood wrote:
Alvaro Herrera wrote:
Except that it also includes diffs for generated files, which tend to be
huge. To work around that you need to create a list of files to
exclude, and the whole thing (which was cumbersome already) starts to
get unmanageable.
$ make
On Mon, 2007-14-05 at 16:22 -0400, Bruce Momjian wrote:
I agree with Tom. I don't think the current behavior is a major issue
for users for it to be mentioned more than it already is
Are you really suggesting that we shouldn't modify config.sgml to note
that autovacuum = off does not actually
On Fri, 2007-27-04 at 18:59 -0400, Neil Conway wrote:
This patch needs more work.
Has a revised version of this patch been submitted?
-Neil
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Mon, 14 May 2007, Tom Lane wrote:
If you can write something like that, why do we need the parameter at all?
Couple of reasons:
-As I already mentioned in my last message, I think it's unwise to let the
LRU writes go completely unbounded. I still think there should be a
maximum, and if
On Mon, May 14, 2007 at 11:55:07AM -0500, Jim C. Nasby wrote:
On Mon, May 14, 2007 at 11:03:52AM -0400, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
But these kinds of inconsistent behaviours can be traps for users. It
means
\c1 and \c 1 do different things even though
On Mon, May 14, 2007 at 11:19:23PM -0400, Greg Smith wrote:
On Mon, 14 May 2007, Tom Lane wrote:
If you can write something like that, why do we need the parameter at all?
Couple of reasons:
-As I already mentioned in my last message, I think it's unwise to let the
LRU writes go
36 matches
Mail list logo
