Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Heikki Linnakangas
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 sent. Given a synchronous transaction, the master would wait until the feedback

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Michael Haggerty
Tom Lane wrote: Michael Haggerty mhag...@alum.mit.edu writes: No, it is also possible to use cvs tag -b REL8_4_STABLE filename. In this case the file as it appears on the current branch is added to the specified branch, but CVS records no commit, author, or timestamp. So, if we're prepared

Re: Interruptible sleeps (was Re: [HACKERS] CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

2010-09-07 Thread Heikki Linnakangas
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

Re: Interruptible sleeps (was Re: [HACKERS] CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

2010-09-07 Thread Heikki Linnakangas
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.

[HACKERS] patch: tsearch - some memory diet

2010-09-07 Thread Pavel Stehule
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

Re: [HACKERS] WIP: Triggers on VIEWs

2010-09-07 Thread Dean Rasheed
On 7 September 2010 02:03, David Christensen da...@endpoint.com wrote: On Sep 5, 2010, at 3:09 AM, Dean Rasheed wrote: On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote: Here is a WIP patch implementing triggers on VIEWs ... snip There are still a number of things left

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Markus Wanner
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

Re: Interruptible sleeps (was Re: [HACKERS] CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

2010-09-07 Thread Markus Wanner
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

[HACKERS] can we publish a aset interface?

2010-09-07 Thread Pavel Stehule
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,

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Simon Riggs
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 sent. Given a

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Heikki Linnakangas
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

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Simon Riggs
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

Re: [HACKERS] can we publish a aset interface?

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 4:53 AM, Pavel Stehule pavel.steh...@gmail.com 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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 4:01 AM, Markus Wanner mar...@bluegap.ch 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

Re: [HACKERS] returning multiple result sets from a stored procedure

2010-09-07 Thread Merlin Moncure
On Sun, Sep 5, 2010 at 2:26 PM, Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] can we publish a aset interface?

2010-09-07 Thread Pavel Stehule
2010/9/7 Robert Haas robertmh...@gmail.com: On Tue, Sep 7, 2010 at 4:53 AM, Pavel Stehule pavel.steh...@gmail.com 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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Markus Wanner
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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
Michael Haggerty mhag...@alum.mit.edu 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Magnus Hagander
On Tue, Sep 7, 2010 at 15:53, Tom Lane t...@sss.pgh.pa.us wrote: Michael Haggerty mhag...@alum.mit.edu 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander mag...@hagander.net 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

Re: [HACKERS] Fix for pg_upgrade's forcing pg_controldata into English

2010-09-07 Thread Bruce Momjian
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian br...@momjian.us 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.

Re: [HACKERS] can we publish a aset interface?

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 9:27 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2010/9/7 Robert Haas robertmh...@gmail.com: On Tue, Sep 7, 2010 at 4:53 AM, Pavel Stehule pavel.steh...@gmail.com wrote: I would to use a special memory context for shared data (based on mmap) and I like

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 9:45 AM, Markus Wanner mar...@bluegap.ch 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 15:53, Tom Lane t...@sss.pgh.pa.us wrote: Michael Haggerty mhag...@alum.mit.edu 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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Markus Wanner
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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Magnus Hagander
On Tue, Sep 7, 2010 at 16:16, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 15:53, Tom Lane t...@sss.pgh.pa.us wrote: Michael Haggerty mhag...@alum.mit.edu writes: Somebody could use git filter-branch to make this change after the

Re: [HACKERS] can we publish a aset interface?

2010-09-07 Thread Tom Lane
Pavel Stehule pavel.steh...@gmail.com 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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Ron Mayer
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 that

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] can we publish a aset interface?

2010-09-07 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Tue, Sep 7, 2010 at 9:27 AM, Pavel Stehule pavel.steh...@gmail.com 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

Re: [HACKERS] proposal: tsearch dictionary initialization hook

2010-09-07 Thread Teodor Sigaev
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. --

Re: [HACKERS] knngist - 0.8

2010-09-07 Thread Teodor Sigaev
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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Simon Riggs
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 new

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 16:16, Tom Lane t...@sss.pgh.pa.us 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.

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Tom Lane
Markus Wanner mar...@bluegap.ch 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

Re: [HACKERS] can we publish a aset interface?

2010-09-07 Thread Alvaro Herrera
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 thinking

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Magnus Hagander
On Tue, Sep 7, 2010 at 17:07, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 16:16, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Simon Riggs
On Tue, 2010-09-07 at 10:47 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Simon Riggs
On Tue, 2010-09-07 at 11:17 -0400, Tom Lane wrote: Markus Wanner mar...@bluegap.ch 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 17:07, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Markus Wanner
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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Max Bowsher
On 07/09/10 16:21, Magnus Hagander wrote: On Tue, Sep 7, 2010 at 17:07, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 16:16, Tom Lane t...@sss.pgh.pa.us wrote: If you want to try, and it doesn't take much time, go for it. I was just

[HACKERS] PgWest 2010 CFP extended (one week)

2010-09-07 Thread Joshua D. Drake
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

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: On Tue, 2010-09-07 at 10:47 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com 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.

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
Max Bowsher m...@f2s.com 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

Re: [HACKERS] can we publish a aset interface?

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 11:18 AM, Alvaro Herrera alvhe...@commandprompt.com 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
I wrote: Magnus Hagander mag...@hagander.net 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

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Markus Wanner
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

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Simon Riggs
On Tue, 2010-09-07 at 11:41 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: On Tue, 2010-09-07 at 10:47 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: The WAL is sent from master to standby in 8192 byte chunks, frequently including multiple commits. From

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 11:06 AM, Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] gincostestimate

