2010/7/8 Tom Lane :
> Pavel Stehule writes:
>> 2010/7/8 Robert Haas :
>>> A precompiler can give you all the same memory management benefits.
>
>> I use mmap(). And with mmap the precompiler are not necessary.
>> Dictionary is loaded only one time - in original ispell format. I
>> think, it is mu
(2010/07/07 11:31), Robert Haas wrote:
> On Tue, Jul 6, 2010 at 10:18 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Obviously not. We don't need to acquire an AccessExclusiveLock to
>>> comment on an object - just something that will CONFLICT WITH an
>>> AccessExclusiveLock. So, use the same l
Robert Haas writes:
>>> How long should I wait before I start breaking things?
>>
>> Did you have any particular breakage in mind?
> Well, you can see for yourself what I've submitted for the next CF.
You might want to hold off on the get_whatever_oid patches for a bit,
but the other stuff I se
On Fri, Jul 9, 2010 at 12:31 AM, Tom Lane wrote:
> Robert Haas writes:
>>> Stamp HEAD as 9.1devel.
>>> (And there was much rejoicing.)
>
>> /me opens a beer.
>
>> How long should I wait before I start breaking things?
>
> Did you have any particular breakage in mind?
>
> I'm hesitant to have a wh
Robert Haas writes:
>> Stamp HEAD as 9.1devel.
>> (And there was much rejoicing.)
> /me opens a beer.
> How long should I wait before I start breaking things?
Did you have any particular breakage in mind?
I'm hesitant to have a whole lot of variance between REL9_0_STABLE and
HEAD just yet, sin
On Jul 8, 2010, at 9:20 PM, Robert Haas wrote:
> /me opens a beer.
>
> How long should I wait before I start breaking things?
I should think that you would need to drink at least 5-6 beers before you
started stumbling around and breaking shit.
David
--
Sent via pgsql-hackers mailing list (
On Fri, Jul 9, 2010 at 12:03 AM, Mark Kirkwood
wrote:
> On 09/07/10 15:57, Robert Haas wrote:
>>
>> Hmm. Well, those numbers seem awfully high, for what you're doing,
>> then. An admission control mechanism that's just letting everything
>> in shouldn't knock 5% off performance (let alone 30%).
On Fri, Jul 9, 2010 at 12:10 AM, Tom Lane wrote:
> Log Message:
> ---
> Stamp HEAD as 9.1devel.
> (And there was much rejoicing.)
/me opens a beer.
How long should I wait before I start breaking things?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Co
Robert Haas writes:
> Before we begin this experiment, we need to stamp HEAD as 9.1devel.
Done.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 8, 2010 at 11:58 PM, Marc G. Fournier
wrote:
>
> As decided at this years hackers conference, we are branching REL9_0_STABLE
> *before* the release, instead of after.
>
> The hope is that we won't be taking away resources from finishing the
> release, but still allow ppl to continue to
On 09/07/10 15:57, Robert Haas wrote:
Hmm. Well, those numbers seem awfully high, for what you're doing,
then. An admission control mechanism that's just letting everything
in shouldn't knock 5% off performance (let alone 30%).
Yeah it does, on the other hand both Josh and I were trying
As decided at this years hackers conference, we are branching
REL9_0_STABLE *before* the release, instead of after.
The hope is that we won't be taking away resources from finishing the
release, but still allow ppl to continue to work on projects that are for
9.1.
The branch is now created
On Thu, Jul 8, 2010 at 11:00 PM, Mark Kirkwood
wrote:
> On 09/07/10 14:26, Robert Haas wrote:
>>
>> On Thu, Jul 8, 2010 at 10:21 PM, Mark Kirkwood
>> wrote:
>>
>>>
>>> Purely out of interest, since the old repo is still there, I had a quick
>>> look at measuring the overhead, using 8.4's pgbench
(2010/07/08 22:08), Robert Haas wrote:
> I think we pretty much have conceptual agreement on the shape of the
> solution to this problem: when a view is created with CREATE SECURITY
> VIEW, restrict functions and operators that might disclose tuple data
> from being pushed down into view (unless, p
(2010/07/03 1:39), Andrew Dunstan wrote:
>
>
> Peter Eisentraut wrote:
Is there any possibilities that both WIN32 and HAVE_UNIX_SOCKETS are
set concurrently? If possible, the libpq may try to call undefined
function, then build will be failed.
>>> Win32 never has HAVE_UNIX_SOCKET.
Sorry for the late responding.
It looks good to me that the point (1) and (4) are fixed.
The (2) and (3) are depending on individual subjective sense,
so it will be no problem, if we decide not to clean them up at
the same time.
Elsewhere, I noticed one other stuff related to naming convention.
On 09/07/10 14:26, Robert Haas wrote:
On Thu, Jul 8, 2010 at 10:21 PM, Mark Kirkwood
wrote:
Purely out of interest, since the old repo is still there, I had a quick
look at measuring the overhead, using 8.4's pgbench to run two custom
scripts: one consisting of a single 'SELECT 1', the oth
2010/7/8 Pavel Stehule :
> sorry, attached fixed patch
Make installcheck for contrib/stringfunc is broken.
Please run regression test with --enable-cassert build.
test stringfunc ... TRAP:
FailedAssertion("!(!lc_ctype_is_c())", File: "mbutils.c", Line: 715)
LOG: server process (PID
On Thu, Jul 8, 2010 at 10:21 PM, Mark Kirkwood
wrote:
> Purely out of interest, since the old repo is still there, I had a quick
> look at measuring the overhead, using 8.4's pgbench to run two custom
> scripts: one consisting of a single 'SELECT 1', the other having 100 'SELECT
> 1' - the latter
On 09/07/10 12:58, Mark Kirkwood wrote:
On 09/07/10 05:10, Josh Berkus wrote:
Simon, Mark,
Actually only 1 lock check per query, but certainly extra processing
and
data structures to maintain the pool information... so, yes certainly
much more suitable for DW (AFAIK we never attempted to meas
On 09/07/10 05:10, Josh Berkus wrote:
Simon, Mark,
Actually only 1 lock check per query, but certainly extra processing and
data structures to maintain the pool information... so, yes certainly
much more suitable for DW (AFAIK we never attempted to measure the
additional overhead for non DW wor
(2010/07/08 23:58), Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I'm not sure what the best thing to do about this is. I think it
>> might be a good idea to start with some discussion of what problems
>> people are trying to solve (hopefully N> 1?) and then try to figure
On Thu, 2010-07-08 at 06:08 -0400, Robert Haas wrote:
> On Thu, Jul 8, 2010 at 2:16 AM, Simon Riggs wrote:
> > On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote:
> >> Rereading the thread, I'm a bit confused by why we're proposing to use
> >> a SHARE lock; it seems to me that a self-conflicting
Peter Eisentraut writes:
> So, clang 2.7 didn't fix it. Do we want to proceed with my patch or
> leave clang unsupported?
Given that the patch breaks plperl, I'd vote no ... but in any case
right now is not the time to be applying it. Maybe it would be useful
to put it in HEAD after we branch 9
On fre, 2010-06-25 at 15:49 -0400, Peter Eisentraut wrote:
> For the record, here is a patch that would address these issues.
>
> At the moment, I'm waiting to get my hands on the new version 2.7 of
> clang to see if some of these issues have gone away.
>
> Considering that clang already helped u
Robert Haas writes:
> On Thu, Jul 8, 2010 at 3:05 PM, Tom Lane wrote:
>> Right, but look for example at the logic involved with the current outer
>> join transformation identity #3, which can't be applied unless the join
>> predicate is strict for the left-hand side. We avoid doing the dogwork
>
On Thu, Jul 8, 2010 at 3:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 8, 2010 at 2:48 PM, Tom Lane wrote:
>>> I think it might work out better if you ask "what
>>> additional conditions are needed in order to prove that this inner join
>>> can commute with this left join", and the
I think it might work out better if you ask "what
> additional conditions are needed in order to prove that this inner join
> can commute with this left join", and then work at being able to prove
> that. (It's entirely likely that the planner isn't currently gathering
> the right information fo
Robert Haas writes:
> On Thu, Jul 8, 2010 at 2:48 PM, Tom Lane wrote:
>> I think it might work out better if you ask "what
>> additional conditions are needed in order to prove that this inner join
>> can commute with this left join", and then work at being able to prove
>> that. (It's entirely
On Thu, Jul 8, 2010 at 2:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> Consider:
>
>> SELECT * FROM foo LEFT JOIN (bar JOIN baz ON bar.y = baz.y) ON foo.x = bar.x;
>
>> If foo is itty bitty and bar and baz are enormous, it would be nice to
>> start by joining foo to bar and then joining the res
Robert Haas writes:
> Consider:
> SELECT * FROM foo LEFT JOIN (bar JOIN baz ON bar.y = baz.y) ON foo.x = bar.x;
> If foo is itty bitty and bar and baz are enormous, it would be nice to
> start by joining foo to bar and then joining the result to baz, but
> that's not legal. However, if bar (y)
On ons, 2010-07-07 at 17:31 -0400, Tom Lane wrote:
> Yeah, I was going to suggest something involving
> find_rendezvous_variable to let the two versions of plpython check for
> each other. But doesn't the error need to be elog(FATAL)? If you
> just
> elog(ERROR) then the conflicting version of py
So I sat down to work on some code to do inner join removal, and
quickly got stuck. As a first step, I wanted to write some code that
would identify inner joins that could be treated as LEFT JOINs if we
so chose. Consider:
SELECT 1 FROM foo, bar WHERE foo.x = bar.x;
If it so happens that there
Simon, Mark,
Actually only 1 lock check per query, but certainly extra processing and
data structures to maintain the pool information... so, yes certainly
much more suitable for DW (AFAIK we never attempted to measure the
additional overhead for non DW workload).
I recall testing it when the
On Thu, Jul 8, 2010 at 12:44 PM, Kevin Grittner
wrote:
> Nice comments later in the email, though; I hope you won't mind if
> you find excerpts popping up in the code review Wiki pages. ;-)
Not at all. Go for it...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgr
Robert Haas wrote:
> Kevin Grittner wrote:
>>> or had major design issues
>>
>> That's a much harder problem. The set of people who can review
>> for that is rather smaller than the set who can see if a patch
>> applies without error.
>
> Well, true. But reporting whether the patch applies w
Dne 8.7.2010 12:33, Robert Haas napsal(a):
2010/6/29 Pavel Baroš:
Yeah, it is my fault, I did not mentioned that this patch is not final. It
is only small part of whole implementation. I wanted to show just this,
because I think that is the part that should not change much. And to show I
did
On Thu, Jul 8, 2010 at 11:36 AM, Kevin Grittner
wrote:
>> or had major design issues
>
> That's a much harder problem. The set of people who can review for
> that is rather smaller than the set who can see if a patch applies
> without error.
Well, true. But reporting whether the patch applies w
On Thu, Jul 8, 2010 at 18:06, Magnus Hagander wrote:
> On Thu, Jul 8, 2010 at 17:45, Andrew Dunstan wrote:
>>
>>
>> Tom Lane wrote:
>>>
>>> Magnus Hagander writes:
>>>
Seems pretty simple - mingw doesn't have support for this. We have two
ways to deal with that I think:
1) Di
On Thu, Jul 8, 2010 at 17:45, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>
>> Magnus Hagander writes:
>>
>>>
>>> Seems pretty simple - mingw doesn't have support for this. We have two
>>> ways to deal with that I think:
>>> 1) Disable it on mingw.
>>> 2) Include it in our custom headers.
>>>
>>
Joshua Tolley writes:
> I noticed the following out-of-date bits in a comment in xlogutils.c:
Removing the comment altogether doesn't seem appropriate. I changed it
to
* (Getting the buffer lock is not really necessary during single-process
* crash recovery, but some subroutines such as MarkB
I noticed the following out-of-date bits in a comment in xlogutils.c:
* LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE), for reading from the main
* fork.
*
- * (Getting the lock is not really necessary, since we expect that this is
- * only used during single-process XLOG replay, but some su
Tom Lane wrote:
Magnus Hagander writes:
Seems pretty simple - mingw doesn't have support for this. We have two
ways to deal with that I think:
1) Disable it on mingw.
2) Include it in our custom headers.
For #2, what we need to include is the define of SIO_KEEPALIVE_VALS as
well
On Thu, Jul 8, 2010 at 17:39, Tom Lane wrote:
> Magnus Hagander writes:
>> Seems pretty simple - mingw doesn't have support for this. We have two
>> ways to deal with that I think:
>> 1) Disable it on mingw.
>> 2) Include it in our custom headers.
>
>> For #2, what we need to include is the defin
On Thu, Jul 8, 2010 at 17:11, Magnus Hagander wrote:
> On Thu, Jul 8, 2010 at 17:04, Tom Lane wrote:
>> m...@postgresql.org (Magnus Hagander) writes:
>>> Log Message:
>>> ---
>>> Add support for TCP keepalives on Windows, both for backend and the new
>>> libpq support.
>>
>> Buildfarm mem
Magnus Hagander writes:
> Seems pretty simple - mingw doesn't have support for this. We have two
> ways to deal with that I think:
> 1) Disable it on mingw.
> 2) Include it in our custom headers.
> For #2, what we need to include is the define of SIO_KEEPALIVE_VALS as
> well as the definition of
Robert Haas wrote:
> Last year, the first CommitFest involved returning with feedback
> a lot of patches that had horribly bitrotted
That's an excellent point. If there is anyone out there who could
do an initial run to kick back patches with bitrot in the next week
or so, that would be a tre
* Robert Haas (robertmh...@gmail.com) wrote:
> I'm not sure what the best thing to do about this is. I think it
> might be a good idea to start with some discussion of what problems
> people are trying to solve (hopefully N > 1?) and then try to figure
> out what a good solution might look like.
On Thu, Jul 8, 2010 at 10:48 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I think we have to assume that whatever actions a pluggable security
>> provider might take at authentication time are going to be based on
>> information from outside the database.
>
> I feel t
* Robert Haas (robertmh...@gmail.com) wrote:
> I think we have to assume that whatever actions a pluggable security
> provider might take at authentication time are going to be based on
> information from outside the database.
I feel that would be perfect for 9.1 and supporting access to the
gener
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Maybe so, but the proposed hook placement doesn't actually allow a
> plugin module to be "involved" in the authorization --- we've already
> decided the authorization is OK. All it can do there is some additional
> initialization, which could equally well b
On Thu, Jul 8, 2010 at 9:37 AM, Stephen Frost wrote:
>> FWIW, I am still of the opinion that we shouldn't have a hook here
>> anyway, because there is no reason to complain about lack of a
>> security context until the user performs an action which requires them
>> to have a security context.
>
>
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> FWIW, I am still of the opinion that we shouldn't have a hook here
>> anyway, because there is no reason to complain about lack of a
>> security context until the user performs an action which requires them
>> to have a securi
Pavel Stehule writes:
> 2010/7/8 Robert Haas :
>> A precompiler can give you all the same memory management benefits.
> I use mmap(). And with mmap the precompiler are not necessary.
> Dictionary is loaded only one time - in original ispell format. I
> think, it is much more simple for administr
On Thu, Jul 8, 2010 at 9:32 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Who is going to manage the actual CF?
>
> I'm willing to do so if people want that. I promise to be more
> aggressive about pursuing this once the release is out; I've seen
> some of the same people who are doing rev
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> 2010/6/16 KaiGai Kohei :
> > OK, fair enough. Please wait for a few days.
> > I'll introduce the proof-of-concept module until this week.
>
> I think we have decided not to pursue this, at least for now. If that
> is the case, the CommitFest
Robert Haas wrote:
> Who is going to manage the actual CF?
I'm willing to do so if people want that. I promise to be more
aggressive about pursuing this once the release is out; I've seen
some of the same people who are doing reviews contributing to the
release process, so I haven't wanted to
On Thu, Jul 8, 2010 at 9:22 AM, Robert Haas wrote:
> On Thu, Jul 8, 2010 at 9:09 AM, Pavel wrote:
>> Any update on this?
>>
>> Sure, sorry for delay, I updated code on http://github.com/pbaros/postgres
>> just a few minutes ago. Today I'll post patch here on HACKERS with my
>> comments.
>
> It's
On Thu, Jul 8, 2010 at 9:09 AM, Pavel wrote:
> Any update on this?
>
> Sure, sorry for delay, I updated code on http://github.com/pbaros/postgres
> just a few minutes ago. Today I'll post patch here on HACKERS with my
> comments.
It's a little hard for me to understand what's going on via the git
2010/6/16 KaiGai Kohei :
> OK, fair enough. Please wait for a few days.
> I'll introduce the proof-of-concept module until this week.
I think we have decided not to pursue this, at least for now. If that
is the case, the CommitFest entry should be updated to Returned with
Feedback.
https://commi
I think we pretty much have conceptual agreement on the shape of the
solution to this problem: when a view is created with CREATE SECURITY
VIEW, restrict functions and operators that might disclose tuple data
from being pushed down into view (unless, perhaps, the user invoking
the view has sufficie
2010/7/8 Robert Haas :
> On Thu, Jul 8, 2010 at 7:03 AM, Pavel Stehule wrote:
>> 2010/7/8 Robert Haas :
>>> On Wed, Jul 7, 2010 at 10:50 PM, Takahiro Itagaki
>>> wrote:
This patch allocates memory with non-file-based mmap() to preload text
search
dictionary files at the server sta
On Thu, Jul 8, 2010 at 7:03 AM, Pavel Stehule wrote:
> 2010/7/8 Robert Haas :
>> On Wed, Jul 7, 2010 at 10:50 PM, Takahiro Itagaki
>> wrote:
>>> This patch allocates memory with non-file-based mmap() to preload text
>>> search
>>> dictionary files at the server start. Note that dist files are no
2010/7/8 Robert Haas :
> On Wed, Jul 7, 2010 at 10:50 PM, Takahiro Itagaki
> wrote:
>> This patch allocates memory with non-file-based mmap() to preload text search
>> dictionary files at the server start. Note that dist files are not mmap'ed
>> directly in the patch; mmap() is used for reallocata
2010/6/29 Pavel Baroš :
> Yeah, it is my fault, I did not mentioned that this patch is not final. It
> is only small part of whole implementation. I wanted to show just this,
> because I think that is the part that should not change much. And to show I
> did something, I am not ignoring GSoC. Now I
On Wed, Jul 7, 2010 at 15:32, Robert Haas wrote:
> On Wed, Jul 7, 2010 at 9:20 AM, Magnus Hagander wrote:
>> On Wed, Jun 30, 2010 at 17:46, Tom Lane wrote:
>>> "Kevin Grittner" writes:
I also think we may want to suggest that for most environments,
people may want to change these sett
On Thu, Jul 8, 2010 at 2:16 AM, Simon Riggs wrote:
> On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote:
>> Rereading the thread, I'm a bit confused by why we're proposing to use
>> a SHARE lock; it seems to me that a self-conflicting lock type would
>> simplify things. There's a bunch of discu
On Wed, Jul 7, 2010 at 10:50 PM, Takahiro Itagaki
wrote:
> This patch allocates memory with non-file-based mmap() to preload text search
> dictionary files at the server start. Note that dist files are not mmap'ed
> directly in the patch; mmap() is used for reallocatable shared memory.
I thought
Hello
I found a page http://www.genesys-e.org/jwalter//mix4win.htm where is
section >>Emulation of mmap/munmap<<. Can be a solution?
Regards
Pavel Stehule
2010/7/8 Pavel Stehule :
> Hello
>
> 2010/7/8 Takahiro Itagaki :
>>
>> Pavel Stehule wrote:
>>
>>> this version has enhanced AllocSet alloc
On Thu, Jul 8, 2010 at 5:27 PM, Magnus Hagander wrote:
> In this scenario, wouldn't it work if the *ssh connection* had
> keepalives enabled though? Then that one should tear down, which in
> turn would send a clear signal to libpq the connection is gone.
Sorry, I'm not sure that. Can the ssh con
Hello
2010/7/8 Takahiro Itagaki :
>
> Pavel Stehule wrote:
>
>> this version has enhanced AllocSet allocator - it can use a mmap API.
>
> I review your patch and will report some comments. However, I don't have
> test cases for the patch because there is no large dictionaries in the
> default po
On Thu, Jul 8, 2010 at 10:23, Fujii Masao wrote:
> On Thu, Jul 8, 2010 at 4:57 PM, Pavel Golub wrote:
>> Sounds good for me. My customer proposed such a scenario:
>>
>> I have opened connection to database server (ver 8.4.3) through the
>> SSH tunnel. This tunnel is created by external program "P
On Thu, Jul 8, 2010 at 4:57 PM, Pavel Golub wrote:
> Sounds good for me. My customer proposed such a scenario:
>
> I have opened connection to database server (ver 8.4.3) through the
> SSH tunnel. This tunnel is created by external program "PUTTY". My PC running
> Application
> is connected to th
Hello, Fujii.
You wrote:
FM> On Wed, Jul 7, 2010 at 10:04 PM, Robert Haas wrote:
>> On Tue, Jul 6, 2010 at 1:08 PM, Pavel Golub wrote:
>>> While I'm very excited about enabling keepalives in libpq, I want to
>>> know how can I use this functionality in my application?
>>>
>>> Let's imagine that
On Thu, Jul 8, 2010 at 7:55 AM, Robert Haas wrote:
>> What was the final decision on behavior if fsync=off?
>
> I'm not sure we made any decision, per se, but if you use fsync=off in
> combination with SR and experience an unexpected crash-and-reboot on
> the master, you will be sad.
True. But, w
Pavel Stehule wrote:
> updated version, concat function doesn't use separator
BTW, didn't you forget stringfunc.sql.in for contrib/stringfunc ?
So, I have not check stringfunc module yet.
I reviewed your patch, and format() in the core is almost ok. It's very cool!
On the other hand, contrib/s
76 matches
Mail list logo
