Simon Riggs wrote:
On Mon, 2009-09-21 at 14:01 +0100, Simon Riggs wrote:
On Mon, 2009-09-21 at 13:50 +0300, Heikki Linnakangas wrote:
is this that we seem to be missing conflict
resolution for GiST index tuples deleted by the kill_prior_tuples
mechanism. Unless I'm missing something, we
On Mon, 2009-09-21 at 19:42 -0700, Jeff Janes wrote:
On Tue, Sep 15, 2009 at 2:41 PM, Simon Riggs si...@2ndquadrant.com wrote:
OK, here is the latest version of the Hot Standby patchset. This is
about version 30+ by now, but we should regard this as 0.2.1
Patch against CVS HEAD (now):
Simon Riggs wrote:
On Mon, 2009-09-21 at 19:42 -0700, Jeff Janes wrote:
jjanes=# begin;
BEGIN
jjanes=# lock table pgbench_history in access exclusive mode;
LOCK TABLE
jjanes=# select count(*) from pgbench_history;
count
519104
(1 row)
jjanes=# select count(*) from
On Tue, 2009-09-22 at 11:04 +0300, Heikki Linnakangas wrote:
By me, yes. WAL replay does not require a table lock to progress. Any
changes are protected with block-level locks. It does acquire a table
lock and cancel conflicting queries when it is about to replay something
that would
DML rules don't work during read only transactions. Now that is a real
shame because it would allow some important capabilities when running in
Hot Standby mode.
postgres=# create or replace function foo () returns void
language plpgsql as
$$ begin null; end; $$;
CREATE FUNCTION
postgres=#
In testing, it looks like there's still something wrong with the
subtransaction handling. I created a test function to create a large
number of subtransactions:
CREATE LANGUAGE plpgsql;
CREATE TABLE bar (id int4);
CREATE OR REPLACE FUNCTION subxids (n integer) RETURNS void LANGUAGE
plpgsql AS $$
On Tue, 2009-09-22 at 12:53 +0300, Heikki Linnakangas wrote:
In testing, it looks like there's still something wrong with the
subtransaction handling. I created a test function to create a large
number of subtransactions:
OK, looking at this now. Thanks for the report.
--
Simon Riggs
On Tue, 2009-09-22 at 12:53 +0300, Heikki Linnakangas wrote:
It looks like the standby tries to remove XID 4323 from the
known-assigned hash table, but it's not there because it was removed
and set in pg_subtrans by an XLOG_XACT_ASSIGNMENT record earlier. I
guess we should just not throw an
Jan Urbański napsal(a):
Hi,
here's a (late, sorry about that) review:
Thanks for the comprehensive review!
It's unified, not context, but that's trivial.
It's not, I have git configured to produce context diffs (see
Jaime, Thanks for your reviewing.
Jaime Casanova wrote:
2009/9/6 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is an update of largeobject access controls.
it applies fine (just 3 succeded hunks), compiles and passes
regression tests...
ALTER LARGE OBJECT is working, but now that
Hi,
Dimitri Fontaine dfonta...@hi-media.com writes:
Patch applies cleanly and build cleanly too, basic examples are working
fine.
I've been reading through the code and am going to mark it as ready for
commiter, as only remarks I have are probably because I do not know
enough about PostgreSQL
Jeevan Chalke escreveu:
That means we cannot simply ignore such characters from the input.
Rather we can process the string R-L. But yes this will definitely going
to break the current applications running today.
IIRC we tight the to_char() and to_timestamp() input for 8.4. Why don't we do
it
Dimitri Fontaine napsal(a):
Hi,
Dimitri Fontaine dfonta...@hi-media.com writes:
Patch applies cleanly and build cleanly too, basic examples are working
fine.
I've been reading through the code and am going to mark it as ready for
commiter, as only remarks I have are probably because
On Tue, 2009-09-22 at 12:53 +0300, Heikki Linnakangas wrote:
In testing, it looks like there's still something wrong with the
subtransaction handling. I created a test function to create a large
number of subtransactions:
CREATE LANGUAGE plpgsql;
CREATE TABLE bar (id int4);
CREATE OR
(Sorry, forgot to CC hackers)
Robert Haas wrote:
With regard to the changes in explain.c, I think that the way you've
capitalized INSERT, UPDATE, and DELETE is not consistent with our
usual style for labelling nodes. Also, you've failed to set sname, so
this reads from uninitialized memory
Le samedi 19 septembre 2009, David Fetter a écrit :
Folks,
Here's what came out for Mozilla, which, I hope you'll pardon my
saying so, is a teensy tad more widely used than PostgreSQL has any
plans to become.
http://www.internetnews.com/government/article.php/3839831/Mozilla+Firefox+
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Robert Haas wrote:
Can you explain the motivation for changing the Append stuff as part
of this patch? It's not immediately clear to me why that needs to be
done as part of this patch or what we get out of it.
It seemed to me that the
On Tue, Sep 22, 2009 at 11:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Robert Haas wrote:
Can you explain the motivation for changing the Append stuff as part
of this patch? It's not immediately clear to me why that needs to be
done as part
Robert Haas robertmh...@gmail.com writes:
Right now, it looks like most of the code is being shared between all
three plan types. I'm pretty suspicious of how much code this patch
moves around and how little of it is actually changed. I can't really
tell if there's an actual design
Petr Jelinek pjmo...@pjmodos.net writes:
It is. I attached patch which does not have this part.
do.sgml seems missing?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Heikki Linnakangas escribió:
Simon Riggs wrote:
On Mon, 2009-09-21 at 19:42 -0700, Jeff Janes wrote:
jjanes=# begin;
BEGIN
jjanes=# lock table pgbench_history in access exclusive mode;
LOCK TABLE
jjanes=# select count(*) from pgbench_history;
count
519104
(1 row)
Simon Riggs wrote:
OK, here is the latest version of the Hot Standby patchset. This is
about version 30+ by now, but we should regard this as 0.2.1
Patch against CVS HEAD (now): clean apply, compile, no known bugs.
OVERVIEW
Anyone who is interested in how the hot standby behaves should
I'm going through the anonymous-code-blocks patch now. There are some
things missing, notably the ability to create a language with an
anonymous-code-block handler. The only way you can do it is to have
a pg_pltemplate entry, which is certainly not good enough for languages
not distributed with
On Tue, Sep 22, 2009 at 7:23 AM, KaiGai Kohei kai...@kaigai.gr.jp wrote:
another one, is it possible for us to have a CREATE LARGE OBJECT
statement?
the reason for this is:
1) it is a little ugly to use the OID in ALTER/GRANT/REVOKE
statements, in a create statement we can assign a name to
On Sat, Sep 19, 2009 at 8:23 PM, Andrew Dunstan and...@dunslane.net wrote:
Dimitri Fontaine wrote:
So here are the major points about this patch:
- it's missing the returns declaration syntax (default value could be
returns void?)
- it would be much more friendly to users if it had a
On Tue, Sep 22, 2009 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm going through the anonymous-code-blocks patch now. There are some
things missing, notably the ability to create a language with an
anonymous-code-block handler. The only way you can do it is to have
a pg_pltemplate
On Tue, Sep 22, 2009 at 1:29 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
have anyone better ideas about the name? if not, then go with
pg_largeobject_meta
I don't think there's anything wrong with calling it metadata. That
seems to leave the door open to future things we might want
On Tue, Sep 22, 2009 at 01:50:45PM -0400, Robert Haas wrote:
On Tue, Sep 22, 2009 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm going through the anonymous-code-blocks patch now. There are
some things missing, notably the ability to create a language with
an anonymous-code-block
Tom Lane wrote:
I'm going through the anonymous-code-blocks patch now. There are some
things missing, notably the ability to create a language with an
anonymous-code-block handler. The only way you can do it is to have
a pg_pltemplate entry, which is certainly not good enough for languages
On Tue, Sep 22, 2009 at 12:53 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 22, 2009 at 1:29 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
have anyone better ideas about the name? if not, then go with
pg_largeobject_meta
I don't think there's anything wrong with calling
Robert Haas robertmh...@gmail.com writes:
Should we consider another generic options syntax, while we're on a
roll? In the long run, that's the best way to avoid having a zillion
keywords.
If there were any near-term prospect of more options for languages,
I might agree ... but there isn't,
Merlin Moncure mmonc...@gmail.com writes:
A note about void returning functionsthere are no send/recv
functions for the void type which will cause problems for users of
this feature over the binary protocol.
This isn't a SELECT and doesn't return anything, so I don't see the
issue.
Tom Lane t...@sss.pgh.pa.us writes:
Merlin Moncure mmonc...@gmail.com writes:
A note about void returning functionsthere are no send/recv
functions for the void type which will cause problems for users of
this feature over the binary protocol.
This isn't a SELECT and doesn't return
Tom,
If the partitioning implementation does not make progress (and does not
make it for 8.5), don't you think that this could be an interesting
contribution to consider for this release?
I have put on the wiki
(http://wiki.postgresql.org/wiki/Join_optimization_for_inheritance_tables)
the
On Tue, 22 Sep 2009, Michael Paquier wrote:
Besides, you can also make tests without 2pc transactions, such as:
\shell ls -ll /home/ioltas/usr/pgsql/data
END;
I think that demonstrating the pgbench shell feature with this 2PC example
is working against your patch being even considered, much
Petr Jelinek pjmo...@pjmodos.net writes:
[ anonymous code blocks patch ]
I committed this after some editorialization. Aside from adding missing
CREATE LANGUAGE and pg_dump support, I didn't like the API for inline
handler functions. Passing just a C string doesn't allow for any future
On Wed, 2009-09-09 at 18:26 +0300, Marko Kreen wrote:
Unicode escapes for extended strings.
On 4/16/09, Marko Kreen mark...@gmail.com wrote:
Reasons:
- More people are familiar with \u escaping, as it's standard
in Java/C#/Python, probably more..
- U strings will not work when
On Tue, 2009-09-22 at 18:16 -0400, Emmanuel Cecchet wrote:
If the partitioning implementation does not make progress (and does not
make it for 8.5), don't you think that this could be an interesting
contribution to consider for this release?
I have put on the wiki
As I understand it, partitioning will certainly lead to some significant
changes/enhancements to the planner. Do you think it is realistic to get
that for 8.5?
I don't think that waiting for our plans for a more robust partitioning
implementation is a reason to put off improvements to the
See attached a patch of this setshell feature.
If you use in a script file something like:
/setshell param_set setshellparam.sh
pgbench reads from the shell script setshellparam.sh the first output value,
verifies if it is an integer, then manages it as a pgbench parameter.
I did not take into
Hstore patch incorporating changes as previously discussed.
In addition the requested new features of conversions to and from
array formats have been added (with docs).
--
Andrew (irc:RhodiumToad)
hstore-20090923.patch.gz
Description: hstore patch
--
Sent via pgsql-hackers mailing list
Josh Berkus j...@agliodbs.com writes:
I don't think that waiting for our plans for a more robust partitioning
implementation is a reason to put off improvements to the implementation
we have.
The complaint I had was that this patch consisted largely of code that
we'd want to throw away once a
On Wed, Sep 9, 2009 at 11:25 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
4. LATERAL allows some optimizations that aren't currently done, either
by explicitly rewriting the query, or (in theory) the optimizer itself
could consider a lateral plan (I believe Oracle does this). This
Robert Haas robertmh...@gmail.com writes:
I've been turning this one over in my head. It seems to me that this
is very similar to what we already do with inner index-scans, only
generalized to joinrels.
Right.
Currently, however, we only consider this possibility when the inner
rel is NOT
Tom Lane napsal(a):
Petr Jelinek pjmo...@pjmodos.net writes:
[ anonymous code blocks patch ]
I committed this after some editorialization. Aside from adding missing
CREATE LANGUAGE and pg_dump support, I didn't like the API for inline
handler functions. Passing just a C string
45 matches
Mail list logo
