On Thu, 2009-10-01 at 17:08 -0400, Tom Lane wrote:
> The discussion at the moment is about ways
> of reducing the probability of getting into that situation in the
> first place.
Definitely.
> That doesn't preclude also providing some more-invasive tools that
> people can use when they do get
Tom Lane píše v čt 01. 10. 2009 v 12:28 -0400:
> 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.
Correct, last build see
On Thu, Oct 01, 2009 at 10:48:41PM -0400, Robert Haas wrote:
> On Mon, Sep 28, 2009 at 3:19 PM, Marko Tiikkaja
> wrote:
> > Robert Haas wrote:
> >>
> >> Can you at least take a stab at it? We can fix your grammar, but
> >> guessing what's going on without documentation is hard.
> >
> > With some
On Mon, Sep 28, 2009 at 3:19 PM, Marko Tiikkaja
wrote:
> Robert Haas wrote:
>>
>> Can you at least take a stab at it? We can fix your grammar, but
>> guessing what's going on without documentation is hard.
>
> With some help from David Fetter, I took another try at it. I hope
> someone finds thi
2009/10/1 KaiGai Kohei :
> Robert Haas wrote:
>> 2009/10/1 KaiGai Kohei :
>>> Robert Haas wrote:
On Thu, Oct 1, 2009 at 8:52 PM, Euler Taveira de Oliveira
wrote:
> David E. Wheeler escreveu:
>> On Oct 1, 2009, at 3:42 PM, Tom Lane wrote:
>>
>>> My inclination is to think
Robert Haas wrote:
> 2009/10/1 KaiGai Kohei :
>> Robert Haas wrote:
>>> On Thu, Oct 1, 2009 at 8:52 PM, Euler Taveira de Oliveira
>>> wrote:
David E. Wheeler escreveu:
> On Oct 1, 2009, at 3:42 PM, Tom Lane wrote:
>
>> My inclination is to think that the right behavior for REPLACE
2009/10/1 KaiGai Kohei :
> Robert Haas wrote:
>> On Thu, Oct 1, 2009 at 8:52 PM, Euler Taveira de Oliveira
>> wrote:
>>> David E. Wheeler escreveu:
On Oct 1, 2009, at 3:42 PM, Tom Lane wrote:
> My inclination is to think that the right behavior for REPLACE FUNCTION
> is to keep t
Robert Haas wrote:
> On Thu, Oct 1, 2009 at 8:52 PM, Euler Taveira de Oliveira
> wrote:
>> David E. Wheeler escreveu:
>>> On Oct 1, 2009, at 3:42 PM, Tom Lane wrote:
>>>
My inclination is to think that the right behavior for REPLACE FUNCTION
is to keep the old proowner and proacl values,
On Thu, Oct 1, 2009 at 1:37 PM, Tom Lane 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 c
On Thu, Oct 1, 2009 at 12:15 PM, Euler Taveira de Oliveira
wrote:
> 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 memo
On Thu, Oct 1, 2009 at 8:52 PM, Euler Taveira de Oliveira
wrote:
> David E. Wheeler escreveu:
>> On Oct 1, 2009, at 3:42 PM, Tom Lane wrote:
>>
>>> My inclination is to think that the right behavior for REPLACE FUNCTION
>>> is to keep the old proowner and proacl values, because that's what it
>>>
Alvaro Herrera wrote:
> Euler Taveira de Oliveira wrote:
> > Itagaki Takahiro escreveu:
> > > I fixed the confusions of get, hit and read in your patch.
> > >
> > Works for me. Will mark it ready for a committer.
> >
> > PS> BTW, your patch (20091001112006.9c36.52131...@oss.ntt.co.jp) doesn't
>
David E. Wheeler escreveu:
> On Oct 1, 2009, at 3:42 PM, Tom Lane wrote:
>
>> My inclination is to think that the right behavior for REPLACE FUNCTION
>> is to keep the old proowner and proacl values, because that's what it
>> always has done and nobody's complained. But I suppose a case could
>>
Euler Taveira de Oliveira wrote:
> Itagaki Takahiro escreveu:
> > I fixed the confusions of get, hit and read in your patch.
> >
> Works for me. Will mark it ready for a committer.
>
> PS> BTW, your patch (20091001112006.9c36.52131...@oss.ntt.co.jp) doesn't seem
> to be in archives.p.o. though I'
Itagaki Takahiro escreveu:
> I fixed the confusions of get, hit and read in your patch.
>
Works for me. Will mark it ready for a committer.
PS> BTW, your patch (20091001112006.9c36.52131...@oss.ntt.co.jp) doesn't seem
to be in archives.p.o. though I've received a copy from the server.
--
Eul
On Oct 1, 2009, at 3:42 PM, Tom Lane wrote:
My inclination is to think that the right behavior for REPLACE
FUNCTION
is to keep the old proowner and proacl values, because that's what it
always has done and nobody's complained. But I suppose a case could
be made that you're completely replacin
On Tue, Sep 29, 2009 at 09:52:06PM +0530, kunal sharma wrote:
> Hi ,
> We are using Postgres 8.4 and its been found going into recovery
> mode couple of times. The server process seems to fork another child process
> which is another postgres server running under same data directory and aft
"Kevin Grittner" writes:
> Fuzzy thinking there -- if it's the last quarter of the *free* pages,
> the suggested probabilities should be fine. (Somehow I got to
> thinking, for a moment, that it would be the last quarter of the
> relation's overall pages)
It's going to be the latter --- we d
Whilst fooling with the default ACLs patch I noticed that there's a
pre-existing bug in CREATE OR REPLACE FUNCTION. It will let you
replace a function if pg_proc_ownercheck passes, which these days
does *not* mean that you are exactly the role mentioned in
pg_proc.proowner; it only means you are s
"Kevin Grittner" wrote:
> I think it would make sense to just start using this once you get
> into the last half or quarter of the free pages. If you go with the
> last quarter, then you might want to use a higher probability than I
> suggested above, although that would tend to leave you with
Tom Lane wrote:
> (Hm, so we might want to make the probability depend on
> max_connections?)
Without doing rigorous math on it, I'd guess that to prevent
contention among n connections you'd want the probably of resetting
the sweep to be about 1 / (n * 2). That would mean you'd advance to
t
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
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
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
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
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
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 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
"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 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" 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 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
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 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
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
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
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
"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
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,
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
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 (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
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 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
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 (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
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
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
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.
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
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:
> 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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>
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
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
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: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
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
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
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
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
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.
--
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
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
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
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
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'.
>
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
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
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
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
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
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
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
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
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 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.
> +
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
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 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
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 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
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
* 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
1 - 100 of 121 matches
Mail list logo
