Robert Haas robertmh...@gmail.com wrote:
I've taken a little bit more of a look at this patch and I guess I'm
not too happy with the design.
Thanks. I was thinking about only syntax for partitioning in the patch,
but I need more consideration about insert-aware catalog design.
5. The use of
LinkedIn
Gourish Singbal souhaite se connecter à vous sur LinkedIn :
--
Amine,
I'd like to add you to my professional network on LinkedIn.
- Gourish
Accepter l'invitation de Gourish Singbal
Hi all,
I joined this list under the mis-impression that it was about hacking
the Python interfaces to pgsql. Is there possibly another list for
that? Or is the Python stuff just mixed in with all the rest? Sorry
for the meta-question...
Cheers,
Peter
--
Peter H. Froehlich
Leonardo F m_li...@yahoo.it wrote:
I saw that you also changed the writing:
(snip)
Are we sure it's 100% equivalent?
I think writetup_rawheap() and readtup_rawheap() are a little complex,
but should work as long as there are no padding between t_len and t_self
in HeapTupleData struct.
- It
Robert Haas robertmh...@gmail.com writes:
If it's unsafe to send written but unflushed WAL to the standby, then
for the same reasons we can't send unwritten WAL either.
[...]
Having said that, I do think we urgently need some high-level design
discussion on how sync rep is actually going to
In the previous discussions of how to migrate from cvs to git, we've
all agreed we should kill the keyword expansion that we have now. I
don't think, however, that we ever decided what to do with the *old*
keywords. We did say we want to be able to reproduce backbranches/tags
*identically* to what
On Wed, Jul 7, 2010 at 10:01 AM, Magnus Hagander mag...@hagander.net wrote:
1) We can migrate the repository with the keywords, and then make one big
commit just after (or before, that doesn't make a difference) removing
them. In this case, backbranches and tags look exactly like they do
now,
On Wed, Jul 7, 2010 at 4:40 AM, Dimitri Fontaine dfonta...@hi-media.com wrote:
Stop me if I'm all wrong already, but I though we said that we should
handle this case by decoupling what we can send to the standby and what
it can apply. We could do this by sending the current WAL fsync'ed
On Wed, Jul 7, 2010 at 3:07 AM, Peter Froehlich
peter.hans.froehl...@gmail.com wrote:
I joined this list under the mis-impression that it was about hacking
the Python interfaces to pgsql. Is there possibly another list for
that? Or is the Python stuff just mixed in with all the rest? Sorry
for
On ons, 2010-07-07 at 03:07 -0400, Peter Froehlich wrote:
I joined this list under the mis-impression that it was about hacking
the Python interfaces to pgsql. Is there possibly another list for
that? Or is the Python stuff just mixed in with all the rest? Sorry
for the meta-question...
If
On Wed, Jul 7, 2010 at 2:14 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
5. The use of the term partition is not very consistent. For
example, we use CREATE PARTITION to create a partition, but we use
DROP TABLE to get rid of it (there is no DROP PARTITION). I think
that the
On Tue, Jul 6, 2010 at 1:08 PM, Pavel Golub pa...@microolap.com wrote:
While I'm very excited about enabling keepalives in libpq, I want to
know how can I use this functionality in my application?
Let's imagine that I connect to a server with keepalives option, other
options (keepalives_idle,
On Wed, Jun 30, 2010 at 17:46, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I also think we may want to suggest that for most environments,
people may want to change these settings to something more
aggressive, like a 30 to 120 second initial delay,
On Wed, Jul 7, 2010 at 9:20 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Jun 30, 2010 at 17:46, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I also think we may want to suggest that for most environments,
people may want to change these
Magnus Hagander mag...@hagander.net wrote:
It'll now set them to 2 hours/1 second by default. I looked
quickly at the RFC and didn't find the exact values there, so those
values are the documented out-of-the-box defaults on Windows. I
can easily change them to RFC values if someone can find
Robert Haas wrote:
(BTW, there are two buildfarm machines - wigeon and orangutan - that
are consistently failing with rather bizarre error messages. Are
these real failures or are those machines just messed up?)
Dave and Scott,
please investigate these errors in your buildfarm members.
Rajanikant Chirmade rajanikant.chirm...@enterprisedb.com writes:
Every identifier is downcase truncated by function
downcase_truncate_identifier()
before using it.
But since the function downcase_truncate_identifier() is not
multibyte-charecter aware,
it is not able to downcase some of
Dimitri Fontaine dfonta...@hi-media.com writes:
Stop me if I'm all wrong already, but I though we said that we should
handle this case by decoupling what we can send to the standby and what
it can apply.
What's the point of that? It won't make the standby apply any faster.
What it will do is
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dfonta...@hi-media.com writes:
Stop me if I'm all wrong already, but I though we said that we should
handle this case by decoupling what we can send to the standby and what
it can apply.
What's the point of that? It won't make the standby
Magnus Hagander wrote:
In the previous discussions of how to migrate from cvs to git, we've
all agreed we should kill the keyword expansion that we have now. I
don't think, however, that we ever decided what to do with the *old*
keywords. We did say we want to be able to reproduce
Dave Page dp...@pgadmin.org writes:
On Wed, Jul 7, 2010 at 10:01 AM, Magnus Hagander mag...@hagander.net wrote:
1) We can migrate the repository with the keywords, and then make one big
commit just after (or before, that doesn't make a difference) removing
them. In this case, backbranches and
On Wed, Jul 7, 2010 at 3:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One point that isn't completely clear from Magnus' description is
whether we should remove the $PostgreSQL$ lines from the HEAD branch
only, or from the still-active back branches as well. I vote for the
latter --- that is, if
On Wed, Jul 7, 2010 at 5:01 AM, Magnus Hagander mag...@hagander.net wrote:
In the previous discussions of how to migrate from cvs to git, we've
all agreed we should kill the keyword expansion that we have now. I
don't think, however, that we ever decided what to do with the *old*
keywords. We
* Dave Page dp...@pgadmin.org [100707 05:05]:
+1 for #1. Changing history and the resulting possibility of becoming
one's own grandfather always makes me nervous.
But, since we're already using CVS, our grandfather is already our
granddaughter...
I'll just point out that if you expand the
Robert Haas robertmh...@gmail.com writes:
So what happens right now using the existing git repository is that
the $PostgeSQL$ tags are there, but they're unexpanded. They just say
$PostgreSQL$ rather than $PostgreSQL: tgl blah blah$.
Really? All of them? Seems like that would have taken
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
I think all of the following codes work in the same way
at least on Windows, where the codes are actually used.
utf16[dstlen] = L'\0';
utf16[dstlen] = '\0';
utf16[dstlen] = 0;
utf16[dstlen] = (WCHAR) 0;
The last one
On Wed, Jul 7, 2010 at 8:49 AM, Peter Eisentraut pete...@gmx.net wrote:
If you want to hack PL/Python, which is a Python interpreter embedded
into the PostgreSQL server, then this is the right place. (Yes, it's
mixed with all the rest.)
If you want to hack a Python client driver, then go to
Tom Lane t...@sss.pgh.pa.us wrote:
1) We can migrate the repository with the keywords, and then make one big
commit just after (or before, that doesn't make a difference) removing
them. In this case, backbranches and tags look exactly like they do
now, but it also means if you do git diff
Peter Eisentraut wrote:
On lör, 2010-07-03 at 09:26 +0100, Mike Fowler wrote:
What I will do
instead is implement the xml_is_well_formed function and get a patch
out in the next day or two.
That sounds very useful.
Here's the patch to add the 'xml_is_well_formed' function.
On 07/07/10 17:19, Peter Froehlich wrote:
On Wed, Jul 7, 2010 at 8:49 AM, Peter Eisentrautpete...@gmx.net wrote:
If you want to hack PL/Python, which is a Python interpreter embedded
into the PostgreSQL server, then this is the right place. (Yes, it's
mixed with all the rest.)
If you want to
Excerpts from Takahiro Itagaki's message of mié jul 07 04:39:38 -0400 2010:
BTW, we could have LogicalTapeReadExact() as an alias of
LogicalTapeRead() and checking the result because we have
many duplicated codes for unexpected end of data errors.
I'd just add a boolean exact required to the
On Wed, Jul 7, 2010 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So what happens right now using the existing git repository is that
the $PostgeSQL$ tags are there, but they're unexpanded. They just say
$PostgreSQL$ rather than $PostgreSQL: tgl
Excerpts from Robert Haas's message of mar jul 06 17:24:21 -0400 2010:
On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan and...@dunslane.net wrote:
In any case, having a mutable logical column
position is the feature that's been most requested.
I think that's true. But the physical storage
Robert Haas wrote:
So what happens right now using the existing git repository is that
the $PostgeSQL$ tags are there, but they're unexpanded. They just say
$PostgreSQL$ rather than $PostgreSQL: tgl blah blah$. I'm all in
favor of removing them, but it would be nice if we could avoid
On Wed, Jul 7, 2010 at 20:31, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
So what happens right now using the existing git repository is that
the $PostgeSQL$ tags are there, but they're unexpanded. They just say
$PostgreSQL$ rather than $PostgreSQL: tgl blah blah$. I'm
On Wed, Jul 7, 2010 at 16:40, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Jul 7, 2010 at 10:01 AM, Magnus Hagander mag...@hagander.net wrote:
1) We can migrate the repository with the keywords, and then make one big
commit just after (or before, that doesn't
On Jul 7, 2010, at 12:07 AM, Peter Froehlich wrote:
I joined this list under the mis-impression that it was about hacking
the Python interfaces to pgsql. Is there possibly another list for
that? Or is the Python stuff just mixed in with all the rest? Sorry
for the meta-question...
For BSD/MIT
On Wed, Jul 7, 2010 at 1:29 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar jul 06 17:24:21 -0400 2010:
On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan and...@dunslane.net wrote:
In any case, having a mutable logical column
position is the
On tis, 2010-07-06 at 18:15 -0400, Tom Lane wrote:
At this point it seems clear to me that we've not adequately thought
through the implications of having two python versions in one
application namespace, and I'm not sure the Python people have either.
I think we need to do something to block
On 7/3/10 10:07 AM, Tom Lane wrote:
It seems to me it ought to be PGC_SIGHUP.
+1
I believe it's userset because the other vacuum parameters are, and that
nobody thought about it much.
--
-- Josh Berkus
PostgreSQL Experts
Peter Eisentraut pete...@gmx.net writes:
On tis, 2010-07-06 at 18:15 -0400, Tom Lane wrote:
At this point it seems clear to me that we've not adequately thought
through the implications of having two python versions in one
application namespace, and I'm not sure the Python people have either.
On 7/6/10 4:44 PM, Robert Haas wrote:
To recap the previous discussion on this thread, we ended up changing
the behavior of 9.0 so that it only sends WAL which has been written
to the OS *and flushed*, because sending unflushed WAL to the standby
is unsafe. The standby can get ahead of the
On 7/6/10 8:06 AM, Tom Lane wrote:
It might be that nobody's using any values other than 0 and -1 ...
in which case it wouldn't matter anyway. I agree that the lack of
bug reports is notable. But still, don't we try to avoid behavioral
changes in stable branches?
I think most people are
On Tue, Jul 6, 2010 at 10:59 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar jul 06 22:31:40 -0400 2010:
On Tue, Jul 6, 2010 at 10:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Obviously not. We don't need
On Wed, Jul 7, 2010 at 6:44 PM, Josh Berkus j...@agliodbs.com wrote:
On 7/6/10 4:44 PM, Robert Haas wrote:
To recap the previous discussion on this thread, we ended up changing
the behavior of 9.0 so that it only sends WAL which has been written
to the OS *and flushed*, because sending
Merlin sent me a test case off-list for the problem mentioned here:
http://archives.postgresql.org/pgsql-bugs/2010-07/msg00025.php
After some investigation I was able to simplify it to the following
example using the regression database:
select
(select sq1) as qq1
from
(select exists(select
On Wed, Jul 7, 2010 at 6:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
After some investigation I was able to simplify it to the following
example using the regression database:
select
(select sq1) as qq1
from
(select exists(select 1 from int4_tbl where f1 = q2) as sq1, 42 as dummy
from
On Mon, Jun 14, 2010 at 12:25 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
The PostgreSQL 9.1 Development Plan:
http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan
calls for a ReviewFest to run from the 15th of June (tomorrow) until
the start of the first CommitFest for
Robert Haas robertmh...@gmail.com writes:
I'm lost. What's a join alias var?
Suppose we have t1 with columns a,b,c and t2 with columns d,e,f, then
consider
select a from t1 join t2 on (whatever)
select t1.a from t1 join t2 on (whatever)
In the first case the parser generates a
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 6, 2010 at 10:59 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar jul 06 22:31:40 -0400 2010:
Hmm... so, maybe ShareUpdateExclusiveLock?
So COMMENT ON will conflict with (auto)vacuum? Seems
2010/7/8 Josh Berkus j...@agliodbs.com:
On 7/6/10 8:06 AM, Tom Lane wrote:
It might be that nobody's using any values other than 0 and -1 ...
in which case it wouldn't matter anyway. I agree that the lack of
bug reports is notable. But still, don't we try to avoid behavioral
changes in
On Wed, Jul 7, 2010 at 7:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Anyway, the way it works is that the parser generates alias Vars that
refer to the join RTE, mainly because this makes life simpler for
ruleutils. But the planner prefers to work with the real underlying
columns whenever those
2010/3/3 Bruce Momjian br...@momjian.us:
Peter Eisentraut wrote:
On m?n, 2010-02-22 at 10:32 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
On Wed, Jul 7, 2010 at 9:04 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
I assume this did not get done for 9.0. Do we want a TODO item?
Yes.
Added:
Reduce locking required for ALTER commands
I just faced production issue where it is impossible to alter table to
Pavel Stehule pavel.steh...@gmail.com wrote:
this version has enhanced AllocSet allocator - it can use a mmap API.
I review your patch and will report some comments. However, I don't have
test cases for the patch because there is no large dictionaries in the
default postgres installation. I'd
Having said that, I do think we urgently need some high-level design
discussion on how sync rep is actually going to handle this issue
(perhaps on a new thread). If we can't resolve this issue, sync rep
is going to be really slow; but there are no easy solutions to this
problem in sight, so
Are these improvements (index creation time, index size) worth enough
to keep on working on this?
I mean: given that bitmaps don't give any benefits in query times, but
only benefits related to disk size and bulk index creation times, and
will have horrible performance for
57 matches
Mail list logo
