Hey Dimitri,
On 07/24/2010 07:26 PM, Dimitri Fontaine wrote:
Trying to figure out how it would fit the PGQ and pgagent needs. But
maybe user defined daemons should be sub-coordinators (I used to think
about them as supervisors) able to talk to the coordinator to get a
backend connected to some
On Thu, Jul 22, 2010 at 5:37 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Fujii Masao wrote:
How should the synchronous replication behave when the number of connected
standby servers is less than quorum?
1. Ignore quorum. The current patch adopts this. If the ACKs from all
connected
The attached patches are revised ones, as follows.
* A new SECURITY LABEL statement replaced the previous ALTER TABLE statement
with SECURITY LABEL TO option. It has the following syntax.
SECURITY LABEL [ FOR provider ] ON object class object name IS
'label';
E.g) SECURITY LABEL ON TABLE
On Sat, Jul 24, 2010 at 4:40 PM, z...@cybertec.at wrote:
Instead, I will post a patch that unifies my configuration choices with
Fujii's patch. Do you have suggestions for better worded GUCs?
slave seems to be phased out by standby for political correctness, so
synchronous_standby instead of
Fujii Masao wrote:
Intuitively by looking at the enumeration of replication_mode I'd think that
the sync standbys are all standby's that operate in a not async mode. That
would be clearer with a boolean sync (or not) and for sync standbys the
replication_mode specified.
You mean that
On Mon, Jul 26, 2010 at 5:27 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Fujii Masao wrote:
Intuitively by looking at the enumeration of replication_mode I'd think
that
the sync standbys are all standby's that operate in a not async mode.
That
would be clearer with a boolean sync (or not)
On Thu, Jul 22, 2010 at 5:37 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Fujii Masao wrote:
How should the synchronous replication behave when the number of connected
standby servers is less than quorum?
1. Ignore quorum. The current patch adopts this. If the ACKs from all
connected
Fujii Masao wrote:
In the following case, how should quorum commit behave?
1. quorum_standbys = 2; there are three connected synchronous standbys
2. One standby sends the ACK back and fails
3. The ACK arrives from another standby
4. How should quorum commit behave?
(a) Transaction commit
Fujii Masao wrote:
I still like
replication_mode = {async|recv|fsync|replay}
rather than
synchronous_replication = {on|off}
acknowledge_commit = {no|recv|fsync|replay}
Hello Fujii,
I wasn't entirely clear. My suggestion was to have only
acknowledge_commit =
On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Fujii Masao wrote:
I still like
replication_mode = {async|recv|fsync|replay}
rather than
synchronous_replication = {on|off}
acknowledge_commit = {no|recv|fsync|replay}
Hello Fujii,
I wasn't entirely
On 7/26/10 1:44 PM +0300, Fujii Masao wrote:
On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havingayebhavi...@gmail.com wrote:
I wasn't entirely clear. My suggestion was to have only
acknowledge_commit = {no|recv|fsync|replay}
instead of
replication_mode = {async|recv|fsync|replay}
Okay, I'll
Jan,
On Sun, 25 Jul 2010, Jan Urbaski wrote:
On 02/07/10 14:33, Teodor Sigaev wrote:
Patch implements much more accuracy estimation of cost for GIN index
scan than generic cost estimation function.
Hi,
I'm reviewing this patch, and to begin with it I tried to reproduce the
problem that
On 26/07/10 12:58, Oleg Bartunov wrote:
Jan,
On Sun, 25 Jul 2010, Jan Urbaski wrote:
On 02/07/10 14:33, Teodor Sigaev wrote:
Patch implements much more accuracy estimation of cost for GIN index
scan than generic cost estimation function.
I was able to reproduce his issue, that is: select
On Mon, Jul 26, 2010 at 6:48 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 7/26/10 1:44 PM +0300, Fujii Masao wrote:
On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havingayebhavi...@gmail.com wrote:
I wasn't entirely clear. My suggestion was to have only
acknowledge_commit =
Markus Wanner mar...@bluegap.ch writes:
To simplify, you might want to start a bgworker on database 'postgres',
which then acts as a sub-coordinator (and doesn't really need to use its
database connection).
Yeah, that sounds like the simplest way forward, so that it's easy for
this user daemon
On Sun, Jul 25, 2010 at 11:29 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
I think RAISE is badly designed. Using % as a placeholder has a limitation
to format strings. For example, format() cannot work as concat():
SELECT format('%%', 123, 456) = ERROR
It's hard to argue with this,
On Mon, Jul 26, 2010 at 12:40 AM, Rajanikant Chirmade
rajanikant.chirm...@enterprisedb.com wrote:
Since discussion stopped in discussion thread
http://archives.postgresql.org/pgsql-bugs/2006-09/msg00128.php
Are there any implications of this change in handling identifiers ?
Thanks Regards,
On Thu, Jul 22, 2010 at 3:09 PM, Markus Wanner mar...@bluegap.ch wrote:
FWIW I don't think you should be thinking in replacing imessages with
SLRU. I rather think you should be thinking in how can you implement
the imessages API on top of SLRU.
Well, I'm rather comparing SLRU with the
On Mon, Jul 26, 2010 at 8:02 AM, Robert Haas robertmh...@gmail.com wrote:
Regardless of where this function ends up, the concat_ws documentation
should contain some mention of the fact that ws is intended to mean
with separator,
big +1 on that -- I've been loosely following the thread and I
CONCAT('foo', NULL) = 'foo' really the behavior that everyone else
implements here? And why does CONCAT() take a variadic ANY
argument? Shouldn't that be variadic TEXT?
CONCAT with variadic text parameter will be limited with existing
default casts to text - for example, you can't to cast
On Mon, Jul 26, 2010 at 9:10 AM, Merlin Moncure mmonc...@gmail.com wrote:
CONCAT('foo', NULL) = 'foo' really the behavior that everyone else
implements here? And why does CONCAT() take a variadic ANY
argument? Shouldn't that be variadic TEXT?
What does that accomplish, besides forcing you
Peter Eisentraut pete...@gmx.net wrote:
In psql's quiet mode, the output of the \timing option is
suppressed,
except in the \copy command. That inconsistency should be fixed in
any
case. It seems to me that if I explicitly turn on timing, then that
should be unaffected by the quiet mode.
Last week, I ran across a situation where I needed to know the SSL
version and cipher in use for a particular database connection.
Magnus pointed me to contrib/sslinfo, but that didn't have quite what
I needed. The attached patch adds two additional functions to
contrib/sslinfo to report this
On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas robertmh...@gmail.com wrote:
Last week, I ran across a situation where I needed to know the SSL
version and cipher in use for a particular database connection.
Magnus pointed me to contrib/sslinfo, but that didn't have quite what
I needed. The
Excerpts from Robert Haas's message of lun jul 26 08:52:46 -0400 2010:
Here's another idea. Instead of making imessages use an SLRU, how
about having it steal pages from shared_buffers? This would require
segmenting messages into small enough chunks that they'd fit, but the
nice part is
On Mon, Jul 26, 2010 at 9:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 9:10 AM, Merlin Moncure mmonc...@gmail.com wrote:
CONCAT('foo', NULL) = 'foo' really the behavior that everyone else
implements here? And why does CONCAT() take a variadic ANY
argument?
On Mon, Jul 26, 2010 at 9:57 AM, Dave Page dp...@pgadmin.org wrote:
On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas robertmh...@gmail.com wrote:
Last week, I ran across a situation where I needed to know the SSL
version and cipher in use for a particular database connection.
Magnus pointed me to
On Mon, Jul 26, 2010 at 10:39 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, Jul 26, 2010 at 9:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 9:10 AM, Merlin Moncure mmonc...@gmail.com wrote:
CONCAT('foo', NULL) = 'foo' really the behavior that everyone else
On Mon, Jul 26, 2010 at 11:07 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 10:39 AM, Merlin Moncure mmonc...@gmail.com wrote:
It was absolutely a good decision because it prevented type inference
in ways that were ambiguous or surprising (for a canonical case see:
On Mon, Jul 26, 2010 at 10:31 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun jul 26 08:52:46 -0400 2010:
Here's another idea. Instead of making imessages use an SLRU, how
about having it steal pages from shared_buffers? This would require
Hi,
On 07/26/2010 04:31 PM, Alvaro Herrera wrote:
Excerpts from Robert Haas's message of lun jul 26 08:52:46 -0400 2010:
Here's another idea. Instead of making imessages use an SLRU, how
about having it steal pages from shared_buffers? This would require
segmenting messages into small enough
On Sat, Jul 24, 2010 at 06:23, Peter Eisentraut pete...@gmx.net wrote:
Another open question I thought of was whether we should put the
dependency record on the pg_index row, or the pg_constraint row, or
perhaps the pg_class row. Right now, it is using pg_index, because that
was easiest to
Hi,
On 07/26/2010 06:33 PM, Robert Haas wrote:
It would be nice to think, for example, that this could be used as
infrastructure for parallel query to stream results back from worker
processes to the backend connected to the user. If you're using 16
processors to concurrently scan 16
On Mon, Jul 26, 2010 at 12:51 PM, Markus Wanner mar...@bluegap.ch wrote:
Dynamically allocating out of a 2MB
segment gives up most of that flexibility.
Absolutely, that's why I'd like to see other modules that use the dynamic
allocator. The more the better.
Right, I agree. The problem is
Hi,
On 07/26/2010 07:16 PM, Robert Haas wrote:
Of course, there are other parts of the system (a whole bunch of them)
that used shared memory also, and perhaps some of those could be
modified to use the dynamic allocator as well. But they're getting by
without it now, so maybe they don't
On Mon, Jul 26, 2010 at 1:50 PM, Markus Wanner mar...@bluegap.ch wrote:
Note however, that a thread based design doesn't have this problem *at all*.
Memory generally is shared (between threads) and you can dynamically
allocate more or less (until Linux' OOM killer hits you.. yet another
Robert Haas robertmh...@gmail.com wrote:
I actually think that memory management is one of the weakest
elements of our current architecture
I'm actually pretty impressed by the memory contexts in PostgreSQL.
Apparently I'm not alone in that, either; a paper by Hellerstein,
Stonebraker, and
On Mon, Jul 26, 2010 at 3:16 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
I actually think that memory management is one of the weakest
elements of our current architecture
I'm actually pretty impressed by the memory contexts in PostgreSQL.
On Thu, Jul 22, 2010 at 10:37:12AM +0200, Yeb Havinga wrote:
Fujii Masao wrote:
Initially I also expected the quorum to behave like described by
Aidan/option 2. Also, IMHO the name quorom is a bit short, like having
maximum but not saying a max_something.
quorum_min_sync_standbys
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 26, 2010 at 9:57 AM, Dave Page dp...@pgadmin.org wrote:
On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas robertmh...@gmail.com wrote:
Any objections to me committing this?
Might wanna fix this first:
+PG_FUNCTION_INFO_V1(ssl_veresion);
On Tue, Jul 27, 2010 at 12:36 PM, Joshua Tolley eggyk...@gmail.com wrote:
Perhaps I'm hijacking the wrong thread for this, but I wonder if the quorum
idea is really the best thing for us. I've been thinking about Oracle's way of
doing things[1]. In short, there are three different modes:
On Mon, Jul 26, 2010 at 8:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 6:48 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 7/26/10 1:44 PM +0300, Fujii Masao wrote:
On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havingayebhavi...@gmail.com wrote:
I wasn't
On Wed, Jul 21, 2010 at 4:36 PM, Fujii Masao masao.fu...@gmail.com wrote:
I was actually hoping to see a patch for these things first, before any of
the synchronous replication stuff. Eliminating the polling loops is
important, latency will be laughable otherwise, and it will help the
43 matches
Mail list logo
