On 25.01.2011 06:29, Pavel Stehule wrote:
2011/1/25 Noah Misch:
On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
because I am not sure so any complex solution can be done to deadline
for 9.1, I created a patch that is based on Tom ideas - just
explicitly detoast function parameter
Hello
2011/1/25 Noah Misch :
> On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
>> because I am not sure so any complex solution can be done to deadline
>> for 9.1, I created a patch that is based on Tom ideas - just
>> explicitly detoast function parameters.
>
> I can confirm that,
On Mon, Jan 24, 2011 at 07:18:47PM -0500, Robert Haas wrote:
> On Sun, Jan 9, 2011 at 5:03 PM, Noah Misch wrote:
> > Here I add the notion of an "exemptor function", a property of a cast that
> > determines when calls to the cast would be superfluous. ?Such calls can be
> > removed, reduced to Rel
On Tue, Jan 25, 2011 at 6:02 AM, Heikki Linnakangas
wrote:
> Hmm, perhaps the code would be more readable if instead of the
> forcePageWrites counter that counts exclusive and non-exclusive backups, and
> an exclusiveBackup boolean indicating if one of the in-progress backups is
> an exclusive one
On Tue, Jan 25, 2011 at 5:14 AM, Heikki Linnakangas
wrote:
>> I'm not entirely sure the replication privilege removal is correct.
>> Doing that, it's no longer possible to deploy a slave *without* using
>> pg_basebackup, unless you are superuser. Do we really want to put that
>> restriction back i
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> Somehow, pgindent appears to have this approach to push lines that are
>> longer than the defined line length limit back to the left to make it
>> fit. That results in something like this:
>>
>> Can we get rid of this behavior?
> I think we wil
Peter Eisentraut wrote:
> Somehow, pgindent appears to have this approach to push lines that are
> longer than the defined line length limit back to the left to make it
> fit. That results in something like this:
>
> printfPQExpBuffer(&buf,
> "SELECT n.nspname as \"%s\",
On Mon, Jan 24, 2011 at 5:53 PM, Josh Berkus wrote:
> On 1/24/11 12:17 PM, Richard Broersma wrote:
> > PgUS is preparing to fund a grant for PgUS members to learn and
> > participate in the patch review process. We looking for experienced
> > reviewers that can assist a candidate through to proc
On Sat, Jan 15, 2011 at 02:25, Hitoshi Harada wrote:
> The patch overrides client_encoding by the added ENCODING option, and
> restores it as soon as copy is done.
We cannot do that because error messages should be encoded in the original
encoding even during COPY commands with encoding option. E
On 1/24/11 12:17 PM, Richard Broersma wrote:
> PgUS is preparing to fund a grant for PgUS members to learn and
> participate in the patch review process. We looking for experienced
> reviewers that can assist a candidate through to process of testing a
> patch - to submitting the final review. Th
On Tue, Jan 25, 2011 at 4:25 AM, Robert Haas wrote:
> On Thu, Jan 13, 2011 at 2:40 AM, Fujii Masao wrote:
>> On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao wrote:
>>> So I'm thinking to change pg_last_xlog_receive_location not to
>>> move backwards.
>>
>> The attached patch does that.
>
> It looks
On Sat, Jan 15, 2011 at 06:41, Peter Eisentraut wrote:
> I've been going over this patch with a fine-tooth comb for the last two
> weeks, fixed some small bugs, added comments, made initdb a little
> friendlier, but no substantial changes.
What can I do to test the patch?
No regression tests are
On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
> because I am not sure so any complex solution can be done to deadline
> for 9.1, I created a patch that is based on Tom ideas - just
> explicitly detoast function parameters.
I can confirm that, for your original test case, this yiel
On Mon, Jan 24, 2011 at 7:01 PM, Tom Lane wrote:
> One other issue that might be worthy of discussion is that as things
> stand, execution of the ADD CONSTRAINT USING INDEX syntax will cause
> the constraint to absorb the index as an INTERNAL dependency. That
> means dropping the constraint would
Tom Lane wrote:
> I wrote:
> > He's complaining that it dies with EINVAL.
>
> > I notice that (1) it's using O_DIRECT even though the printout claims
> > otherwise, and (2) it's writing from a buffer that has no better than
> > char alignment, which is certainly not OK for O_DIRECT. Either one
>
Greg Smith wrote:
> Bruce Momjian wrote:
> > xlogdefs.h says:
> >
> > /*
> > * Because O_DIRECT bypasses the kernel buffers, and because we never
> > * read those buffers except during crash recovery, it is a win to use
> > * it in all cases where we sync on each write(). We could allow O_DI
On Sun, Jan 9, 2011 at 5:03 PM, Noah Misch wrote:
> Here I add the notion of an "exemptor function", a property of a cast that
> determines when calls to the cast would be superfluous. Such calls can be
> removed, reduced to RelabelType expressions, or annotated (via a new field in
> FuncExpr) wi
I wrote:
> ... If that's the only issue then I don't see any need to wait on
> the author, so will take this one.
I find myself quite dissatisfied with the way that this patch adds yet
another bool flag to index_create (which has too many of those already),
with the effect of causing it to exactly
Somehow, pgindent appears to have this approach to push lines that are
longer than the defined line length limit back to the left to make it
fit. That results in something like this:
printfPQExpBuffer(&buf,
"SELECT n.nspname as \"%s\",\n"
" p.prona
Just to put this on the record for 9.2: I've just thought of a way
to further extend the READ ONLY optimizations to de facto READ ONLY
transactions. Right now, when a dangerous structure is formed with
three transactions (which consists of read-write dependencies from
T0 -> T1 -> T2) and T2 is com
On 24.01.2011 22:31, Magnus Hagander wrote:
On Mon, Jan 24, 2011 at 21:14, Heikki Linnakangas
wrote:
On 24.01.2011 20:22, Magnus Hagander wrote:
I can't see an explicit check for the user ttempting to do
pg_stop_backup() when there is a nonexclusive backup running? Maybe
I'm reading it wrong?
On Mon, Jan 24, 2011 at 21:14, Heikki Linnakangas
wrote:
> On 24.01.2011 20:22, Magnus Hagander wrote:
>> I can't see an explicit check for the user ttempting to do
>> pg_stop_backup() when there is a nonexclusive backup running? Maybe
>> I'm reading it wrong? The case being when a user has starte
PgUS is preparing to fund a grant for PgUS members to learn and
participate in the patch review process. We looking for experienced
reviewers that can assist a candidate through to process of testing a
patch - to submitting the final review. The ultimate deliverable
would be the actual review pos
On 24.01.2011 20:22, Magnus Hagander wrote:
On Mon, Jan 24, 2011 at 17:52, Heikki Linnakangas
wrote:
Another updated patch. Fixed bitrot, and addressed the privilege issue
Fujii-san raised here:
http://archives.postgresql.org/message-id/4d380560.3040...@enterprisedb.com.
I changed the privileg
On Mon, Jan 24, 2011 at 2:21 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> I am wondering if it wouldn't be simpler and more logical to allow
>> idempotent changes of these settings at any time, and to restrict
>> only changes that actually change something. It feels really
>> weird to all
On Thu, Jan 13, 2011 at 2:40 AM, Fujii Masao wrote:
> On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao wrote:
>> So I'm thinking to change pg_last_xlog_receive_location not to
>> move backwards.
>
> The attached patch does that.
It looks to me like this is changing more than just the return value
of
Robert Haas wrote:
> I am wondering if it wouldn't be simpler and more logical to allow
> idempotent changes of these settings at any time, and to restrict
> only changes that actually change something. It feels really
> weird to allow changing these properties to their own values at
> any time
On Mon, Jan 24, 2011 at 17:52, Heikki Linnakangas
wrote:
> On 13.01.2011 23:32, Heikki Linnakangas wrote:
>>
>> Anyway, here's an updated patch with all the known issues fixed.
>
> Another updated patch. Fixed bitrot, and addressed the privilege issue
> Fujii-san raised here:
> http://archives.pos
Steve Singer writes:
> src/backend/parser/parse_utilcmd.c: 1452
> Your calling strdup on the attribute name. I don't have a good enough
> grasp on the code to be able to trace this through to where the memory
> gets free'd. Does it get freed? Should/could this be a call to pstrdup
strdup() is
Jesper Krogh writes:
> Would it be hard to make it support "n-grams" (e.g. making the length
> configurable) instead of trigrams?
That would be a complete rewrite with an incompatible on-disk index
representation, which seems a bit beyond the scope of this patch.
regards,
si...@2ndquadrant.com (Simon Riggs) writes:
> I just wanted to point out that the patch submitted here does not allow
> what is requested here for FKs (nor indexes).
That's fine; I was trying to support the thought that there was
something useful about this idea. Being able to expressly deactivat
Florian Pflug writes:
> On Jan22, 2011, at 17:55 , Tom Lane wrote:
>> Reflecting on that, I'm inclined to suggest
>> Bitmap Heap Scan ...
>> Recheck Cond: blah blah
>> Rows Removed by Recheck Cond: 42
>> Filter Cond: blah blah blah
>> Rows R
On 13.01.2011 23:32, Heikki Linnakangas wrote:
Anyway, here's an updated patch with all the known issues fixed.
Another updated patch. Fixed bitrot, and addressed the privilege issue
Fujii-san raised here:
http://archives.postgresql.org/message-id/4d380560.3040...@enterprisedb.com.
I changed
On 2011-01-24 16:34, Alexander Korotkov wrote:
Hi!
On Mon, Jan 24, 2011 at 3:07 AM, Jan Urbański wrote:
I see two issues with this patch. First of them is the resulting index
size. I created a table with 5 copies of
/usr/share/dict/american-english in it and a gin index on it, using
gin_trgm_
Hi!
On Mon, Jan 24, 2011 at 3:07 AM, Jan Urbański wrote:
> I see two issues with this patch. First of them is the resulting index
> size. I created a table with 5 copies of
> /usr/share/dict/american-english in it and a gin index on it, using
> gin_trgm_ops. The results were:
>
> * relation siz
On Mon, Jan 24, 2011 at 09:03, Fujii Masao wrote:
> On Mon, Jan 24, 2011 at 4:47 PM, Magnus Hagander wrote:
>> On Mon, Jan 24, 2011 at 08:45, Fujii Masao wrote:
>>> On Fri, Jan 21, 2011 at 12:28 AM, Tom Lane wrote:
Magnus Hagander writes:
>> - Why not initialize logid and logseg like
Heikki Linnakangas writes:
> On 24.01.2011 03:42, Itagaki Takahiro wrote:
>> To suppress it, I'm thinking to add noreturn to die_horribly().
>> Any objections? Another solution might be adding a dummy assignment
>> after calls of die_horribly().
> I added a dummy assignment, that's how we've han
On 01/24/2011 02:25 PM, Vangelis Katsikaros wrote:
[skip]
Oh sorry for the double posting. Thought I canceled it, my bad...
Vangelis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 24, 2011 at 6:58 AM, Vangelis Katsikaros
wrote:
> I see that the gist README file (src/backend/access/gist/README) hasn't seen
> any major content updates, since its initial creation, apart from gist
> insertion recovery issues [1].
>
> I would like to ask if there are any major differ
Hi,
According to http://www.pgbuildfarm.org/cgi-bin/show_status.pl, only
GCC 3.4.2 and 4.5.0 have successfully build PostgreSQL,and only under
32 bit Windows environment, and I guess from
http://archives.postgresql.org/pgsql-hackers/2010-12/msg02073.php that
you mean we should only the above two ve
Hello
I see that the gist README file (src/backend/access/gist/README) hasn't
seen any major content updates, since its initial creation, apart from
gist insertion recovery issues [1].
I would like to ask if there are any major differences between the
README file and postrges' code, and if t
On Mon, Jan 24, 2011 at 8:08 AM, Heikki Linnakangas
wrote:
> * Is there any point in allowing a FDW without a handler? It's totally
> useless, isn't it? We had the CREATE FOREIGN DATA WRAPPER syntax in previous
> versions, and it allowed it, but it has always been totally useless so I
> don't thin
On 21.01.2011 17:57, Robert Haas wrote:
On Fri, Jan 21, 2011 at 10:17 AM, Heikki Linnakangas
wrote:
On 18.01.2011 17:26, Shigeru HANADA wrote:
1) 20110118-no_fdw_perm_check.patch - This patch is not included in
last post. This had been proposed on 2011-01-05 first, but maybe has
not been re
Hello
I see that the gist README file (src/backend/access/gist/README) hasn't
seen any major content updates, since its initial creation, apart from
gist insertion recovery issues [1].
I would like to ask if there are any major differences between the
README file and postrges' code, and if t
On Mon, Jan 24, 2011 at 20:49, Robert Haas wrote:
> I notice that this is adding keywords and syntax support for what is
> basically a PostgreSQL extension (since we certainly can't possibly be
> following the SQL standards given that we're not implementing a new
> datatype. Is that really a good
On Mon, Jan 24, 2011 at 2:45 AM, Itagaki Takahiro
wrote:
> [ latest patch ]
I notice that this is adding keywords and syntax support for what is
basically a PostgreSQL extension (since we certainly can't possibly be
following the SQL standards given that we're not implementing a new
datatype. Is
2011/1/24 Pavel Stehule :
> Hello
>
>>
>>
>>> Other comments- I don't like using 'i' and 'j', you really should use
>>> better variable names, especially in large loops which contain other
>>> loops. I'd also suggest changing the outer loop to be equivilant to the
>>> number of iterations that wil
Hello
>
>
>> Other comments- I don't like using 'i' and 'j', you really should use
>> better variable names, especially in large loops which contain other
>> loops. I'd also suggest changing the outer loop to be equivilant to the
>> number of iterations that will be done instead of the number of
On Wed, Jan 19, 2011 at 14:36, Stephen Frost wrote:
> Alright, here's the latest on this patch. I've added a log_csv_fields
> GUC along with the associated magic to make it work (at least for me).
> Also added 'role_name' and '%U' options. Requires postmaster restart to
> change, didn't include
On 24/01/11 02:01, Nate C wrote:
> Unexpected argument handling in pl/python variadic argument function
>
> create or replace function variadic_sql
> (template text, variadic args text[], out text)
> language sql as
> $$
> select $1 || ' -- ' || $2::text
> $
On 01/23/2011 11:11 PM, Xiaobo Gu wrote:
Yes, I want it working on 64 bit Windows Server 2003 R2 and 64 bit
Windows 7 home basic.
Which version of 32bit MinGW do you use, I use the one shipped with
Rtools212.exe which is downloaded from
http://www.murdoch-sutherland.com/Rtools, and there is no
Robert Haas writes:
> On Sun, Jan 23, 2011 at 9:20 PM, Joseph Adams
> wrote:
>> The attached patch changes hstore's Makefile so it is like the others.
>
> Thanks, committed.
For the record, I smell bitrot here:
http://archives.postgresql.org/message-id/m21v7jpqe6@2ndquadrant.fr
I had in
2011/1/24 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I merge your changes and little enhanced comments.
>
> Thanks. Reviewing this further-
>
> Why are you using 'FOREACH' here instead of just making it another
> variation of 'FOR'? What is 'FOUND' set to fol
On Sat, Jan 22, 2011 at 07:20, Tom Lane wrote:
> Heikki Linnakangas writes:
>> * I wonder if CREATE FOREIGN DATA WRAPPER should automatically create
>> the handler function, if it doesn't exist yet.
>
> Doing that would require the equivalent of pg_pltemplate for FDWs, no?
> I think we're a long
On Mon, Jan 24, 2011 at 4:47 PM, Magnus Hagander wrote:
> On Mon, Jan 24, 2011 at 08:45, Fujii Masao wrote:
>> On Fri, Jan 21, 2011 at 12:28 AM, Tom Lane wrote:
>>> Magnus Hagander writes:
> - Why not initialize logid and logseg like so?:
>
> int logid = startptr.xlogid;
55 matches
Mail list logo
