--On 21. Juli 2010 17:16:13 -0400 Robert Haas wrote:
I get the same error message from concurrent CREATE TABLE commands
even without CINE...
S1:
rhaas=# begin;
BEGIN
rhaas=# create table foo (id int);
CREATE TABLE
S2:
rhaas=# begin;
BEGIN
rhaas=# create table foo (id int);
S1:
rhaas=# com
Hi,
first, thanks for the review.
> Hi, I've been reviewing this patch for the last few days. Here it is :
>
> * Submission review
> * Is the patch in context diff format?
> Yes
>
> * Does it apply cleanly to the current CVS HEAD?
> Yes
>
> * Does it include reasonable tests, necessary doc
Hello
2010/7/23 Itagaki Takahiro :
> I'm reviewing contrib part of the string functions patch.
>
> I found an issue in sprintf() to print integer values. In this case,
> 'l' (for long type) is used on *all* platforms. For example,
> SELECT sprintf('%d', 10);
> internally uses
> appendStringInfo(
2010/7/23 Itagaki Takahiro :
> 2010/7/22 Pavel Stehule :
>> I see a SQL/MED security very unclean - it have to be very vell documented :(
>> ERROR: password is required
>> DETAIL: Non-superuser cannot connect if the server does not request a
>> password.
>
> The security model of current FDW hea
I'm reviewing contrib part of the string functions patch.
I found an issue in sprintf() to print integer values. In this case,
'l' (for long type) is used on *all* platforms. For example,
SELECT sprintf('%d', 10);
internally uses
appendStringInfo('%ld', (int64) 10)
But there are some platform
2010/7/23 Itagaki Takahiro :
> 2010/7/21 Pavel Stehule :
>> It is about 2% slower for UTF8 encoding. So it isn't significant for me.
>> I agree with your changes. Thank You very much
>
> Thanks. The core-part is almost ready to commit.
> I'll continue to review the contrib part.
>
> But I found the
(2010/07/23 12:56), Robert Haas wrote:
> 2010/7/22 KaiGai Kohei:
>>> Well, I like SECURITY LABEL better because it's more clear about what
>>> kind of label we're talking about, but if there's consensus on some
>>> other option it's OK with me. Actually, we need to work the security
>>> provider n
(2010/07/23 13:00), Robert Haas wrote:
> 2010/7/22 KaiGai Kohei:
>> Anyway, it is an obvious feature, and seems to me works fine.
>
> So this makes it sound like you like the feature.
>
>> However, it is not clear for me how do we make progress this feature.
>> If we support a command to include
2010/7/22 KaiGai Kohei :
> Anyway, it is an obvious feature, and seems to me works fine.
So this makes it sound like you like the feature.
> However, it is not clear for me how do we make progress this feature.
> If we support a command to include other configuration, it also needs
> to patch on
2010/7/22 KaiGai Kohei :
>> Well, I like SECURITY LABEL better because it's more clear about what
>> kind of label we're talking about, but if there's consensus on some
>> other option it's OK with me. Actually, we need to work the security
>> provider name in there too, I think, so perhaps SECURI
David,
I checked your patch. Then, there are a few comments in the code.
Apart from the discussion in this thread, would you fix them please.
| *** a/src/bin/initdb/initdb.c
| --- b/src/bin/initdb/initdb.c
| *** static char infoversion[100];
| *** 111,116
| --- 111,117
| s
2010/7/21 Pavel Stehule :
> It is about 2% slower for UTF8 encoding. So it isn't significant for me.
> I agree with your changes. Thank You very much
Thanks. The core-part is almost ready to commit.
I'll continue to review the contrib part.
But I found there is a design issue in format() :
Append
2010/7/22 Pavel Stehule :
> I see a SQL/MED security very unclean - it have to be very vell documented :(
> ERROR: password is required
> DETAIL: Non-superuser cannot connect if the server does not request a
> password.
The security model of current FDW heavily depends on implementation of
exis
(2010/07/23 10:05), Robert Haas wrote:
> 2010/7/22 KaiGai Kohei:
>> Thanks for your reviewing.
>>> 1. I am inclined to suggest the syntax SECURITY LABEL ON ... IS ...,
>>> following COMMENT ON (it's also somewhat similar to the GRANT syntax).
>>>While the hook in ExecCheckRTPerms() will only al
2010/7/22 KaiGai Kohei :
> Thanks for your reviewing.
>> 1. I am inclined to suggest the syntax SECURITY LABEL ON ... IS ...,
>> following COMMENT ON (it's also somewhat similar to the GRANT syntax).
>> While the hook in ExecCheckRTPerms() will only allow meaningful
>> permissions checks on the u
Thanks for your reviewing.
(2010/07/23 0:54), Robert Haas wrote:
> 2010/7/14 KaiGai Kohei:
>> The attached patch is a part of efforts to support security label
>> on database objects.
>
> This is similar to what I had in mind as a design for this feature,
> but I have some gripes:
>
> 1. I am in
On Thu, Jul 22, 2010 at 5:34 PM, Kris Jurka wrote:
> Per discussion and investigation on the -jdbc list, the server appears to
> violate the frontend/backend protocol when binary copy data is sent to the
> server. Upon receiving the binary copy end of data marker (a -1 field
> count), the server
On Thu, Jul 22, 2010 at 6:56 PM, Jan Urbański wrote:
> the rest are just stylistic nitpicks.
But, if the patch author doesn't fix them, the committer has to, so
your nitpicking is much appreciated, at least by me!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres
On 21/07/10 14:43, Pavel Stehule wrote:
> Hello
>
> I am sending a actualised patch.
Hi, thanks!
> I understand to your criticism about line numbering. I have to
> agree. With line numbering the patch is longer. I have a one
> significant reason for it.
> CREATE OR REPLACE FUNCTION public
Hello,
At least from a performance point of view CINE should never cause a table
rewrite, it should either execute as a plain CREATE or as "nothing". I don't
mind if the CINE fails if the column already exists but with a different
definition, so maybe it could be worded differently to make it c
Per discussion and investigation on the -jdbc list, the server appears to
violate the frontend/backend protocol when binary copy data is sent to the
server. Upon receiving the binary copy end of data marker (a -1 field
count), the server immediately responds with CommandComplete and
ReadyFor
On ons, 2010-07-21 at 22:12 -0700, Jeff Davis wrote:
> The two functions aren't perfectly symmetric, because
> pg_stat_get_backend_server_port() returns -1 if it's a unix socket,
> and
> pg_stat_get_backend_server_addr() returns NULL (which is also
> overloaded
> to mean that you don't have permis
On ons, 2010-07-21 at 15:48 -0400, Alvaro Herrera wrote:
> Excerpts from Peter Eisentraut's message of mié jul 21 15:18:58 -0400 2010:
> > After some investigation I figured that I need to add two more checks
> > into the ALTER TABLE code to prevent certain types of direct changes to
> > typed tabl
Robert Haas wrote:
>> 18 patches have reviews due within four days or less
>
> This is a very big number... I hope some of these reviews start to
> come in soon. I think this is where our bottleneck is at present.
Based on off-list emails, I expect most of these to clear by this
weekend. P
On Wed, Jul 21, 2010 at 02:38:17PM -0400, Merlin Moncure wrote:
> On Wed, Jul 21, 2010 at 2:28 PM, Robert Haas wrote:
> > Yeah, I'd like some more votes, too. Aside from what I suggested
> > (array_join/array_split), I think my favorite is your #5.
>
> -1 for me for any name that is of the form
Hi,
On 07/22/2010 08:31 PM, Alvaro Herrera 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 dynamic allocator. So far I
On Thu, Jul 22, 2010 at 12:38 PM, vamsi krishna
wrote:
> if lev=5 , and let's say there are two combinations setA = {1,2,3,4,5} and
> set B={6,7,8,9,10}.
>
> I want to reuse the plan of {1.2,3,4,5} for {6,7,8,9,10}.
I don't think that makes any sense.
--
Robert Haas
EnterpriseDB: http://www.ent
On Thu, Jul 22, 2010 at 2:09 PM, Kevin Grittner
wrote:
> 48 pending
> 8 ready for committer
Note that all of the patches except one which are marked as "Ready for
Committer" were either submitted by a committer, or the reviewer is a
committer. Of those, 3 are mine. Two of those are patches I'm
Excerpts from Markus Wanner's message of jue jul 22 08:49:29 -0400 2010:
> Of course, as mentioned in the bgworker patch, this could be done
> differently. Using solely shared memory, or maybe SLRU to store change
> sets. However, I certainly like the abstraction and guarantees such a
> message
New numbers on where we are with this CommitFest:
71 patches were submitted
3 patches were withdrawn (deleted) by their authors
--
68 total patches currently in the application
--
3 committed to 9.0
--
65 9.1 patches
--
1 rejected
5 returned with feedback
11 committed for 9.1
--
17 9.1 patche
Hi,
From the code I understood that when executing a query "normally", in
READ COMMITTED mode, we take a new snapshot for every query that comes
out of rewrite. But in an EXPLAIN ANALYZE, we only update the CID of
the snapshot taken when the EXPLAIN started.
Did I misunderstand the code? A
Hi everybody
I am doing a modification to Dynamic programming algorithm in postgreSQL. I
want to re-use a plan of one " joinrels" for another of the same level.
For example,
if lev=5 , and let's say there are two combinations setA = {1,2,3,4,5} and
set B={6,7,8,9,10}.
I want to reuse the plan of
On Thu, 2010-07-01 at 16:30 +, Leonardo F wrote:
> To sum up: IMHO nor improvements in memory usage nor
> in startup time would be good reasons to switch to bitmap
> indexes... but bulk index creation time (10 minutes to index
> what it takes 60 minutes with btree... and maybe more if tables
2010/7/14 KaiGai Kohei :
> The attached patch is a part of efforts to support security label
> on database objects.
This is similar to what I had in mind as a design for this feature,
but I have some gripes:
1. I am inclined to suggest the syntax SECURITY LABEL ON ... IS ...,
following COMMENT ON
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
Greg,
On 07/22/2010 03:59 PM, Greg Smith wrote:
There's a fairly good mapping of what techniques are patented and which
were only mentioned in research in the Sun dynamic memory patent at
http://www.freepatentsonline.com/7328316.html ; that mentions an earlier
paper by the author of the techniqu
Hello
I see a SQL/MED security very unclean - it have to be very vell documented :(
I have a database on port 5401. With user Tom - it require a password
[pa...@nemesis pgsql]$ psql-dev1 postgres -U tom
Password for user tom:
Timing is on.
psql-dev1 (9.0devel)
Type "help" for help.
postgres=>
20.07.2010 18:31, Robert Haas:
According to the EXPLAIN ANALYZE output, your "slow" query is
executing in 0.007 ms, and your "fast" query is executing in 0.026 ms
(i.e. not as quickly as the slow query). Since you mention that it
takes 7 s further down, I suspect this is not the real EXPLAIN AN
On Thu, Jul 22, 2010 at 1:59 AM, Robert Haas wrote:
> Ah, I see. That's pretty compelling, I guess. Although it still
> seems like a lot of code...
>
I think there is a way to merge single-byte and multi-byte versions of
functions without loss in performance using macros and includes (like in
'
Such version with macros and includes can look like this:
#ifdef MULTIBYTE
#define NEXT_X (x+= char_lens[i-1])
#define NEXT_Y (y+= y_char_len)
#define CMP (char_cmp(x, char_lens[i-1], y, y_char_len))
#else
#define NEXT_X (x++)
#define NEXT_Y (y++)
#define CMP (*x == *y)
#endif
static int
levensht
Markus Wanner wrote:
On 07/20/2010 09:05 PM, Alvaro Herrera wrote:
Hmm, deriving code from a paper published by IBM sounds like bad news --
who knows what patents they hold on the techniques there?
Yeah, that might be an issue. Note, however, that the lock-based
variant differs substantially
On Thu, Jul 22, 2010 at 3:21 AM, Alexander Korotkov
wrote:
> On Thu, Jul 22, 2010 at 1:59 AM, Robert Haas wrote:
>>
>> Ah, I see. That's pretty compelling, I guess. Although it still
>> seems like a lot of code...
>
> I think there is a way to merge single-byte and multi-byte versions of
> func
On Wed, Jul 21, 2010 at 11:06 PM, David Christensen wrote:
>
> On Jul 21, 2010, at 12:31 PM, Alvaro Herrera wrote:
>
>> Excerpts from Peter Eisentraut's message of mié jul 21 10:24:26 -0400 2010:
>>> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
It's tempting to propose making .psqlrc
On Thu, Jul 22, 2010 at 1:41 AM, Fujii Masao wrote:
> We should enclose -1 with tag.
A quick survey of the documentation as a whole suggests that we
enclose -1 with in a few places but more commonly we don't.
I have no position on whether we should do it or not, but maybe we
should try to be co
Hi,
On 07/22/2010 01:04 PM, Robert Haas wrote:
Well, shared_buffers has to be allocated as one contiguous slab
because we index into it that way. So I don't really see how
dynamically allocating memory could help. What you'd need is a
different system for assigning buffer tags, so that a parti
On Thu, Jul 22, 2010 at 3:01 AM, Markus Wanner wrote:
> On 07/22/2010 12:11 AM, Robert Haas wrote:
>>
>> I'm not sure why merging the SLRU pools with shared_buffers would
>> benefit from dynamically allocated shared memory.
>
> Well, I'm not sure how you'd merge SLRU pools with shared_buffers. IMO
On Thu, Jul 22, 2010 at 5:41 AM, Magnus Hagander wrote:
> On Thu, Jul 22, 2010 at 11:33, Peter Eisentraut wrote:
>> On tor, 2010-07-22 at 09:18 +0100, Dave Page wrote:
>>> On Thu, Jul 22, 2010 at 9:11 AM, Magnus Hagander
>>> wrote:
>>> > On Thu, Jul 22, 2010 at 10:04, Dave Page wrote:
>>> >> O
On Thu, Jul 22, 2010 at 11:33, Peter Eisentraut wrote:
> On tor, 2010-07-22 at 09:18 +0100, Dave Page wrote:
>> On Thu, Jul 22, 2010 at 9:11 AM, Magnus Hagander wrote:
>> > On Thu, Jul 22, 2010 at 10:04, Dave Page wrote:
>> >> On Wed, Jul 21, 2010 at 5:54 PM, Robert Haas
>> >> wrote:
>> >>> We
On ons, 2010-07-21 at 23:06 +0200, Dimitri Fontaine wrote:
> Alvaro Herrera writes:
> > This does not work as cleanly as you suppose, because some "build
> > objects" are stored in the source tree. configure being one of them.
> > So if you switch branches, configure is rerun even in a VPATH buil
On tor, 2010-07-22 at 09:18 +0100, Dave Page wrote:
> On Thu, Jul 22, 2010 at 9:11 AM, Magnus Hagander wrote:
> > On Thu, Jul 22, 2010 at 10:04, Dave Page wrote:
> >> On Wed, Jul 21, 2010 at 5:54 PM, Robert Haas wrote:
> >>> We need to decide what email addresses committers will use on the new
>
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 standbys have arrived, transaction commit is successful
even if the number of s
On Thu, Jul 22, 2010 at 9:11 AM, Magnus Hagander wrote:
> On Thu, Jul 22, 2010 at 10:04, Dave Page wrote:
>> On Wed, Jul 21, 2010 at 5:54 PM, Robert Haas wrote:
>>> We need to decide what email addresses committers will use on the new
>>> git repository when they commit.
>>
>> Are you are aware
On Thu, Jul 22, 2010 at 10:04, Dave Page wrote:
> On Wed, Jul 21, 2010 at 5:54 PM, Robert Haas wrote:
>> We need to decide what email addresses committers will use on the new
>> git repository when they commit.
>
> Are you are aware that we already have a list of "approved" addresses
> for the co
On Wed, Jul 21, 2010 at 5:54 PM, Robert Haas wrote:
> We need to decide what email addresses committers will use on the new
> git repository when they commit.
Are you are aware that we already have a list of "approved" addresses
for the committers?
--
Dave Page
EnterpriseDB UK: http://www.enter
On 07/22/2010 07:42 AM, Guillaume Lelarge wrote:
Le 21/07/2010 23:23, Andreas Joseph Krogh a écrit :
[...]
I was googling for how to create a text-seach-config with the following
properties:
- Map unicode accentuated letters to an un-accentuated equivalent
- No stop-words
- Lowercase all wor
On 21/07 06.57, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 10:52 PM, Amber wrote:
> > I am trying to build RPostgreSQL on Solaris 10u7 X64, but have problems
> > with pg_config, the configure script of RPostgreSQL checks for pg_config and
> > got ?checking for pg_config... /usr/bin/pg_config?.
Hi,
On 07/22/2010 12:11 AM, Robert Haas wrote:
I'm not sure why merging the SLRU pools with shared_buffers would
benefit from dynamically allocated shared memory.
Well, I'm not sure how you'd merge SLRU pools with shared_buffers. IMO
that inherently leads to the problem of allocating memory d
57 matches
Mail list logo
