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 somet
On Mon, 2009-09-21 at 19:42 -0700, Jeff Janes wrote:
> On Tue, Sep 15, 2009 at 2:41 PM, 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, co
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 co
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
> > tha
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=# crea
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
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
http://wiki.postgresql.org/wiki/Working_with_Git#Context_diffs_with_Gi
Jaime, Thanks for your reviewing.
Jaime Casanova wrote:
2009/9/6 KaiGai Kohei :
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 we can change the owne
Hi,
Dimitri Fontaine 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 internals, and the o
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
Dimitri Fontaine napsal(a):
Hi,
Dimitri Fontaine 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 a
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);
>
> CREAT
(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 when
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 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 Append on top was only a
On Tue, Sep 22, 2009 at 11:04 AM, Tom Lane wrote:
> Marko Tiikkaja 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
Robert Haas 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 improvement here or if this
Petr Jelinek 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:
http://www.postgresql.org/mailpref/pgsql-ha
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
> >>
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 shou
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 t
On Tue, Sep 22, 2009 at 7:23 AM, KaiGai Kohei 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 the LO
>>
On Sat, Sep 19, 2009 at 8:23 PM, Andrew Dunstan 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 defaul
On Tue, Sep 22, 2009 at 1:26 PM, 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 cert
On Tue, Sep 22, 2009 at 1:29 PM, Jaime Casanova
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 to do,
without restricting
On Tue, Sep 22, 2009 at 01:50:45PM -0400, Robert Haas wrote:
> On Tue, Sep 22, 2009 at 1:26 PM, 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 onl
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
no
On Tue, Sep 22, 2009 at 12:53 PM, Robert Haas wrote:
> On Tue, Sep 22, 2009 at 1:29 PM, Jaime Casanova
> 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 doo
Robert Haas 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, so I'm having a hard
Merlin Moncure 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 writes:
> Merlin Moncure 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
> is
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 res
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 l
Petr Jelinek 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
expansibility (eg adding
On Wed, 2009-09-09 at 18:26 +0300, Marko Kreen wrote:
> Unicode escapes for extended strings.
>
> On 4/16/09, Marko Kreen 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 stdstr
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
> (http://wiki.postgres
> 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 i
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 acc
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 (pgs
Josh Berkus 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 better partitio
On Wed, Sep 9, 2009 at 11:25 PM, Andrew Gierth
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 would
> >> apply
Robert Haas 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 a joinrel. It se
Tom Lane napsal(a):
Petr Jelinek 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 fu
Stephen Frost wrote:
Mark,
Your last email on this patch, from August 9th, indicates that you've
still got "TODO: redo pg_stat_lock_waits ...". Has you updated this
patch since then?
Stephen,
No - that is still a TODO for me - real life getting in the way :-)
Cheers
Mark
--
S
46 matches
Mail list logo
