On 11/27/2011 04:39 PM, Ants Aasma wrote:
On the AMD I saw about 3% performance drop with timing enabled. On the
Intel machine I couldn't measure any statistically significant change.
Oh no, it's party pooper time again. Sorry I have to be the one to do
it this round. The real problem with t
On Mon, Nov 28, 2011 at 3:00 AM, Tom Lane wrote:
> I see your point that we only need the penalty values to be comparable
> for the same "new" value, but I don't think that really answers my
> objection, because you've had to lobotomize the logic. As an example,
> if we have a new empty range to
On Sun, Nov 27, 2011 at 12:12:41PM -0800, David E. Wheeler wrote:
> On Nov 27, 2011, at 6:11 AM, Andrew Dunstan wrote:
>
> >> Has this been backpatched as well?
> >
> > It has been to 9.1.
>
> There may be a simple workaround, but it's non-obvious. I think it should be
> back-patched all the wa
Attached are the results from performing a similar process to the
prior benchmark, but on Greg Smith's high-end server, and with an
orderlines table that has been "doubled-up" until it is 1538 MB,
making the same old query perform a quicksort that's over 3GB. Short
version: HEAD is 20468.0ms, with
On Sun, Nov 27, 2011 at 10:28 AM, Alexander Soudakov wrote:
> Hello.
>
> I finished developing www_fdw:
> https://github.com/cyga/www_fdw/
>
> It has docs/examples:
> https://github.com/cyga/www_fdw/wiki
>
> I haven't upload it to pgxn or pgfoundry yet.
>
> I want to ask for the following 2 things
On 11/27/2011 06:17 PM, Tom Lane wrote:
Peter Eisentraut writes:
I've committed it now, and some buildfarm members are failing with lack
of shared memory, semaphores, or disk space. Don't know what to do with
that or why so many are failing like that. We could create a way to
omit the test
Alexander Korotkov writes:
> On Sun, Nov 27, 2011 at 10:43 PM, Tom Lane wrote:
>> 1. penalty is using both hard-wired penalty values (1.0, 2.0, etc) and
>> values obtained from subtype_diff. This is not good, because you have
>> no idea what scale the subtype differences will be expressed on. T
Peter Eisentraut writes:
> CATALOG(pg_attribute,1249) BKI_BOOTSTRAP ...
> {
> ...
> int4attinhcount;
> Oid attcollation;
> aclitem attacl[1];
> CATVARLEN(
> textattoptions[1];
> textattfdwoptions[1];
> )
> } FormData_pg_attribute;
> wher
* Theo Schlossnagle (je...@omniti.com) wrote:
> I'd like to be able to creatively solve this problem without modifying
> the core, but today I cannot.
I thought a hook already existed for this (there's already a module
which uses a hook to log commands done as a superuser, for example)..
Perhaps i
Peter Eisentraut writes:
> I've committed it now, and some buildfarm members are failing with lack
> of shared memory, semaphores, or disk space. Don't know what to do with
> that or why so many are failing like that. We could create a way to
> omit the test if it becomes a problem.
I believe t
On lör, 2011-11-05 at 18:45 +0200, Peter Eisentraut wrote:
> On mån, 2011-09-19 at 07:06 +0300, Peter Eisentraut wrote:
> > I found a simpler way to get this working. Just hack up the catalogs
> > for the new path directly. So I can now run this test suite against
> > older versions as well, like
It would be helpful if variable length catalog fields (except the first
one) would not be visible on the C level in the Form_pg_* structs. We
keep them listed in the include/catalog/pg_*.h files so that the BKI
generating code can see them and for general documentation, but the
fields are meaningl
Peter Eisentraut writes:
> This ought to show EXECUTE privilege on the new function, but it
> doesn't, because proacl is null, and nothing in the information schema
> handles that specially.
> I've pondered some ways to fix that. One would be to add a variant of
> aclexplode() that takes a param
Kohei KaiGai writes:
> Sorry, it does not cover all the code paths that I want to apply permission
> checks around creation of new tables.
>
> The existing DAC checks permission on creation of new tables at
> DefineRelation() and OpenIntoRel(), and sepgsql also wants to follow
> this manner.
> How
2011/11/27 Dimitri Fontaine :
> Kohei KaiGai writes:
>>> I wonder if you could implement that as an extension given the command
>>> trigger patch finds its way in. What do you think?
>>>
>> Unfortunately, it does not solve my point.
>
> [...]
>
>> It is also reason why I mentioned about an idea t
Kohei KaiGai writes:
>> I wonder if you could implement that as an extension given the command
>> trigger patch finds its way in. What do you think?
>>
> Unfortunately, it does not solve my point.
[...]
> It is also reason why I mentioned about an idea that put prep-creation hook
> on a limited
2011/11/21 Robert Haas :
>>> Now, what you have here is a much broader reworking. And that's not
>>> necessarily bad, but at the moment I'm not really seeing how it
>>> benefits us.
>>>
>> In my point, if individual object types need to have its own handler for
>> alter commands, points of the cod
On Nov 27, 2011, at 6:11 AM, Andrew Dunstan wrote:
>> Has this been backpatched as well?
>
> It has been to 9.1.
There may be a simple workaround, but it's non-obvious. I think it should be
back-patched all the way.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
2011/11/26 Dimitri Fontaine :
> Kohei KaiGai writes:
>> We still don't have clear direction of the way to implement external
>> permission
>> checks on object creation time. So, please consider these patches are on the
>> proof-of-concept stage; using prep-creation-hook to permission checks.
>
>
Alexander Soudakov wrote:
> in addition to:
>> I want to ask for the following 2 things:
>> 1. testing from community;
>> 2. how can I add my extension to official fdw list:
>> http://wiki.postgresql.org/wiki/Foreign_data_wrappers
>> Is there any procedure for it?
>
> Can I have it included in
On Sun, Nov 27, 2011 at 10:43 PM, Tom Lane wrote:
>
> 1. penalty is using both hard-wired penalty values (1.0, 2.0, etc) and
> values obtained from subtype_diff. This is not good, because you have
> no idea what scale the subtype differences will be expressed on. The
> hard-wired values could be
Try this:
create function foo(int) returns int as $$ select $1 $$ language sql;
select * from information_schema.routine_privileges;
This ought to show EXECUTE privilege on the new function, but it
doesn't, because proacl is null, and nothing in the information schema
handles that specia
Alexander Korotkov writes:
> On Sat, Nov 26, 2011 at 11:11 AM, Jeff Davis wrote:
>> There's been some significant change in rangetypes_gist.c, can you
>> please rebase this patch?
> OK, rebased with head.
I looked at this patch a bit. I agree with the aspect of it that says
"let's add a flag b
Also,
in addition to:
> I want to ask for the following 2 things:
> 1. testing from community;
> 2. how can I add my extension to official fdw list:
> http://wiki.postgresql.org/wiki/Foreign_data_wrappers
> Is there any procedure for it?
Can I have it included in 9.2?
On Sun, Nov 27, 2011 at 10:
Hello.
I finished developing www_fdw:
https://github.com/cyga/www_fdw/
It has docs/examples:
https://github.com/cyga/www_fdw/wiki
I haven't upload it to pgxn or pgfoundry yet.
I want to ask for the following 2 things:
1. testing from community;
2. how can I add my extension to official fdw list
Pavel Stehule writes:
> function exec_set_found uses a PointerGetDatum, should be BoolGetDatum
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
Alexander Korotkov writes:
>> The first solution that comes to mind is to make the penalty and
>> picksplit functions forcibly segregate empty ranges from others, that is
>> a split will never put empty ranges together with non-empty ones.
> Have you seen my patch about GiST for range types?
> ht
Hello,
function exec_set_found uses a PointerGetDatum, should be BoolGetDatum
*** pl_exec.c.orig 2011-11-24 12:51:45.0 +0100
--- pl_exec.c 2011-11-27 18:07:46.983118326 +0100
***
*** 5860,5866
PLpgSQL_var *var;
var = (PLpgSQL_var *) (estate->datums
I noticed that a bulk INSERT into an empty table (which has been
TRUNCATEd in the same transaction, for good measure) results in a
curious number of open(2) calls for the FSM resource fork:
open("base/657862/16554373_fsm", O_RDWR) = -1 ENOENT (No such file or directory)
lseek(17, 0, SEEK_END)
On 11/26/2011 10:36 PM, Bruce Momjian wrote:
Move pg_dump memory routines into pg_dumpmem.c/h and restore common.c
with its original functions. The previous function migration would
cause too many difficulties in back-patching.
MSVC is still broken with this change, but now I think we've ex
Hi,
+/* __MINGW64_VERSION_MAJOR is related to both 32/64 bit gcc compiles by
+ * mingw-w64, however it gots defined only after
Why not use __MINGW32__, which is defined without including any headers?
>>
>> Because it's defined by other than mingw-w64 compilers.
>
> I see. That's b
On 11/27/2011 08:25 AM, Mr. Aaron W. Swenson wrote:
On Sat, Nov 26, 2011 at 03:28:57PM -0500, Andrew Dunstan wrote:
On 10/12/2011 08:55 PM, Alex Hunsaker wrote:
On Wed, Oct 12, 2011 at 17:53, David E.
Wheeler wrote:
On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
Close, seems I was wron
On Sat, Nov 26, 2011 at 03:28:57PM -0500, Andrew Dunstan wrote:
> On 10/12/2011 08:55 PM, Alex Hunsaker wrote:
> > On Wed, Oct 12, 2011 at 17:53, David E.
> > Wheeler wrote:
> >> On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
> >>
> >>> Close, seems I was wrong about the typemap ExtUtils::ParseX
On lör, 2011-11-26 at 10:45 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On fre, 2011-11-18 at 09:44 -0500, Tom Lane wrote:
> >> It wouldn't be that hard for elog.c to do strrchr(fname, '/') or
> >> something like that,
>
> > Here is a patch for that. I would also like to backpatch this
>
> The first solution that comes to mind is to make the penalty and
> picksplit functions forcibly segregate empty ranges from others, that is
> a split will never put empty ranges together with non-empty ones. Then,
> we can assume that a non-empty internal node doesn't represent any empty
> lea
On Sat, Nov 26, 2011 at 11:11 AM, Jeff Davis wrote:
>
> There's been some significant change in rangetypes_gist.c, can you
> please rebase this patch?
>
OK, rebased with head.
--
With best regards,
Alexander Korotkov.
rangetypegist-0.3.patch.gz
Description: GNU Zip compressed data
--
Sent
Hi there!
I built the current PostgreSQL 9.1.1 sources under Ubuntu 11.04 (in a
VMware under Win7).
I followed the steps in this guide:
www.thegeekstuff.com/2009/04/linux-postgresql-install-and-configure-from-source
It seems to work (I can run the server and connect to it with PgAdmin).
Now
Hi,
>>> For the win32.h, I really don't understand why _WINSOCKAPI_ was defined
>>> before
>>>
>>> some google suggests that defining _WINSOCKAPI_ before prevents
>>> inclusion of winsock.h but that does not have relation to inclusion of
>>> and if is included first, it should be ok.
>>>
>>
38 matches
Mail list logo
