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 g
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
Alvaro Herrera wrote:
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.
$
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 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, 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 actual
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 mai
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:
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
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 regressi
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.
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, the
[EMAIL PROTECTED] (Neil Conway) writes:
> On Sun, 2007-13-05 at 22:06 -0400, Tom Lane wrote:
>> This fact is already documented in at least three places; do we really
>> need two more?
>
> I think we need to at least modify the documentation for the autovacuum
> GUC parameter, which currently state
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 a
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 u
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 CVS does not do
> > +by itself, such as letting you create patches without write access,
s/such as letting you create patches/specifically cr
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
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 untouched version of
"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 us
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
> >
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
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.
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 m
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
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 t
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 s
"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. W
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 w
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 para
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
do
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 poss
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 thinkin
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.
"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
"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 alternat
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
"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 everyo
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
Am Montag, 14. Mai 2007 03:56 schrieb David Fetter:
> +For those things which CVS 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/
---(e
39 matches
Mail list logo
