On Tue, Sep 7, 2010 at 6:02 AM, Simon Riggs wrote:
> On Mon, 2010-09-06 at 22:32 +0200, Boszormenyi Zoltan wrote:
>> (in commit)
>> write wal record
>> release locks/etc > wait for sync ack
>>
>> In the first case, the contention is obviously increased.
>> With this, we are creating more idle ti
Max Bowsher writes:
> On 08/09/10 00:37, Robert Haas wrote:
>> but if our CVS repository is busted maybe
>> we should be looking to fix that rather than complaining about
>> cvs2git.
> A possibility. We'd need a tool which would insert an extra node into
> the history graph of an RCS file. Unless
Greg Stark wrote:
> The industry standard solution that we're missing that we *should* be
> figuring out how to implement is incremental backups.
>
> I've actually been thinking about this recently and I think we could
> do it fairly easily with our existing infrastructure. I was planning
> on doi
On Tue, Sep 7, 2010 at 8:54 PM, Tom Lane wrote:
> Max Bowsher writes:
>> On 08/09/10 00:37, Robert Haas wrote:
>>> Well, if Max is correct that this bug is fixed in CVS 1.11.18 (I don't
>>> see it in the NEWS file) and that a checkout-by-date shows the file
>>> present during the time cvs2git cla
Max Bowsher writes:
> On 08/09/10 00:37, Robert Haas wrote:
>> Well, if Max is correct that this bug is fixed in CVS 1.11.18 (I don't
>> see it in the NEWS file) and that a checkout-by-date shows the file
>> present during the time cvs2git claims it is present, then a less
>> surprising translatio
Max Bowsher writes:
> On 08/09/10 00:47, Tom Lane wrote:
>> Max Bowsher writes:
>>> And, I've just tracked down that this bug was apparently fixed in CVS
>>> 1.11.18, released November 2004.
>>
>> Hrm, what bug exactly? As far as I've gathered from the discussion,
>> this is a fundamental desig
On 08/09/10 00:37, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 7:18 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Well, as Max says downthread, cvs -r REL8_4_STABLE -d
>>> INTERMEDIATE_DATE apparently shows the file as being there, which is a
>>> fairly good argument for his position.
>>
>> I ha
On 08/09/10 00:47, Tom Lane wrote:
> Max Bowsher writes:
>> And, I've just tracked down that this bug was apparently fixed in CVS
>> 1.11.18, released November 2004.
>
> Hrm, what bug exactly? As far as I've gathered from the discussion,
> this is a fundamental design limitation of CVS, not a fi
Max Bowsher writes:
> And, I've just tracked down that this bug was apparently fixed in CVS
> 1.11.18, released November 2004.
Hrm, what bug exactly? As far as I've gathered from the discussion,
this is a fundamental design limitation of CVS, not a fixable bug.
regards,
Jeff Davis writes:
> On Tue, 2010-09-07 at 13:30 -0700, David Fetter wrote:
>> Offhand, I'm not thinking of past examples of mutating/disappearing
>> GUC that people would want to freeze, nor of a new GUC that would
>> negate or substantially alter such freezing. What have I missed?
> It just se
On Tue, Sep 7, 2010 at 7:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, as Max says downthread, cvs -r REL8_4_STABLE -d
>> INTERMEDIATE_DATE apparently shows the file as being there, which is a
>> fairly good argument for his position.
>
> I haven't tested, but if I understand what Max and
Robert Haas writes:
> Well, as Max says downthread, cvs -r REL8_4_STABLE -d
> INTERMEDIATE_DATE apparently shows the file as being there, which is a
> fairly good argument for his position.
I haven't tested, but if I understand what Max and Michael are saying
about CVS, that operation would proba
On Tue, Sep 7, 2010 at 6:34 PM, Tom Lane wrote:
> Hmm. Some further looking in the git log output shows that that
> "manufactured commit" is actually the ONLY commit shown as being a
> predecessor of REL8_4_3. Everything else after 8.4.2 was tagged is
> shown as reached from refs/tags/REL8_4_4.
Max Bowsher writes:
> Hmm. Now I'm speculating vaguely about how the cycle breaker could be
> convinced to break branch update commits into as many pieces as
> possible, instead of as few.
That same thought occurred to me. If it simply didn't aggregate, but
treated each such file separately, wou
On 07/09/10 23:34, Tom Lane wrote:
> No doubt. However, the facts on the ground are that it.po is provably
> not there in REL8_4_0, REL8_4_1, REL8_4_2, or REL8_4_3, and is there in
> REL8_4_4, and that no commit on the branch touched it before 2010-05-13
> (just before 8.4.4). I will be intereste
Robert Haas wrote:
> On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs wrote:
> >> What I *think* you're saying is that the slave doesn't send per-commit
> >> messages, but instead processes the WAL as it's received and then sends
> >> a heres-where-I-am status message back upstream immediately before
I wrote:
> Hmm. Some further looking in the git log output shows that that
> "manufactured commit" is actually the ONLY commit shown as being a
> predecessor of REL8_4_3. Everything else after 8.4.2 was tagged is
> shown as reached from refs/tags/REL8_4_4. This is at the least pretty
> weird, an
On 07/09/10 23:20, Max Bowsher wrote:
> On 07/09/10 23:15, Robert Haas wrote:
>> On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane wrote:
>>> BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4
>>> and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps,
>>> but it sure
Robert Haas writes:
> On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane wrote:
>> BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4
>> and not refs/tags/REL8_4_3?
> I think this is another result of the same basic problem. Since
> cvs2git thinks it.po was added to REL8_4_STABLE
On Tue, 2010-09-07 at 14:49 -0700, David Fetter wrote:
> There are two problems at hand here, as I see it: the more general
> problem of "freezing" settings for a given role, and the very specific
> capability of guaranteeing read-only-ness, which could have large
> implications in, for example, da
On 07/09/10 23:15, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane wrote:
>> BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4
>> and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps,
>> but it sure looks wrong. (Magnus, did you check agains
On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane wrote:
> BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4
> and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps,
> but it sure looks wrong. (Magnus, did you check against the 8.4.3 tarball?)
I think this is anot
On 07/09/10 21:25, Magnus Hagander wrote:
> On Tue, Sep 7, 2010 at 22:06, Robert Haas wrote:
>> On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas wrote:
>>> On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander wrote:
You're saying you don't "require" a fix on the latest issue here? Or
should we
On Tue, Sep 07, 2010 at 02:43:12PM -0700, Jeff Davis wrote:
> On Tue, 2010-09-07 at 13:30 -0700, David Fetter wrote:
> > Offhand, I'm not thinking of past examples of mutating/disappearing
> > GUC that people would want to freeze, nor of a new GUC that would
> > negate or substantially alter such f
Max Bowsher writes:
> It wouldn't - except for the fact that cvs2git batches such manufactured
> commits such that there is no guarantee that a single manufactured
> commit pertains only to files in the commit immediately afterwards. For
> example, consider the it.po file in the commit referenced
On Tue, 2010-09-07 at 13:30 -0700, David Fetter wrote:
> Offhand, I'm not thinking of past examples of mutating/disappearing
> GUC that people would want to freeze, nor of a new GUC that would
> negate or substantially alter such freezing. What have I missed?
If you'll allow me to change my argum
I think so. Try it!
David
On Sep 7, 2010, at 11:39 AM, Sergey Konoplev wrote:
> Hi,
>
> On 7 September 2010 20:35, Tom Lane wrote:
>> How does $subject differ from what we already do? See
>> http://www.postgresql.org/docs/9.0/static/plpgsql-structure.html
>
> So will it be possible to do thi
On Tue, Sep 7, 2010 at 22:16, Tom Lane wrote:
> Robert Haas writes:
>> I just looked at your latest conversion (based on what Max did) and it
>> looks a lot better. I think, though, that we should re-remove these
>> branches:
>
>> origin/unlabeled-1.44.2
>> origin/unlabeled-1.51.2
>> origi
On Tue, Sep 07, 2010 at 12:41:51PM -0700, Jeff Davis wrote:
> On Tue, 2010-09-07 at 11:39 -0700, David Fetter wrote:
> > We'd like to create a role called read_only, with eponymous
> > capability.
>
> Seems useful.
Great to hear :)
> > If so, is it more
> > DCL-ish, or more DDL-ish?
>
> I don't
On Tue, Sep 7, 2010 at 22:06, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas wrote:
>> On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander wrote:
>>> You're saying you don't "require" a fix on the latest issue here? Or
>>> should we spend some time trying to figure out if we can f
Robert Haas writes:
> I just looked at your latest conversion (based on what Max did) and it
> looks a lot better. I think, though, that we should re-remove these
> branches:
> origin/unlabeled-1.44.2
> origin/unlabeled-1.51.2
> origin/unlabeled-1.59.2
> origin/unlabeled-1.87.2
> origi
On Tue, Sep 7, 2010 at 4:06 PM, marcin mank wrote:
> On Tue, Sep 7, 2010 at 5:17 PM, Tom Lane wrote:
>> We can *not* allow the slave to replay WAL ahead of what is known
>> committed to disk on the master. The only way to make that safe
>> is the compare-notes-and-ship-WAL-back approach that Rob
On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander wrote:
>> You're saying you don't "require" a fix on the latest issue here? Or
>> should we spend some time trying to figure out if we can fix it with
>> git-filter-branch?
>
> I think that "the
On Tue, Sep 7, 2010 at 5:17 PM, Tom Lane wrote:
> We can *not* allow the slave to replay WAL ahead of what is known
> committed to disk on the master. The only way to make that safe
> is the compare-notes-and-ship-WAL-back approach that Robert mentioned.
>
> If you feel that decoupling WAL applic
On Tue, 2010-09-07 at 11:39 -0700, David Fetter wrote:
> We'd like to create a role called read_only, with eponymous
> capability.
Seems useful.
> If so, is it more
> DCL-ish, or more DDL-ish?
I don't like the idea of a security model relying on the ability (or
lack thereof) to set GUCs. Imagine
On sön, 2010-08-22 at 15:15 -0400, Tom Lane wrote:
> > We combine the surrogate pair components to a single code point and
> > encode that in UTF-8. We don't encode the components separately;
> that
> > would be wrong.
>
> Oh, OK. Should the docs make that a bit clearer?
Done.
--
Sent via pg
Hi,
On 7 September 2010 20:35, Tom Lane wrote:
> How does $subject differ from what we already do? See
> http://www.postgresql.org/docs/9.0/static/plpgsql-structure.html
So will it be possible to do things like this?
1.
CREATE FUNCTION func_name(arg_name text) RETURNS integer AS $$
BEGIN
R
Folks,
I noticed a little unimplemented feature which I suspect a lot of
people would find useful, namely the ability to "freeze" certain
settings for a role.
Example: We'd like to create a role called read_only, with eponymous
capability. At the moment, we can't do what's below, but I'd like to
Max Bowsher writes:
> On 07/09/10 18:16, Tom Lane wrote:
>> Hmm, I see. This depends on the fact that git commits reference
>> filesystem states and not deltas, correct? So it does actually make
>> sense to just delete that commit from the history. I was concerned
>> that it'd invalidate later
2010/9/7 Robert Haas :
> On Tue, Sep 7, 2010 at 12:44 PM, Pavel Stehule
> wrote:
>>> I don't see how you could do anything with this that you can't do with
>>> the existing implementation. It's not as if you can store pointers
>>> into an mmap'd block and then count on them being valid the next
On Tue, Sep 7, 2010 at 12:44 PM, Pavel Stehule wrote:
>> I don't see how you could do anything with this that you can't do with
>> the existing implementation. It's not as if you can store pointers
>> into an mmap'd block and then count on them being valid the next time
>> you map the file... it
On Tue, Sep 7, 2010 at 2:15 PM, Simon Riggs wrote:
> Every time I explain anything, I get someone run around shouting "but
> that can't work!". I'm sorry, but again your logic is poor and the bias
> against properly considering viable alternatives is the only thing
> perfectly evident. So yes, I a
On 07/09/10 18:16, Tom Lane wrote:
> Michael Haggerty writes:
>> Tom Lane wrote:
>>> What I'd like is for those commits to vanish from the git log entirely.
>
>> It seems to me that in your case such commits could be "grafted over":
>
>> *---*---*---*
>> \
>> A---B---C---D
>
On Tue, 2010-09-07 at 12:07 -0400, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs wrote:
> >> What I *think* you're saying is that the slave doesn't send per-commit
> >> messages, but instead processes the WAL as it's received and then sends
> >> a heres-where-I-am status messag
On 09/07/2010 05:55 PM, Markus Wanner wrote:
Robert's argument
Sorry, I meant Ron.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 09/07/2010 06:00 PM, Robert Haas wrote:
People who are more concerned about performance than robustness aren't
going to use sync rep in the first place.
I'm advocating sync (or eager, FWIW) replication for years, now. One of
the hardest preconception I'm always confronted with is: this
Heikki Linnakangas writes:
> A more general solution would be to have a new MemoryContext
> implementation that does the same your patch does. Ie. instead of
> tracking each allocation, just allocate a big chunk, and have palloc()
> return the next n free bytes from it, like a stack. pfree() wo
Michael Haggerty writes:
> Tom Lane wrote:
>> What I'd like is for those commits to vanish from the git log entirely.
> It seems to me that in your case such commits could be "grafted over":
> *---*---*---*
> \
> A---B---C---D
> E.g., if "C" is one of these special manufactur
Max Bowsher writes:
> On 07/09/10 16:47, Tom Lane wrote:
>> Max Bowsher writes:
>>> ... Just as soon as I can figure out how
>>> to cleanly fit that into cvs2git's structure, I want it to change the
>>> word "create" to "update" in most of those commits.
>> I thought all of those message texts w
Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 7, 2010 at 17:07, Tom Lane wrote:
>>> Look for
>>>This commit was manufactured by cvs2svn to create branch ...
>
>> Ok, found a bunch of those (78 to be exact). And the issue with them
>> is we want to change the commit author on t
2010/9/7 Robert Haas :
> On Tue, Sep 7, 2010 at 9:27 AM, Pavel Stehule wrote:
>> 2010/9/7 Robert Haas :
>>> On Tue, Sep 7, 2010 at 4:53 AM, Pavel Stehule
>>> wrote:
I would to use a special memory context for shared data (based on
mmap) and I like impementation of aset. There is only o
Hello
2010/9/7 Teodor Sigaev :
> Hm, what is aim of this hook? It looks like a wrapper of dictionary init
> method.
If I use a mmap for shared dictionary, then I have to prealloc and
maybe preread dictionary - it can be done in external module. But I
have to join preloaded dictionary to requested
A more general solution would be to have a new MemoryContext
implementation that does the same your patch does. Ie. instead of
tracking each allocation, just allocate a big chunk, and have palloc()
return the next n free bytes from it, like a stack. pfree() would
obviously not work, but wholesale
2010/9/7 Heikki Linnakangas :
> On 07/09/10 19:27, Teodor Sigaev wrote:
>>>
>>> on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
>>> on 64bit from 55MB to cca 27MB.
>>
>> Good results. But, I think, there are more places in ispell to use
>> hold_memory():
>> - affixes and affix tree
>> - regi
On 07/09/10 16:47, Tom Lane wrote:
> Max Bowsher writes:
>> Personally, the idea of trying to use git-filter-branch to make what
>> cvs2git currently gives you more sensible scares me silly.
>
> I'm not excited about it either --- but if Magnus wants to experiment,
> no harm trying.
>
>> Another
2010/9/7 Teodor Sigaev :
>> on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
>> on 64bit from 55MB to cca 27MB.
>
> Good results. But, I think, there are more places in ispell to use
> hold_memory():
> - affixes and affix tree
> - regis (REGex for ISpell, regis.c)
yes, but minimally for Czec
On 07/09/10 19:27, Teodor Sigaev wrote:
on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
on 64bit from 55MB to cca 27MB.
Good results. But, I think, there are more places in ispell to use
hold_memory():
- affixes and affix tree
- regis (REGex for ISpell, regis.c)
A more general solution
On Sep 7, 2010, at 9:35 AM, Tom Lane wrote:
> How does $subject differ from what we already do? See
> http://www.postgresql.org/docs/9.0/static/plpgsql-structure.html
> particularly this:
>
> Note: There is actually a hidden "outer block" surrounding the
> body of any PL/pgSQL functi
"David E. Wheeler" writes:
> Anyone ever thought to try to add $subject to PL/pgSQL?
How does $subject differ from what we already do? See
http://www.postgresql.org/docs/9.0/static/plpgsql-structure.html
particularly this:
Note: There is actually a hidden "outer block" surrounding the
on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
on 64bit from 55MB to cca 27MB.
Good results. But, I think, there are more places in ispell to use
hold_memory():
- affixes and affix tree
- regis (REGex for ISpell, regis.c)
--
Teodor Sigaev E-mail: teo.
Howdy,
Anyone ever thought to try to add $subject to PL/pgSQL? Someone left a
[comment][] on the PGXN blog about how this is a supported syntax for using
named parameters on Oracle. The context is to avoid conflicts between variable
names and column names by function-qualifyin the former and ta
On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs wrote:
>> What I *think* you're saying is that the slave doesn't send per-commit
>> messages, but instead processes the WAL as it's received and then sends
>> a heres-where-I-am status message back upstream immediately before going
>> to sleep waiting f
I also dropped the use of rd_amcache, instead having ginGetStats()
Ok, I'm agree
I didn't do anything about the questionable equations in
gincostestimate. Those need to either be fixed, or documented as
to why they're correct. Other than that I think this could be
committed.
Fixed, and slig
On Tue, Sep 7, 2010 at 11:06 AM, Simon Riggs wrote:
> On Tue, 2010-09-07 at 16:31 +0200, Markus Wanner wrote:
>> On 09/07/2010 04:15 PM, Robert Haas wrote:
>> > In theory, that's true, but if we do that, then there's an even bigger
>> > problem: the slave might have replayed WAL ahead of the maste
On Tue, 2010-09-07 at 11:41 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2010-09-07 at 10:47 -0400, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> The WAL is sent from master to standby in 8192 byte chunks, frequently
> >>> including multiple commits. From standby, one reply per chunk
Hi,
On 09/07/2010 05:17 PM, Tom Lane wrote:
Oh yes it is. If the slave replays WAL that didn't happen on the
master, it might for instance have heap tuples in TID slots that are
empty on the master, or index pages laid out differently from the
master. Trying to apply additional WAL from the ma
On Tue, Sep 7, 2010 at 11:41 AM, Tom Lane wrote:
> Oh, well you certainly didn't explain it well then.
>
> What I *think* you're saying is that the slave doesn't send per-commit
> messages, but instead processes the WAL as it's received and then sends
> a heres-where-I-am status message back upstr
I wrote:
> Magnus Hagander writes:
>> Ok, found a bunch of those (78 to be exact).
> What I'd like is for those commits to vanish from the git log entirely.
> In a practical sense, what you should probably do is for each file
> mentioned in such a commit, cause the file's addition to the branch
On Tue, Sep 7, 2010 at 11:18 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar sep 07 10:13:12 -0400 2010:
>
>> > I try to solve performance problems with czech tsearch. I checked
>> > serialization and deserialization, but this decrease load time only to
>> > 100ms (from 500)
Max Bowsher writes:
> Personally, the idea of trying to use git-filter-branch to make what
> cvs2git currently gives you more sensible scares me silly.
I'm not excited about it either --- but if Magnus wants to experiment,
no harm trying.
> Another glitch that might be worth fixing before you co
Simon Riggs writes:
> On Tue, 2010-09-07 at 11:17 -0400, Tom Lane wrote:
>> We can *not* allow the slave to replay WAL ahead of what is known
>> committed to disk on the master. The only way to make that safe
>> is the compare-notes-and-ship-WAL-back approach that Robert mentioned.
>>
>> If you
Simon Riggs writes:
> On Tue, 2010-09-07 at 10:47 -0400, Tom Lane wrote:
>> Simon Riggs writes:
>>> The WAL is sent from master to standby in 8192 byte chunks, frequently
>>> including multiple commits. From standby, one reply per chunk. If we
>>> need to wait for apply while nothing else is rece
For one week guys...
https://www.postgresqlconference.org/2010/west/cfp/
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997
--
Sent via pgsql-
On 07/09/10 16:21, Magnus Hagander wrote:
> On Tue, Sep 7, 2010 at 17:07, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Tue, Sep 7, 2010 at 16:16, Tom Lane wrote:
If you want to try, and it doesn't take much time, go for it. I was
just saying I wouldn't complain if we decide to li
On 09/07/2010 04:47 PM, Ron Mayer wrote:
In that situation, wouldn't it be possible that a different client
queried the slave and already saw the result of that transaction
which would later be rolled back?
Good point, yes.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-
Magnus Hagander writes:
> On Tue, Sep 7, 2010 at 17:07, Tom Lane wrote:
>> Look for
>> This commit was manufactured by cvs2svn to create branch ...
> Ok, found a bunch of those (78 to be exact). And the issue with them
> is we want to change the commit author on them to be whomever made t
On Tue, 2010-09-07 at 11:17 -0400, Tom Lane wrote:
> Markus Wanner writes:
> > On 09/07/2010 04:15 PM, Robert Haas wrote:
> >> In theory, that's true, but if we do that, then there's an even bigger
> >> problem: the slave might have replayed WAL ahead of the master
> >> location; therefore the sla
On Tue, 2010-09-07 at 10:47 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2010-09-07 at 09:27 +0300, Heikki Linnakangas wrote:
> >> For the sake of argument, yes that's what I was thinking. Now please
> >> explain how *you're* thinking it should work.
>
> > The WAL is sent from master
On Tue, Sep 7, 2010 at 17:07, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 7, 2010 at 16:16, Tom Lane wrote:
>>> If you want to try, and it doesn't take much time, go for it. I was
>>> just saying I wouldn't complain if we decide to live with it as-is.
>
>> Ok. Do we have a way of i
Excerpts from Robert Haas's message of mar sep 07 10:13:12 -0400 2010:
> > I try to solve performance problems with czech tsearch. I checked
> > serialization and deserialization, but this decrease load time only to
> > 100ms (from 500) that is too much for us. After some gaming with mmap
> > I th
Markus Wanner writes:
> On 09/07/2010 04:15 PM, Robert Haas wrote:
>> In theory, that's true, but if we do that, then there's an even bigger
>> problem: the slave might have replayed WAL ahead of the master
>> location; therefore the slave is now corrupt and a new base backup
>> must be taken.
>
Magnus Hagander writes:
> On Tue, Sep 7, 2010 at 16:16, Tom Lane wrote:
>> If you want to try, and it doesn't take much time, go for it. I was
>> just saying I wouldn't complain if we decide to live with it as-is.
> Ok. Do we have a way of identifying them - e.g. is it all the commits
> with a
On Tue, 2010-09-07 at 16:31 +0200, Markus Wanner wrote:
> On 09/07/2010 04:15 PM, Robert Haas wrote:
> > In theory, that's true, but if we do that, then there's an even bigger
> > problem: the slave might have replayed WAL ahead of the master
> > location; therefore the slave is now corrupt and a n
http://www.sigaev.ru/misc/builtin_knngist_core-0.8.gz
http://www.sigaev.ru/misc/builtin_knngist_itself-0.8.gz
http://www.sigaev.ru/misc/builtin_knngist_proc-0.8.gz
http://www.sigaev.ru/misc/builtin_knngist_contrib_pg_trgm-0.8.gz
http://www.sigaev.ru/misc/builtin_knngist_contrib_btree_gist-0.8.gz
Hm, what is aim of this hook? It looks like a wrapper of dictionary init method.
I propose a new hook type - that helps with controlling a life cycle
of some tsearch dictionaries. This hook has minimal impact on
performance - it's called once per session for one tsearch
configuration.
--
Teodo
Robert Haas writes:
> On Tue, Sep 7, 2010 at 9:27 AM, Pavel Stehule wrote:
>> I try to solve performance problems with czech tsearch. I checked
>> serialization and deserialization, but this decrease load time only to
>> 100ms (from 500) that is too much for us. After some gaming with mmap
>> I t
Simon Riggs writes:
> On Tue, 2010-09-07 at 09:27 +0300, Heikki Linnakangas wrote:
>> For the sake of argument, yes that's what I was thinking. Now please
>> explain how *you're* thinking it should work.
> The WAL is sent from master to standby in 8192 byte chunks, frequently
> including multipl
Markus Wanner wrote:
> On 09/07/2010 02:16 PM, Robert Haas wrote:
>> practice, this means that the master and standby need to compare notes
>> on the ending WAL location and whichever one is further advanced needs
>> to stream the intervening records to the other.
>
> Not necessarily, no. Remember
Pavel Stehule writes:
> I would to use a special memory context for shared data (based on
> mmap) and I like impementation of aset. There is only one difference -
> aset is based on malloc and I would to use a mmap.
> malloc() is used in AllocSetContextCreate and AllocSetAlloc. These
> procedures
On Tue, Sep 7, 2010 at 16:16, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 7, 2010 at 15:53, Tom Lane wrote:
>>> Michael Haggerty writes:
Somebody could use "git filter-branch" to make this change after the
conversion, but I can't estimate how much work it would be.
>>>
>>
On 09/07/2010 04:15 PM, Robert Haas wrote:
In theory, that's true, but if we do that, then there's an even bigger
problem: the slave might have replayed WAL ahead of the master
location; therefore the slave is now corrupt and a new base backup
must be taken.
The slave isn't corrupt. It would su
Magnus Hagander writes:
> On Tue, Sep 7, 2010 at 15:53, Tom Lane wrote:
>> Michael Haggerty writes:
>>> Somebody could use "git filter-branch" to make this change after the
>>> conversion, but I can't estimate how much work it would be.
>>
>> The conversion is already far better than I expected
On Tue, Sep 7, 2010 at 9:45 AM, Markus Wanner wrote:
> On 09/07/2010 02:16 PM, Robert Haas wrote:
>>
>> Right, definitely. The trouble is that if they happen concurrently,
>> and there's a crash, you have to be prepared for the possibility that
>> either one of the two has completed and the other
On Tue, Sep 7, 2010 at 9:27 AM, Pavel Stehule wrote:
> 2010/9/7 Robert Haas :
>> On Tue, Sep 7, 2010 at 4:53 AM, Pavel Stehule
>> wrote:
>>> I would to use a special memory context for shared data (based on
>>> mmap) and I like impementation of aset. There is only one difference -
>>> aset is ba
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> I certainly hope that pg_regress isn't freeing the strings it passes
> > >> to putenv() ...
> >
> > > pg_regress does not restore these settings (it says with C/English) so
> > > the code is different.
>
On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander wrote:
> You're saying you don't "require" a fix on the latest issue here? Or
> should we spend some time trying to figure out if we can fix it with
> git-filter-branch?
I think that "the latest issue here" is the issue of how files get
added to bra
On Tue, Sep 7, 2010 at 15:53, Tom Lane wrote:
> Michael Haggerty writes:
>> Tom Lane wrote:
>>> So, if we're prepared to assert that we've never done that, could we
>>> have an option to cvs2git that is willing to use the first commit on
>>> a branch to represent the act of adding the file to the
Michael Haggerty writes:
> Tom Lane wrote:
>> So, if we're prepared to assert that we've never done that, could we
>> have an option to cvs2git that is willing to use the first commit on
>> a branch to represent the act of adding the file to the branch?
> I'm afraid this would be pretty far down
On 09/07/2010 02:16 PM, Robert Haas wrote:
Right, definitely. The trouble is that if they happen concurrently,
and there's a crash, you have to be prepared for the possibility that
either one of the two has completed and the other is not.
Understood.
In
practice, this means that the master a
2010/9/7 Robert Haas :
> On Tue, Sep 7, 2010 at 4:53 AM, Pavel Stehule wrote:
>> I would to use a special memory context for shared data (based on
>> mmap) and I like impementation of aset. There is only one difference -
>> aset is based on malloc and I would to use a mmap.
>>
>> malloc() is used
1 - 100 of 113 matches
Mail list logo
