2009/9/30 Pavel Stehule :
> So I dropped variadic functions from mixed/named notation and little
> bit modified documentation. Please, can some native English speaker
> look on documentation?
>
Hi Pavel,
I've had a look through the documentation and cleaned up a few things.
I changed the chapter
Peter Eisentraut wrote:
> On Fri, 2009-07-17 at 13:58 +0100, Richard Huxton wrote:
>> 2. Titles on navigation links.
>> Run ./STYLING/title_links.pl and it should add title attributes to the
>> navigation links. This means hovering over the top links gives the title
>> of the page they will go to
David E. Wheeler wrote:
> On Sep 29, 2009, at 8:55 AM, Richard Huxton wrote:
>
>> For the browser, does the following match what you're after, Andrew?
>> - clicking chapter title opens the browser panel
>> - panel stays open until you click close icon
>> - panel contains collapsable tree of chapte
Hi,
Tom Lane writes:
> Peter Eisentraut writes:
>> On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
>>> (Note that you would still need a non-default setting of
>>> listen_addresses for "-h machine_name" to actually work.)
>
>> Which makes this proposal kind of uninteresting.
As already said,
At 2009-09-30 22:08:12 -0400, t...@sss.pgh.pa.us wrote:
>
> # local connections via TCP/IP:
> hostall all samehost @authmethod@
I think that's an excellent idea.
On the other hand, I tend to be slightly against the idea of changing
the default listen_addresses fro
I'd like to propose adding a new GUC to limit the amount of memory a backend
can allocate for its own use. The problem this addresses is that sometimes
one needs to set work_mem fairly high to get good query plans for large joins.
However, some complex queries will then use huge amounts of memory
+ /*
+* If our initial RunningXactData had an overflowed snapshot then we
+* knew we were missing some subxids from our snapshot. We can use
+* this data as an initial snapshot, but we cannot yet mark it valid.
+* We know that the missing subxids are equal to or earlier than
+
On Thu, Oct 1, 2009 at 04:11, Itagaki Takahiro
wrote:
>
> Magnus Hagander wrote:
>
>> I can certainly review the win32 encoding patch, but I was rather
>> hoping for some comments from others on if we're interested in a win32
>> only solution, or if we want something more generic. Should we just
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
> just my 2 cents. but i always wondered about the existence of
> listen_addresses at all... to me the only reason it exists is to force
> me to change 'localhost' to '*' after installing, something i always
> do almost automaticaly =)
Try run
On Wed, Sep 30, 2009 at 12:34:23PM -0400, Tom Lane wrote:
> qualified to review them. (I don't actually think we have anybody
> except Michael who's really familiar with ecpg.)
I'm afraid I'm simply not able to spend much time on this in the near future as
I'm simply too busy atm. I spend some ti
Stephen Frost wrote:
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
just my 2 cents. but i always wondered about the existence of
listen_addresses at all... to me the only reason it exists is to force
me to change 'localhost' to '*' after installing, something i always
do almost aut
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module "would not hurt".
So here's the patch.
I don't think there is documentation required;
correct me if I am
On Thu, Oct 1, 2009 at 1:53 PM, Albe Laurenz wrote:
> In the discussion following
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
> the consensus was that a hook that allows you to implement
> a password checking routine as a module "would not hurt".
>
> So here's the patch.
>
Dave Page wrote:
On Thu, Oct 1, 2009 at 1:53 PM, Albe Laurenz wrote:
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module "would not hurt".
So here's
Andrew Dunstan wrote:
>>> So here's the patch.
>>> I don't think there is documentation required;
>>> correct me if I am wrong.
>>
>> How will people know how to use it, or that it's even there without at
>> least a note in the docs somewhere?
>
> I'd prefer to have an example as a contrib module,
Michael Meskes írta:
> On Wed, Sep 30, 2009 at 12:34:23PM -0400, Tom Lane wrote:
>
>> qualified to review them. (I don't actually think we have anybody
>> except Michael who's really familiar with ecpg.)
>>
>
> I'm afraid I'm simply not able to spend much time on this in the near future
>
Tom Lane wrote:
> Now that the samehost/samenet patch is in, I wonder if it wouldn't be
> a good idea to replace this part of the default pg_hba.conf file:
You're probably not suggesting this, but I would be against a default
setting of 'samehost' used with 'trust'.
Essentially that would be the
Tom Lane wrote:
> Having looked at the code, I think that samehost is pretty safe. I'm
> still worried about samenet picking up a bogusly broad netmask --- but
> samehost hard-wires the netmask at all-ones. Even if your network
> configuration is really screwed up, the kernel isn't going to send
On Thu, Oct 1, 2009 at 15:26, Albe Laurenz wrote:
> Andrew Dunstan wrote:
So here's the patch.
I don't think there is documentation required;
correct me if I am wrong.
>>>
>>> How will people know how to use it, or that it's even there without at
>>> least a note in the docs somewhe
On Wed, 2009-09-30 at 18:45 +0300, Heikki Linnakangas wrote:
> Regarding this in InitStandbyDelayTimers:
> + /*
> +* If replication delay is enormously huge, just treat that as
> +* zero and work up from there. This prevents us from acting
> +* foolishly when replaying old log files.
On Thu, Oct 01, 2009 at 03:54:37PM +0200, Magnus Hagander wrote:
> On Thu, Oct 1, 2009 at 15:26, Albe Laurenz wrote:
> > Andrew Dunstan wrote:
> So here's the patch.
> I don't think there is documentation required;
> correct me if I am wrong.
> >>>
> >>> How will people know how to
* Albe Laurenz [091001 08:54]:
> In the discussion following
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
> the consensus was that a hook that allows you to implement
> a password checking routine as a module "would not hurt".
>
> So here's the patch.
> I don't think there
2009/10/1 Brendan Jurd :
> 2009/9/30 Pavel Stehule :
>> So I dropped variadic functions from mixed/named notation and little
>> bit modified documentation. Please, can some native English speaker
>> look on documentation?
>>
>
> Hi Pavel,
>
> I've had a look through the documentation and cleaned up
On Sun, 2009-09-27 at 15:35 +0300, Heikki Linnakangas wrote:
> TransactionIdIsInProgress() doesn't consult the known-assigned-xids
> structure. That's a problem: in the standby, TransactionIdIsInProgress()
> can return false for a transaction that is still running in the master.
> HeapTupleSatisfi
Jaime Casanova wrote:
> Tom Lane wrote:
>>
>> Although come to think of it ... is there any reason besides sheer
>> conservatism to not make the default listen_addresses value '*'?
>
> just my 2 cents. but i always wondered about the existence of
> listen_addresses at all... to me the only reaso
On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote:
Why wouldn't the entire TOC be in a collapsed list?
Permanently on-screen? My only concern there would be for people
viewing
on phones etc.
I have to admit that I'm never looking at the Pg docs on my iPhone.
This is mainly because I use
David E. Wheeler wrote:
> On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote:
>
>>> Why wouldn't the entire TOC be in a collapsed list?
>>
>> Permanently on-screen? My only concern there would be for people viewing
>> on phones etc.
>
> I have to admit that I'm never looking at the Pg docs on my iP
On 10/01/2009 10:24 AM, Kevin Grittner wrote:
Trust authentication has a few valid use cases, but it does tend to
worry me that people may leave it enabled in inappropriate situations
on production clusters. I don't see how we could get rid of it, but
I'd be OK with a warning in the log when a p
On Thu, 2009-10-01 at 14:29 +0300, Heikki Linnakangas wrote:
> + /*
> +* If our initial RunningXactData had an overflowed snapshot then we
> +* knew we were missing some subxids from our snapshot. We can use
> +* this data as an initial snapshot, but we cannot yet mark it valid.
> +
daveg writes:
> I'd like to propose adding a new GUC to limit the amount of memory a backend
> can allocate for its own use.
Use ulimit.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On Wed, 2009-09-30 at 09:33 +0300, Heikki Linnakangas wrote:
> Looking at the changes to StartupMultiXact, you're changing the locking
> so that both MultiXactOffsetControlLock and MultiXactMemberControlLock
> are acquire first before changing anything. Why? Looking at the other
> functions in th
On Thu, Oct 1, 2009 at 10:24 AM, David E. Wheeler wrote:
> On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote:
>
>>> Why wouldn't the entire TOC be in a collapsed list?
>>
>> Permanently on-screen? My only concern there would be for people viewing
>> on phones etc.
>
> I have to admit that I'm never
daveg wrote:
>
> I'd like to propose adding a new GUC to limit the amount of memory a backend
> can allocate for its own use. The problem this addresses is that sometimes
> one needs to set work_mem fairly high to get good query plans for large joins.
> However, some complex queries will then use
Boszormenyi Zoltan escribió:
> First, Tom Lane suggested to unify core and ecpg FETCH
> syntaxes so both will accept optional FROM/IN, which I did.
> SQLDA support adds new FETCH forms (Informix-specific
> ones) so naturally these patches clash. There's no simple way
> to make they separately appl
I'm looking why cometh_month fails and it is problem with last hstore
putback:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_moth&dt=2009-09-30%2021:06:00
Stack trace is following:
6f013828 hstore_hash (7fffa050, 1395298, 1, 41,
7370616365414143, 0) + c0
00
Aidan Van Dyk wrote:
> Can we have the check password hook function called in both the
> plaintext/encrypted case, with a flag as to whether it's encrypted or
> not?
It will be called in both cases, and I figured that you can
check yourself the same way that PostgreSQL does:
If isMD5(password), th
Dave Page writes:
> How will people know how to use it, or that it's even there without at
> least a note in the docs somewhere?
We don't normally document function hooks anywhere but the source code.
That's one of the things that makes them low overhead ;-)
I agree with the subsequent comments
On Sep 30, 2009, at 5:13 PM, Kevin Grittner wrote:
decibel wrote:
*any* step that improves dealing with table bloat is extremely
welcome, as right now you're basically stuck rebuilding the table.
+1
Although, possibly more irritating than actually rebuilding it is
evaluating borderline bloa
Stef Walter writes:
> Tom Lane wrote:
>> Now that the samehost/samenet patch is in, I wonder if it wouldn't be
>> a good idea to replace this part of the default pg_hba.conf file:
> You're probably not suggesting this, but I would be against a default
> setting of 'samehost' used with 'trust'.
>
Tom Lane escreveu:
> daveg writes:
>> I'd like to propose adding a new GUC to limit the amount of memory a backend
>> can allocate for its own use.
>
> Use ulimit.
>
What about plataforms (Windows) that don't have ulimit?
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via
On Thu, Oct 1, 2009 at 11:35 AM, Tom Lane wrote:
> Stef Walter writes:
>> Tom Lane wrote:
>>> Now that the samehost/samenet patch is in, I wonder if it wouldn't be
>>> a good idea to replace this part of the default pg_hba.conf file:
>
>> You're probably not suggesting this, but I would be agains
Euler Taveira de Oliveira writes:
> Tom Lane escreveu:
>> daveg writes:
>>> I'd like to propose adding a new GUC to limit the amount of memory a backend
>>> can allocate for its own use.
>>
>> Use ulimit.
>>
> What about plataforms (Windows) that don't have ulimit?
Get a real operating system
into hot standby mode after a
shutdown checkpoint. I think that really should be fixed, it's just
weird from a usability point of view if it doesn't work.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
hs-riggs-branch-20091001.tar.gz
Description: GNU Zip compressed
Simon Riggs wrote:
> Hmm, yes. ISTM that I'm still calculating latestRunningXid the old way
> while assuming it is calculated the new way. The new way is just to grab
> nextXid since we have XidGenLock and do TransactionIdRetreat() on it.
Ok, good, that's what I thought too. I'll fix that.
--
In response to Euler Taveira de Oliveira :
> Tom Lane escreveu:
> > daveg writes:
> >> I'd like to propose adding a new GUC to limit the amount of memory a
> >> backend
> >> can allocate for its own use.
> >
> > Use ulimit.
>
> What about plataforms (Windows) that don't have ulimit?
I have a h
On Thu, Oct 1, 2009 at 11:47 AM, Tom Lane wrote:
> Euler Taveira de Oliveira writes:
>> Tom Lane escreveu:
>>> daveg writes:
I'd like to propose adding a new GUC to limit the amount of memory a
backend
can allocate for its own use.
>>>
>>> Use ulimit.
>>>
>> What about plataforms
decibel wrote:
> So while something that makes it easier to clean out the end of a
> table would be good, I think the critical need is a way to make
> vacuum more aggressive about obtaining the exclusive lock.
I wonder if we should have a different mode of operation that only
attempted the trunca
Alvaro Herrera writes:
> I wonder if we should have a different mode of operation that only
> attempted the truncate (say VACUUM TRUNCATE), optionally being
> non-conditional about obtaining the required lock. That said, I wonder
> even more whether any such hacks are still needed after the visil
On Thu, 2009-10-01 at 18:47 +0300, Heikki Linnakangas wrote:
> Could you look into these two TODO items you listed on the wiki page:
Unless we agree otherwise, if its listed on the Wiki page then I will
work on it.
Maybe not as when you might like it, but I am working through the list.
5 new ch
On Thu, Oct 01, 2009 at 03:47:07PM +0200, Boszormenyi Zoltan wrote:
> You're not being fair with me. The dependencies are quite
> technical.
I'm sorry that you interpreted my email this way, it wasn't at all meant to
offend you.
> First, Tom Lane suggested to unify core and ecpg FETCH
> syntaxes
On Thu, 2009-10-01 at 18:48 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Hmm, yes. ISTM that I'm still calculating latestRunningXid the old way
> > while assuming it is calculated the new way. The new way is just to grab
> > nextXid since we have XidGenLock and do TransactionIdRetreat
Robert Haas writes:
> What WOULD be useful is to find a way to provide a way to configure
> work_mem per backend rather than per executor node. But that's a much
> harder problem.
I think it's mostly a planner problem: how do you deal with the fact
that that would make cost estimates for differe
Robert Haas escreveu:
> On Thu, Oct 1, 2009 at 11:47 AM, Tom Lane wrote:
>> Euler Taveira de Oliveira writes:
>>> Tom Lane escreveu:
daveg writes:
> I'd like to propose adding a new GUC to limit the amount of memory a
> backend
> can allocate for its own use.
Use ulimit.
>
On Thu, 2009-10-01 at 12:05 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > I wonder if we should have a different mode of operation that only
> > attempted the truncate (say VACUUM TRUNCATE), optionally being
> > non-conditional about obtaining the required lock. That said, I wonder
> > eve
Zdenek Kotala writes:
> I'm looking why cometh_month fails and it is problem with last hstore
> putback:
I think this is the same 64-bit problem we fixed last night --- wait for
the next rebuild before worrying.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Simon Riggs writes:
> No real need to be random is there? In the bloated space scenario,
> VACUUM will be triggered but will be unable to remove the empty blocks.
> So in that case VACUUM can hint the FSM to perform "start from beginning
> of relation" behaviour.
No, that's an entirely unrelated
Simon Riggs wrote:
> It would be more useful to think of this as "look for huge chunks of
> space and fill them" rather than "start at beginning", since space
> won't always be right at start.
Either I misunderstand you or I disagree. If there's a huge chunk of
space near the end, and many ma
Euler Taveira de Oliveira writes:
> I see. Tough problem is: how do we get per backend memory usage accurately? Is
> it relying on OS specific API the only way?
Given all the third-party libraries (perl, python, libxml2, yadda yadda)
that can be in use and won't go through palloc, I think that th
On Thu, 2009-10-01 at 11:32 -0500, Kevin Grittner wrote:
> Either I misunderstand you or I disagree.
That does seem to be a common stance, though I will read on. :-)
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Thu, 2009-10-01 at 11:32 -0500, Kevin Grittner wrote:
> If there's a huge chunk of
> space near the end, and many many smaller spaces spread throughout,
> what I'd like is for rows to be placed in those small ones. This
> would minimize the number of pages to read for queries, and would
> pres
Tom Lane escreveu:
> Robert Haas writes:
>> What WOULD be useful is to find a way to provide a way to configure
>> work_mem per backend rather than per executor node. But that's a much
>> harder problem.
>
> I think it's mostly a planner problem: how do you deal with the fact
> that that would m
Simon Riggs writes:
> Yes, as Tom points out, this must be done with bias away from the very
> end of the table.
> I meant that we should start from the beginning of large spaces and that
> we shouldn't assume that all space worth filling is at start of
> relation.
Right. One of the goals that
On Thu, Oct 1, 2009 at 17:24, Tom Lane wrote:
> Dave Page writes:
>> How will people know how to use it, or that it's even there without at
>> least a note in the docs somewhere?
>
> We don't normally document function hooks anywhere but the source code.
> That's one of the things that makes them
Magnus Hagander escreveu:
> On Thu, Oct 1, 2009 at 17:24, Tom Lane wrote:
>> Dave Page writes:
>>> How will people know how to use it, or that it's even there without at
>>> least a note in the docs somewhere?
>> We don't normally document function hooks anywhere but the source code.
>> That's on
Magnus Hagander writes:
> On Thu, Oct 1, 2009 at 17:24, Tom Lane wrote:
>> I agree with the subsequent comments suggesting a sample module that
>> actually does something useful --- although if it's going to link to
>> external code like cracklib, it probably is going to have to be on
>> pgfoundr
Alvaro Herrera writes:
> Oh, BTW, did anyone get interested in adding the bits to disable the OOM
> killer for postmaster on the various Linux initscripts? It needs some
> games with /proc//oom_adj and requires root privileges, but I think
> an initscript is in an excellent position to do it.
I
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I was imagining that this would be something for individual distros
> to tackle. It's probably not portable enough to go into the
> contrib/start-scripts examples. On the other hand, it'd make lots
> of sense to have the Fedora or Debian or whatever script
On Thu, Oct 1, 2009 at 19:07, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Oct 1, 2009 at 17:24, Tom Lane wrote:
>>> I agree with the subsequent comments suggesting a sample module that
>>> actually does something useful --- although if it's going to link to
>>> external code like crackl
On Thu, Oct 01, 2009 at 01:07:04PM -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Oct 1, 2009 at 17:24, Tom Lane wrote:
> >> I agree with the subsequent comments suggesting a sample module that
> >> actually does something useful --- although if it's going to link to
> >> external c
Tom Lane wrote:
> Alvaro Herrera writes:
> > Oh, BTW, did anyone get interested in adding the bits to disable the OOM
> > killer for postmaster on the various Linux initscripts? It needs some
> > games with /proc//oom_adj and requires root privileges, but I think
> > an initscript is in an excell
Michael Meskes írta:
> On Thu, Oct 01, 2009 at 03:47:07PM +0200, Boszormenyi Zoltan wrote:
>
>> You're not being fair with me. The dependencies are quite
>> technical.
>>
>
> I'm sorry that you interpreted my email this way, it wasn't at all meant to
> offend you.
>
Please, accept my ap
Tom Lane wrote:
Magnus Hagander writes:
On Thu, Oct 1, 2009 at 17:24, Tom Lane wrote:
I agree with the subsequent comments suggesting a sample module that
actually does something useful --- although if it's going to link to
external code like cracklib, it probably is going to have t
Petr Jelinek writes:
> because it seems like merging privileges seems to be acceptable for most
> (although I am not sure I like it, but I don't have better solution for
> managing conflicts), I changed the patch to do just that.
It's not clear to me whether we have consensus on this approach.
Stephen Frost writes:
> I'm not exactly keen on Debian init scripts hacking kernel settings.
> Should it hack up the shared memory numbers too? This is not what I
> would consider 'init script' material for specific applications.
What was suggested was tweaking the oom_adj setting for the postma
Magnus Hagander writes:
> That said, it would still be good to have something actually *useful*
> in contrib. A bit more than just comparing userid and password.
> Perhaps at least being able to set the min length, and the requirement
> on having >1 "character class"?
+1. There's still the issue
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Petr Jelinek writes:
> > because it seems like merging privileges seems to be acceptable for most
> > (although I am not sure I like it, but I don't have better solution for
> > managing conflicts), I changed the patch to do just that.
>
> It's not clear
Stephen Frost writes:
> This doesn't actually address the entire problem. How about
> schema-level default grants which you want to override with per-role
> default grants? Or the other way around? Is it always only more
> permissive with more defaults? Even when the grantee is the same?
Well
Tom Lane wrote:
> Stef Walter writes:
>> Tom Lane wrote:
>>> Now that the samehost/samenet patch is in, I wonder if it wouldn't be
>>> a good idea to replace this part of the default pg_hba.conf file:
>
>> You're probably not suggesting this, but I would be against a default
>> setting of 'sameho
On Thu, Oct 01, 2009 at 07:21:54PM +0200, Boszormenyi Zoltan wrote:
> Please, accept my apologies, I only tried to express my
> frustration, this is not a good situation for either of us.
Apologies accepted, email is a difficult means of communication anyway. It
leads to misunderstanding IMO.
> Y
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > This doesn't actually address the entire problem. How about
> > schema-level default grants which you want to override with per-role
> > default grants? Or the other way around? Is it always only more
> > permissive with more de
Stephen Frost writes:
> Erm, wait, we're going to drop the only piece of this that outside folks
> have actually been asking for? Specifically, having per-schema default
> ACLs?
They are per-schema for the objects belonging to the granting user.
Otherwise you have a bunch of nasty issues, includ
Tom Lane wrote:
Stephen Frost writes:
Erm, wait, we're going to drop the only piece of this that outside folks
have actually been asking for? Specifically, having per-schema default
ACLs?
They are per-schema for the objects belonging to the granting user.
Otherwise you have a bunch o
Tom Lane wrote:
> Simon Riggs writes:
>> Yes, as Tom points out, this must be done with bias away from the
>> very end of the table.
>
>> I meant that we should start from the beginning of large spaces and
>> that we shouldn't assume that all space worth filling is at start
>> of relation.
OK,
"Kevin Grittner" writes:
> Tom Lane wrote:
>> So for example we might try resetting the search to the start of the
>> relation with probability 0.01.
> If I understand the heuristic you propose, and my math skill haven't
> eroded too badly from lack of use, every 229 spots considered would
> ca
Michael Meskes írta:
> On Thu, Oct 01, 2009 at 07:21:54PM +0200, Boszormenyi Zoltan wrote:
>
>> Please, accept my apologies, I only tried to express my
>> frustration, this is not a good situation for either of us.
>>
>
> Apologies accepted, email is a difficult means of communication anywa
Peter Eisentraut wrote:
> I'm not exactly sure what the goal is, however. You built the
> documentation at some point. Then it gets updated when necessary. You
> can delete the documentation by running make -C doc maintainer-clean.
> Then it's gone forever and never reappears unless you explici
Kevin Grittner wrote:
> Tom Lane wrote:
>> Simon Riggs writes:
>>> Yes, as Tom points out, this must be done with bias away from the
>>> very end of the table.
>>> I meant that we should start from the beginning of large spaces and
>>> that we shouldn't assume that all space worth filling is at s
On Thu, Oct 01, 2009 at 10:35:55AM -0400, Tom Lane wrote:
> daveg writes:
> > I'd like to propose adding a new GUC to limit the amount of memory a backend
> > can allocate for its own use.
>
> Use ulimit.
That was my initial thought too. However, ulimit() is documented as superceded
by setrlimit
Heikki Linnakangas wrote:
> Kevin Grittner wrote:
>> Tom Lane wrote:
>>> So for example we might try resetting the search to the start of
the
>>> relation with probability 0.01.
>>
>> If I understand the heuristic you propose, and my math skill
>> haven't eroded too badly from lack of use, e
On Thu, Oct 01, 2009 at 11:47:43AM -0400, Tom Lane wrote:
> Euler Taveira de Oliveira writes:
> > Tom Lane escreveu:
> >> daveg writes:
> >>> I'd like to propose adding a new GUC to limit the amount of memory a
> >>> backend
> >>> can allocate for its own use.
> >>
> >> Use ulimit.
> Seriously
"Kevin Grittner" wrote:
> 0.99 percent chance to continue the sweep
Make that a 99% chance, or a 0.99 chance (in case the typo was not
apparent).
> Am I saying something stupid here?
Well, besides that line?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Thu, Oct 1, 2009 at 3:23 PM, Heikki Linnakangas
wrote:
> We probably could do with more bias. For example, we still prefer pages
> close to the page we last inserted to, by searching for free space in
> the same FSM page first, before starting the search from the top of the
> tree. And of cours
"Kevin Grittner" writes:
> The way I figure it, if there is a 0.01 chance to reset the sweep,
> then there's a 0.99 percent chance to continue the sweep from the last
> position. 0.99^229 is about 0.1, which means there is a 10% chance
> not to have reset after that many attempts to advance.
Rig
--On 30. September 2009 13:19:53 -0400 Alvaro Herrera
wrote:
I think it would be helpful if you could post ONE patch with all the
changes and all the new files in the diff. AIUI, "the" patch is now
split across three separate emails. :-(
That's correct, here it is.
Some additional not
Robert Haas writes:
> The elephant in the room here is that if the relation is a million
> pages of which 1-100,000 and 1,000,000 are in use, no amount of bias
> is going to help us truncate the relation unless every tuple on page
> 1,000,000 gets updated or deleted.
Well, there is no way to move
On Thu, Oct 1, 2009 at 4:47 PM, Tom Lane wrote:
> A possible downside of keeping things compact this way is that you'd
> probably get a longer average search distance because of all the early
> pages tending to remain full. Maybe what we want is some bias against
> inserting in the last half or q
On Thu, Oct 1, 2009 at 5:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> The elephant in the room here is that if the relation is a million
>> pages of which 1-100,000 and 1,000,000 are in use, no amount of bias
>> is going to help us truncate the relation unless every tuple on page
>> 1,000,000
Bernd Helmle escribió:
>
>
> --On 30. September 2009 13:19:53 -0400 Alvaro Herrera
> wrote:
>
> >>I think it would be helpful if you could post ONE patch with all the
> >>changes and all the new files in the diff. AIUI, "the" patch is now
> >>split across three separate emails. :-(
> >
> >Tha
Robert Haas wrote:
> The elephant in the room here is that if the relation is a million
> pages of which 1-100,000 and 1,000,000 are in use, no amount of bias
> is going to help us truncate the relation unless every tuple on page
> 1,000,000 gets updated or deleted.
Perhaps bias, combined wit
Tom Lane writes:
> That doesn't preclude also providing some more-invasive tools
> that people can use when they do get into that situation;
About this side of things, what about having any query which asks for
system columns (any of them) take a specific (new) exclusive row level
lock. The tupl
1 - 100 of 121 matches
Mail list logo
