On 06/09/10 23:10, Markus Wanner wrote:
Good. How about syscall overhead? One more write operation to the
self-pipe per signal from within the signal handler and one read to
actually clear the 'ready' state of the pipe from the waiter portion of
the code, right?
Right.
Do we plan to replace a
On 06/09/10 20:24, Markus Wanner wrote:
On 09/06/2010 06:27 PM, Heikki Linnakangas wrote:
+ * It's important to reset the latch*before* checking if there's work to
+ * do. Otherwise, if someone sets the latch between the check and the
+ * ResetLatch call, you will miss it and Wait will block.
Hello
this simple patch reduce a persistent allocated memory for tsearch
ispell dictionaries.
on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
on 64bit from 55MB to cca 27MB.
Regards
Pavel Stehule
tsearch_group_alloc.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list
On 7 September 2010 02:03, David Christensen wrote:
>
> On Sep 5, 2010, at 3:09 AM, Dean Rasheed wrote:
>
>> On 15 August 2010 18:38, Dean Rasheed wrote:
>>> Here is a WIP patch implementing triggers on VIEWs ...
>>>
>>> There are still a number of things left todo:
>>> - extend ALTER VIEW with
Hi,
On 05/27/2010 01:28 PM, Robert Haas wrote:
How do you propose to guarantee that? ISTM that you have to either
commit locally first, or send the commit to the remote first. Either
way, the two events won't occur exactly simultaneously.
I'm not getting the point of this discussion. As long
On 09/07/2010 09:06 AM, Heikki Linnakangas wrote:
Setting a latch that's already set is very fast, so you want to keep it
set until the last moment. See the coding in walsender for example, it
goes to some lengths to avoid clearing the latch until it's very sure
there's no more work for it to do.
Hello
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 should be overwritten, bu
On Tue, 2010-09-07 at 09:27 +0300, Heikki Linnakangas wrote:
> On 06/09/10 17:14, Simon Riggs wrote:
> > On Mon, 2010-09-06 at 16:14 +0300, Heikki Linnakangas wrote:
> >>>
> >>> The standby is sending a stream of messages to the master with current
> >>> LSN positions at the time the message is sen
On 07/09/10 12:47, Simon Riggs wrote:
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 received, we do.
Ok, thank you. The obvious performance problem is that
On Tue, 2010-09-07 at 13:11 +0300, Heikki Linnakangas wrote:
> The obvious performance problem
Is not obvious at all, and you misunderstand again. This emphasises the
need for me to show code.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Serv
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 in AllocSetContextCreate and A
On Tue, Sep 7, 2010 at 4:01 AM, Markus Wanner wrote:
> In any case, a server failure in between the commit request of the client
> and the commit confirmation for the client results in a client that can't
> tell if its transaction committed or not.
>
> So why do we care what to do first internally
On Sun, Sep 5, 2010 at 2:26 PM, Peter Eisentraut wrote:
> On fre, 2010-09-03 at 16:18 -0400, Tom Lane wrote:
>> Part of the reason it's sat on TODO is lack of consensus about how
>> such a feature ought to look/work; particularly since most of the
>> discussion about it has considered that it'd go
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
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
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 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
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
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: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
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
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 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
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.
>>>
>>
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
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
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
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
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
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
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
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
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.
>
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
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
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, 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
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 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-
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
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-
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
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
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
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)
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: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
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, 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
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
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: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
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 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.
"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 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
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
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 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 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
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
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
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
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
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
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
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
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
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
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 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, 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 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
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
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
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
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
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
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 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, 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 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
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 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
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: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
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, 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
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, 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
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 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 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, 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
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 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
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
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
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
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
1 - 100 of 113 matches
Mail list logo
