On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be thinking in a non SSD world, but
its possible in an SSD.
So, code it. Shouldn't be hard to write a demo comparison. I don't
You can believe whatever you want, that doesn't make it true.
completely agree. Like yours, Its just my point of view, not the reality.
I agree with most points here, but I wondering how many good ideas are
killed with the thought: this will be a performance killer with so
many random access,
This broke the buildfarm on Windows, and I'm not sure of the best way to fix it.
We currently define read and write permissions in port/win32.h
specifically for windows. A quick-fix to just add these new ones as
aliases won't work, because they are used in both open and umask
calls.
Since
On Wed, Dec 8, 2010 at 15:40, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Wed, Dec 8, 2010 at 02:07, Tom Lane t...@sss.pgh.pa.us wrote:
[ win32.h says ]
#define fsync(fd) _commit(fd)
What this means is that switching to a simple preference order
On Dec11, 2010, at 06:20 , Pavel Stehule wrote:
I wrote a few functions for record type - record_expand,
record_get_fields, record_get_field, record_set_fields.
Just FYI, I've created something similar a while ago. The code can be found at
https://github.com/fgp/pg_record_inspect
The main
On Thu, 2010-12-09 at 22:13 +0900, Fujii Masao wrote:
When I created the conflict between recovery and many read-only
transactions in the standby server for test purpose, I found that the
keyword waiting disappeared from PS display for just a moment
even though the conflict had not been
On Mon, Dec 6, 2010 at 12:54 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Dec 6, 2010 at 3:07 AM, Greg Smith g...@2ndquadrant.com wrote:
The one time this year top-posting seems appropriate...this patch seems
stalled waiting for some sort of response to the concerns Alvaro raised
here.
2010/12/11 Florian Pflug f...@phlo.org:
On Dec11, 2010, at 06:20 , Pavel Stehule wrote:
I wrote a few functions for record type - record_expand,
record_get_fields, record_get_field, record_set_fields.
Just FYI, I've created something similar a while ago. The code can be found at
On Dec11, 2010, at 16:03 , Pavel Stehule wrote:
2010/12/11 Florian Pflug f...@phlo.org:
On Dec11, 2010, at 06:20 , Pavel Stehule wrote:
I wrote a few functions for record type - record_expand,
record_get_fields, record_get_field, record_set_fields.
Just FYI, I've created something similar a
Magnus Hagander mag...@hagander.net writes:
This broke the buildfarm on Windows, and I'm not sure of the best way to fix
it.
We currently define read and write permissions in port/win32.h
specifically for windows. A quick-fix to just add these new ones as
aliases won't work, because they are
Hey Pavel,
Everything looks fine, but I propose you to add record_set_field
just for convenience and as opposite of record_get_field.
2010/12/11 Pavel Stehule pavel.steh...@gmail.com
Hello
I wrote a few functions for record type - record_expand,
record_get_fields, record_get_field,
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Anybody have a problem with adopting this behavior?
Seems a bit surprising.
Yeahh.. I'm not really sure about mkdir -p type actions
I wrote:
Magnus Hagander mag...@hagander.net writes:
This broke the buildfarm on Windows, and I'm not sure of the best way to fix
it.
Hm, those symbols are already in use elsewhere in the code; I would
assume it's just a matter of missing #includes in these particular
files. Where does
On Sat, Dec 11, 2010 at 17:13, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Magnus Hagander mag...@hagander.net writes:
This broke the buildfarm on Windows, and I'm not sure of the best way to
fix it.
Hm, those symbols are already in use elsewhere in the code; I would
assume it's just a
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 11, 2010 at 17:13, Tom Lane t...@sss.pgh.pa.us wrote:
Ah, I have a theory: fcntl.h.
Nope, not there. I can't find S_IWGRP in any of the files.
Well, I notice that copydir.c compiled before, and still compiles after,
despite this change:
On Sat, Dec 11, 2010 at 17:23, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 11, 2010 at 17:13, Tom Lane t...@sss.pgh.pa.us wrote:
Ah, I have a theory: fcntl.h.
Nope, not there. I can't find S_IWGRP in any of the files.
Well, I notice that
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 11, 2010 at 17:23, Tom Lane t...@sss.pgh.pa.us wrote:
I think the reason it's not failing is that it includes fcntl.h.
S_IRWXU is defined in port/win32.h...
No, it isn't. There's an apparently-useless definition of _S_IRWXU
there, but
On Sat, Dec 11, 2010 at 17:38, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 11, 2010 at 17:23, Tom Lane t...@sss.pgh.pa.us wrote:
I think the reason it's not failing is that it includes fcntl.h.
S_IRWXU is defined in port/win32.h...
No, it
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 11, 2010 at 17:38, Tom Lane t...@sss.pgh.pa.us wrote:
No, it isn't. There's an apparently-useless definition of _S_IRWXU
there, but no S_IRWXU.
Hmm. You're right, of course.
A search on my windows box finds the text string S_IRWXU in
2010/12/11 Florian Pflug f...@phlo.org:
On Dec11, 2010, at 16:03 , Pavel Stehule wrote:
2010/12/11 Florian Pflug f...@phlo.org:
On Dec11, 2010, at 06:20 , Pavel Stehule wrote:
I wrote a few functions for record type - record_expand,
record_get_fields, record_get_field, record_set_fields.
On Sat, Dec 11, 2010 at 17:55, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 11, 2010 at 17:38, Tom Lane t...@sss.pgh.pa.us wrote:
No, it isn't. There's an apparently-useless definition of _S_IRWXU
there, but no S_IRWXU.
Hmm. You're right, of
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 11, 2010 at 17:55, Tom Lane t...@sss.pgh.pa.us wrote:
2. Why didn't the previously hard-wired constants passed to chmod
and umask fail on Windows? The M$ documentation I can find at the
moment suggests that *only* _S_IREAD and _S_IWRITE
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 11, 2010 at 17:55, Tom Lane t...@sss.pgh.pa.us wrote:
1. How did all those pre-existing references to S_IRXWU compile?
Yeah, that's weird. IIRC (I stopped looking for the moment, need a
step back) some of them were protected by #ifndef
On Sat, Dec 11, 2010 at 18:46, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 11, 2010 at 17:55, Tom Lane t...@sss.pgh.pa.us wrote:
1. How did all those pre-existing references to S_IRXWU compile?
Yeah, that's weird. IIRC (I stopped looking for the
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 11, 2010 at 18:46, Tom Lane t...@sss.pgh.pa.us wrote:
I think we can just #define the other cases as zeroes. I'm not sure why
you think that's an issue for open --- the privileges don't exist.
Hmm. I was/am worried about any case that
On Sat, Dec 11, 2010 at 10:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Anybody have a problem with adopting this behavior?
Seems a bit
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 11, 2010 at 10:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
OK. Is there any value in doing mkdir -p in WAL-recovery execution of
CREATE TABLESPACE but not regular execution?
I don't think so. If someone creates a directory that is not
On Sat, Dec 11, 2010 at 1:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 11, 2010 at 10:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
OK. Is there any value in doing mkdir -p in WAL-recovery execution of
CREATE TABLESPACE but not regular execution?
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 11, 2010 at 1:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not really thinking about crash recovery, but replication slaves.
Omitting to create the tablespace location directories on slaves
doesn't seem far-fetched at all. Of course, it's
Hi everyone,
I just wrote my first patch, and I need to know whether I missed something
or not. I haven't used C for a really long time, so sickbags on standby,
and if you notice something really stupid don't hesitate to call me an
asshole (according to Simon Phipps that proves we are a healthy
On Fri, Dec 10, 2010 at 8:09 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be thinking in a non SSD world, but
its possible in
On Wed, Dec 8, 2010 at 6:52 AM, Marti Raudsepp ma...@juffo.org wrote:
A very useful feature for unlogged tables would be the ability to
switch them back to normal tables -- this way you could do bulk
loading into an unlogged table and then turn it into a regular table
using just fsync(),
Hi,
I've been reading through the entire thread and it seems like this is
the best mail to choose to answer.
Tom Lane t...@sss.pgh.pa.us writes:
Maybe I misread David's meaning, but I thought he was saying that
there's no value in inventing all those control file entries in the
first place.
On Fri, Dec 10, 2010 at 8:16 PM, Robert Haas robertmh...@gmail.com wrote:
As I was working on the hash index support, it occurred to me that at
some point in the future, we might want to allow an unlogged index on
a permanent table.
That is the feature I would be most excited about.
With
On Dec11, 2010, at 17:55 , Pavel Stehule wrote:
It same trick, that I use in record_set_fields.
Oh, I see. Sorry, must haven missed that when I read your blog entry.
But I don't want to
use it for reading of value. I don't like it. You don't need to know a
value, you have to know a type -
(Moving to pgsql-hackers)
On 10.12.2010 20:21, Tom Lane wrote:
Simon Riggssi...@2ndquadrant.com writes:
Reduce spurious Hot Standby conflicts from never-visible records.
Hot Standby conflicts only with tuples that were visible at
some point. So ignore tuples from aborted transactions or for
Hackers,
Here is first version of patch, which enable index support of wildcard
search in pg_trgm contrib module. The idea of the patch is to extract from
wildcard trigrams which should occurs in wildcard matching string. For
example, for '%sector%' wildcard such trigrams would be: 'sec', 'ect',
Hi,
The other infrastructure patch that has been mark ready for commit then
commented further upon by Tom is $subject, even if the function provided
as been renamed to pg_execute_sql_file().
Please find attached the newer version that fixes Tom concerns, removing
the VARIADIC forms of the
On Fri, Dec 10, 2010 at 11:24:27AM -0500, Tom Lane wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Are there any actual remaining use-cases for that sed step?
The goal here is to allow extension authors to maintain their version
number in the
2010/12/11 Florian Pflug f...@phlo.org:
On Dec11, 2010, at 17:55 , Pavel Stehule wrote:
It same trick, that I use in record_set_fields.
Oh, I see. Sorry, must haven missed that when I read your blog entry.
But I don't want to
use it for reading of value. I don't like it. You don't need to
Hello
you have to respect pg coding style:
a) not too long lines
b) not C++ line comments
Zdar
Pavel
2010/12/11 t...@fuzzy.cz:
Hi everyone,
I just wrote my first patch, and I need to know whether I missed something
or not. I haven't used C for a really long time, so sickbags on standby,
On Dec 11, 2010, at 1:09 PM, David Fetter wrote:
Why is it in the makefile at all? If the makefile does need to know it,
why don't we have it scrape the number out of the control file? Or even
more to the point, since when do we need version numbers in extensions?
We *absolutely* need
On Dec 11, 2010, at 12:09 PM, Dimitri Fontaine wrote:
Yeah that works, as soon as VVV is the version we upgrade from.
That said, we need to find a way to lighten the process for extensions
where it's easy to have a single script to support upgrade from more
than once past release.
What
On Dec 10, 2010, at 6:18 PM, Jeff Janes wrote:
On Fri, Dec 10, 2010 at 3:09 PM, Hamza Bin Sohail hsoh...@purdue.edu wrote:
Hello hackers,
I think i'm at the right place to ask this question.
Based on your experience and the fact that you have written the Postgres
code,
can you tell
Hello
you have to respect pg coding style:
a) not too long lines
b) not C++ line comments
OK, thanks for the notice. I've fixed those two problems.
regards
Tomasdiff --git a/src/backend/catalog/system_views.sql
b/src/backend/catalog/system_views.sql
index 346eaaf..0ee59b1 100644
---
On Dec 11, 2010, at 9:24 AM, Florian Pflug wrote:
begin
for v_field in select * from fieldinfos(myrec) loop
case
when v_field.fieldtype = 'type1'::regtype then
v_value_type1 := fieldvalue(myrec, NULL::type1,
false);
Hello
I looked on your module now and I am can't to say, what is better -
both modules has little bit different target if I understand, and I
don't know if they can be mixed. There are two strategies - rich
contrib module or a few functions in core. Probably we can't to have a
too rich API for
Yesterday I did a bit of work on allowing bytea values to be passed into
and out of plperl in binary format, effectively removing the need to
escape and de-escape them. (The work can be seen on he plperlargs branch
of my development repo at
On Dec 11, 2010, at 2:27 PM, Andrew Dunstan wrote:
Yesterday I did a bit of work on allowing bytea values to be passed into and
out of plperl in binary format, effectively removing the need to escape and
de-escape them. (The work can be seen on he plperlargs branch of my
development repo
On Sat, Dec 11, 2010 at 1:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 11, 2010 at 1:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not really thinking about crash recovery, but replication slaves.
Omitting to create the tablespace location
On 12/11/2010 08:01 PM, David E. Wheeler wrote:
At the moment the behaviour is triggered by a custom setting
(plperl.pass_binary_bytea), but this isn't really satisfactory. We could turn
it on permanently, but that would break a lot of legacy code. What we really
need is a way of marking
On Sat, Dec 11, 2010 at 2:53 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Wed, Dec 8, 2010 at 6:52 AM, Marti Raudsepp ma...@juffo.org wrote:
A very useful feature for unlogged tables would be the ability to
switch them back to normal tables -- this way you could do bulk
loading into an
On Sat, Dec 11, 2010 at 3:18 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Dec 10, 2010 at 8:16 PM, Robert Haas robertmh...@gmail.com wrote:
As I was working on the hash index support, it occurred to me that at
some point in the future, we might want to allow an unlogged index on
a
On Sat, Dec 11, 2010 at 5:27 PM, Andrew Dunstan
andrew.duns...@pgexperts.com wrote:
Yesterday I did a bit of work on allowing bytea values to be passed into and
out of plperl in binary format, effectively removing the need to escape and
de-escape them. (The work can be seen on he plperlargs
On Fri, Dec 10, 2010 at 8:16 PM, Robert Haas robertmh...@gmail.com wrote:
I think the first patch (relpersistence-v4.patch) is ready to commit,
and the third patch to allow synchronous commits to become
asynchronous when it doesn't matter (relax-sync-commit-v1.patch)
doesn't seem to be
On 12/11/2010 09:16 PM, Robert Haas wrote:
Well, you could set that GUC (plperl.pass_binary_bytea) on a function
without changing any syntax on at all.
CREATE FUNCTION name (args) ... SET plperl.pass_binary_bytea = true;
Oh, good point. I'd forgotten about that. I'll experiment and see if
On Sat, Dec 11, 2010 at 9:21 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Dec 10, 2010 at 8:16 PM, Robert Haas robertmh...@gmail.com wrote:
I think the first patch (relpersistence-v4.patch) is ready to commit,
and the third patch to allow synchronous commits to become
asynchronous when
On Sat, Dec 11, 2010 at 9:28 PM, Andrew Dunstan and...@dunslane.net wrote:
On 12/11/2010 09:16 PM, Robert Haas wrote:
Well, you could set that GUC (plperl.pass_binary_bytea) on a function
without changing any syntax on at all.
CREATE FUNCTION name (args) ... SET plperl.pass_binary_bytea =
On Sat, Dec 11, 2010 at 4:40 PM, t...@fuzzy.cz wrote:
Hello
you have to respect pg coding style:
a) not too long lines
b) not C++ line comments
OK, thanks for the notice. I've fixed those two problems.
Please add this to the currently-open commitfest.
Hi everyone,
one of the ssesion I've attended on PgDay last week was Heikki's session
about statistics in PostgreSQL. One of the issues he mentioned (and one
I regularly run into) is the absence of cross-column stats. When the
columns are not independent, this usually result in poor estimates
On Dec 11, 2010, at 5:58 PM, Andrew Dunstan wrote:
create function foo() . with ( /attribute/ [, ...] )
Currently allowed attributes are isStrict and isCachable. The mechanism is
effectively obsolete right now, but we could use it for what I have in mind
quite nicely.
Makes
61 matches
Mail list logo