2010-09-07 Thread Teodor Sigaev
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

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs si...@2ndquadrant.com 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

[HACKERS] function_name.parameter_name

2010-09-07 Thread David E. Wheeler
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

Re: [HACKERS] patch: tsearch - some memory diet

2010-09-07 Thread 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) -- Teodor Sigaev E-mail:

Re: [HACKERS] function_name.parameter_name

2010-09-07 Thread Tom Lane
David E. Wheeler david.whee...@pgexperts.com 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

Re: [HACKERS] function_name.parameter_name

2010-09-07 Thread David E. Wheeler
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 function.

Re: [HACKERS] patch: tsearch - some memory diet

2010-09-07 Thread 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 - regis (REGex for ISpell, regis.c) A more general

Re: [HACKERS] patch: tsearch - some memory diet

2010-09-07 Thread Pavel Stehule
2010/9/7 Teodor Sigaev teo...@sigaev.ru: 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Max Bowsher
On 07/09/10 16:47, Tom Lane wrote: Max Bowsher m...@f2s.com 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.

Re: [HACKERS] patch: tsearch - some memory diet

2010-09-07 Thread Pavel Stehule
2010/9/7 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: 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

Re: [HACKERS] patch: tsearch - some memory diet

2010-09-07 Thread Teodor Sigaev
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

Re: [HACKERS] proposal: tsearch dictionary initialization hook

2010-09-07 Thread Pavel Stehule
Hello 2010/9/7 Teodor Sigaev teo...@sigaev.ru: 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

Re: [HACKERS] can we publish a aset interface?

2010-09-07 Thread Pavel Stehule
2010/9/7 Robert Haas robertmh...@gmail.com: On Tue, Sep 7, 2010 at 9:27 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2010/9/7 Robert Haas robertmh...@gmail.com: On Tue, Sep 7, 2010 at 4:53 AM, Pavel Stehule pavel.steh...@gmail.com wrote: I would to use a special memory context for shared

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Michael Haggerty
Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 17:07, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
Max Bowsher m...@f2s.com writes: On 07/09/10 16:47, Tom Lane wrote: Max Bowsher m...@f2s.com 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
Michael Haggerty mhag...@alum.mit.edu 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

Re: [HACKERS] patch: tsearch - some memory diet

2010-09-07 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Markus Wanner
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:

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Markus Wanner
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

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Simon Riggs
On Tue, 2010-09-07 at 12:07 -0400, Robert Haas wrote: On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Max Bowsher
On 07/09/10 18:16, Tom Lane wrote: Michael Haggerty mhag...@alum.mit.edu 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

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 2:15 PM, Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] can we publish a aset interface?

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 12:44 PM, Pavel Stehule pavel.steh...@gmail.com 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

Re: [HACKERS] can we publish a aset interface?

2010-09-07 Thread Pavel Stehule
2010/9/7 Robert Haas robertmh...@gmail.com: On Tue, Sep 7, 2010 at 12:44 PM, Pavel Stehule pavel.steh...@gmail.com 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
Max Bowsher m...@f2s.com 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

[HACKERS] Freezing per-role settings

2010-09-07 Thread David Fetter
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

Re: [HACKERS] function_name.parameter_name

2010-09-07 Thread Sergey Konoplev
Hi, On 7 September 2010 20:35, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] UTF16 surrogate pairs in UTF8 encoding

2010-09-07 Thread Peter Eisentraut
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

Re: [HACKERS] Freezing per-role settings

2010-09-07 Thread Jeff Davis
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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread marcin mank
On Tue, Sep 7, 2010 at 5:17 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander mag...@hagander.net 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

Re: [HACKERS] Synchronization levels in SR

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 4:06 PM, marcin mank marcin.m...@gmail.com wrote: On Tue, Sep 7, 2010 at 5:17 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Magnus Hagander
On Tue, Sep 7, 2010 at 22:06, Robert Haas robertmh...@gmail.com wrote: On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander mag...@hagander.net wrote: You're saying you don't require a fix on the latest issue here? Or should

Re: [HACKERS] Freezing per-role settings

2010-09-07 Thread David Fetter
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 like the

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Magnus Hagander
On Tue, Sep 7, 2010 at 22:16, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com 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  

Re: [HACKERS] function_name.parameter_name

2010-09-07 Thread David E. Wheeler
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 t...@sss.pgh.pa.us 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

Re: [HACKERS] Freezing per-role settings

2010-09-07 Thread Jeff Davis
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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
Max Bowsher m...@f2s.com 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

Re: [HACKERS] Freezing per-role settings

2010-09-07 Thread David Fetter
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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Max Bowsher
On 07/09/10 21:25, Magnus Hagander wrote: On Tue, Sep 7, 2010 at 22:06, Robert Haas robertmh...@gmail.com wrote: On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander mag...@hagander.net wrote: You're saying you don't require

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Robert Haas
On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Max Bowsher
On 07/09/10 23:15, Robert Haas wrote: On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Freezing per-role settings

2010-09-07 Thread Jeff Davis
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, data

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Max Bowsher
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 t...@sss.pgh.pa.us 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

Re: [HACKERS] git: uh-oh

2010-09-07 Thread Tom Lane
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, and I

Re: [HACKERS] Synchronous replication - patch status inquiry

2010-09-07 Thread Bruce Momjian
Robert Haas wrote: On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs si...@2ndquadrant.com 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

  1   2   >