On Tue, 2010-06-08 at 15:46 -0400, Tom Lane wrote:
> Josh Berkus writes:
> > Let's get 9.0 out the door, hey?
>
> What we actually need is some testing effort. The lack of bug reports
> against Hot Standby, in particular, is proof positive that no meaningful
> testing is happening.
Absence of e
(2010/06/08 11:15), Robert Haas wrote:
> 2010/6/7 KaiGai Kohei:
>> Our headache is on functions categorized to middle-threat. It enables to
>> leak the given arguments using error messages. Here are several ideas,
>> but they have good and bad points.
>
> I think we are altogether off in the weeds
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan wrote:
> There is precedent for .pgpass being a bit ambiguous. See the way
> "localhost" is used.
OK. The attached patch allows us to use "replication" in the database
field of the .pgpass file, for the replication connection.
Regards,
--
Fujii M
Hello,
I'd like to experiment on compiling postgres with LLVM (either llvm-gcc or
clang) on Linux, is it supported ? Where should I start ?
Thanks ;)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
Fujii Masao wrote:
Tom's proposal is very small, but we cannot distinguish the password
for replication purpose from that for the real database named "replication".
Is this OK? I can live with this as far as it's documented.
There is precedent for .pgpass being a bit ambiguous. See the wa
On Tue, Jun 8, 2010 at 10:18 PM, Takahiro Itagaki
wrote:
>
> Robert Haas wrote:
>> I think we're replacing restartpoint_command, not recovery_end_command.
>
> Ah, sorry. I did the same replacement for restartpoint_command
> in _, -, and camel case words.
Gah. Perhaps one of these days we will s
On Wed, Jun 2, 2010 at 10:24 PM, Fujii Masao wrote:
> On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas
> wrote:
>> On 02/06/10 06:23, Fujii Masao wrote:
>>>
>>> On Mon, May 31, 2010 at 7:17 PM, Fujii Masao
>>> wrote:
4) Change it so that checkpoint_segments takes effect in standby mo
Robert Haas wrote:
> I think we're replacing restartpoint_command, not recovery_end_command.
Ah, sorry. I did the same replacement for restartpoint_command
in _, -, and camel case words.
BTW, should we also have a release note for the command?
I added a simple description for it in the patch.
On Tue, Jun 8, 2010 at 1:13 PM, Tom Lane wrote:
> Fujii Masao writes:
>> Hmm.. is it worth going back to my proposal?
>
> I don't recall exactly what proposal you might be referring to, but
http://archives.postgresql.org/pgsql-hackers/2010-01/msg00400.php
> I'm hesitant to put any large amount
On Wed, Jun 9, 2010 at 10:45 AM, Takahiro Itagaki
wrote:
>
> Robert Haas wrote:
>
>> On Tue, Jun 8, 2010 at 6:45 PM, Tom Lane wrote:
>> > Andrew Dunstan writes:
>> >> I prefer archive_cleanup_command. We should name things after their
>> >> principal function, not an implementation detail, IMNS
On Tue, Jun 8, 2010 at 9:45 PM, Takahiro Itagaki
wrote:
> Robert Haas wrote:
>
>> On Tue, Jun 8, 2010 at 6:45 PM, Tom Lane wrote:
>> > Andrew Dunstan writes:
>> >> I prefer archive_cleanup_command. We should name things after their
>> >> principal function, not an implementation detail, IMNSHO.
On Tue, Jun 8, 2010 at 9:37 AM, Greg Sabino Mullane wrote:
> When I get some free time, I'll make a patch to implement as much of
> the spec as we sanely can.
Saying that you'll fix it but not on any particular timetable is
basically equivalent to saying that you're not willing to fix it at
all.
Robert Haas wrote:
> On Tue, Jun 8, 2010 at 6:45 PM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> I prefer archive_cleanup_command. We should name things after their
> >> principal function, not an implementation detail, IMNSHO.
> >
> > Weak preference for archive_cleanup_command here.
>
>
On Tue, Jun 8, 2010 at 6:20 PM, Josh Berkus wrote:
>> If I simply start overhauling the list without explaining what I
>> perceive to be the systematic problems with it, then I will get yelled
>> at for failing to follow community process.
>
> Nonsense. The one good thing about admin stuff in th
On Tue, Jun 8, 2010 at 6:45 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I prefer archive_cleanup_command. We should name things after their
>> principal function, not an implementation detail, IMNSHO.
>
> Weak preference for archive_cleanup_command here.
OK, sounds like we have consensus on
On Tue, Jun 8, 2010 at 6:35 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Tue, 2010-06-08 at 18:03 -0400, Robert Haas wrote:
>>> OK, yes, I see what you're getting at now. There are two possible
>>> ways to do freeze the tuples and keep the xmin: we can either rely on
>>> the PD_ALL_VISIBLE pa
Excerpts from Tom Lane's message of mar jun 08 18:35:00 -0400 2010:
> But none of this accomplishes a damn thing towards the original goal,
> which was to avoid an extra disk write associated with freezing (not
> to mention an extra write for setting the transaction-committed hint
> bit). Setting
Tom Lane wrote:
As for the language choice, my first thought is +1 for perl over shell,
mainly because it might be directly useful to people on Windows while
shell never would be. On the other hand, if it's possible to do a
useful one-liner in shell then let's do it that way.
I don't thin
Andrew Dunstan writes:
> I prefer archive_cleanup_command. We should name things after their
> principal function, not an implementation detail, IMNSHO.
Weak preference for archive_cleanup_command here.
> More importantly, we should include an example in the docs. I created
> one the other day
Simon Riggs writes:
> On Tue, 2010-06-08 at 18:03 -0400, Robert Haas wrote:
>> OK, yes, I see what you're getting at now. There are two possible
>> ways to do freeze the tuples and keep the xmin: we can either rely on
>> the PD_ALL_VISIBLE page-level bit (as I previously proposed) or we can
>> ad
Tom Lane wrote:
Andrew Dunstan writes:
Well, yes. But then to stop that you could just lock users out using
pg_hba.conf, no? It just doesn't seem to be buying all that much to me.
The main reason to turn it off is to disable a whole lot of very poorly
tested code, and thereby impro
Robert Haas wrote:
On Mon, Mar 22, 2010 at 11:58 AM, Greg Stark wrote:
On Thu, Mar 18, 2010 at 9:43 AM, Simon Riggs wrote:
On Wed, 2010-03-17 at 11:37 +0200, Heikki Linnakangas wrote:
One awkward omission in the new built-in standby mode, mainly used for
streaming replicati
> Whoa, there. There is not any way of moving forward with this list
> without explaining why the list in its present form is not too useful.
Ah, the way I read your post was "the list is not useful therefore I
will ignore it." From that perspective it was important for me to
respond to you lest
On Tue, 2010-06-08 at 18:03 -0400, Robert Haas wrote:
> OK, yes, I see what you're getting at now. There are two possible
> ways to do freeze the tuples and keep the xmin: we can either rely on
> the PD_ALL_VISIBLE page-level bit (as I previously proposed) or we can
> additionally have a HEAP_XMIN
On Tue, Jun 8, 2010 at 5:08 PM, Simon Riggs wrote:
>> > Why not just have a separate flag for HEAP_XMIN_FROZEN, that way we can
>> > keep the xmin but also can see it is frozen?
>>
>> We could do that, but I think the point of this exercise is to reduce
>> I/O - specifically, I/O caused by anti-wr
On Tue, Jun 8, 2010 at 5:13 PM, Josh Berkus wrote:
> On 6/8/10 2:01 PM, Robert Haas wrote:
>> I appreciate the effort that went into making this list, but it's not
>> very useful to work off of any more. The problem is that the set of
>> things that is listed here is pretty erratic - there are ac
On Jun 8, 2010, at 12:34 PM, Merlin Moncure wrote:
> hm. any chance of a shorter operator, like '#'? I kinda agree that
> hstore_in and the operator don't have to be the same, but requiring
> three letter token for the two most high traffic operations w/hstore
> seems off to me.
>
> # is curre
On Tue, 2010-06-08 at 17:17 -0400, Robert Haas wrote:
> On Mon, Mar 22, 2010 at 11:58 AM, Greg Stark wrote:
> > On Thu, Mar 18, 2010 at 9:43 AM, Simon Riggs wrote:
> >> On Wed, 2010-03-17 at 11:37 +0200, Heikki Linnakangas wrote:
> >>
> >>> One awkward omission in the new built-in standby mode, m
On Tue, Jun 08, 2010 at 03:46:06PM -0400, Tom Lane wrote:
> Josh Berkus writes:
> > Let's get 9.0 out the door, hey?
>
> What we actually need is some testing effort. The lack of bug
> reports against Hot Standby, in particular, is proof positive that
> no meaningful testing is happening. (If y
Andrew Dunstan writes:
> Well, yes. But then to stop that you could just lock users out using
> pg_hba.conf, no? It just doesn't seem to be buying all that much to me.
The main reason to turn it off is to disable a whole lot of very poorly
tested code, and thereby improve the reliability of you
On Mon, Mar 22, 2010 at 11:58 AM, Greg Stark wrote:
> On Thu, Mar 18, 2010 at 9:43 AM, Simon Riggs wrote:
>> On Wed, 2010-03-17 at 11:37 +0200, Heikki Linnakangas wrote:
>>
>>> One awkward omission in the new built-in standby mode, mainly used for
>>> streaming replication, is that there is no ea
On 6/8/10 2:01 PM, Robert Haas wrote:
> I appreciate the effort that went into making this list, but it's not
> very useful to work off of any more. The problem is that the set of
> things that is listed here is pretty erratic - there are actual
> problems that are not on this list, and there are
On Tue, 2010-06-08 at 16:58 -0400, Robert Haas wrote:
> On Tue, Jun 8, 2010 at 4:55 PM, Simon Riggs wrote:
> > On Fri, 2010-06-04 at 10:18 -0400, Tom Lane wrote:
> >> Jan Wieck writes:
> >> > On 6/2/2010 3:10 PM, Alvaro Herrera wrote:
> >> >> I'd prefer a setting that would tell the system to fre
On Tue, Jun 8, 2010 at 4:54 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>> On Thu, Jun 3, 2010 at 11:15 PM, Andrew Dunstan
>> wrote:
>>> The docs don't seem to contain any discussion I could find on why one
>>> might
>>> not want hot_standby on. Maybe it's just too obvious to most people, but
On Tue, 2010-06-08 at 16:47 -0400, Robert Haas wrote:
> On Thu, May 27, 2010 at 9:22 AM, Heikki Linnakangas
> wrote:
> > On 27/05/10 12:39, Dimitri Fontaine wrote:
> >>
> >> Greg Stark writes:
> >>>
> >>> Fwiw I like the word "replica" but I don't see an obvious choice of
> >>> word to pair it wi
On Tue, Jun 8, 2010 at 1:32 PM, Josh Berkus wrote:
> However, I haven't see much progress in the last 10 days on closing any
> of these issues, and quite a few people have moved on to 9.1 features.
I appreciate the effort that went into making this list, but it's not
very useful to work off of an
On Tue, Jun 8, 2010 at 4:55 PM, Simon Riggs wrote:
> On Fri, 2010-06-04 at 10:18 -0400, Tom Lane wrote:
>> Jan Wieck writes:
>> > On 6/2/2010 3:10 PM, Alvaro Herrera wrote:
>> >> I'd prefer a setting that would tell the system to freeze all tuples
>> >> that fall within a safety range whenever an
On Fri, 2010-06-04 at 10:18 -0400, Tom Lane wrote:
> Jan Wieck writes:
> > On 6/2/2010 3:10 PM, Alvaro Herrera wrote:
> >> I'd prefer a setting that would tell the system to freeze all tuples
> >> that fall within a safety range whenever any tuple in the page is frozen
> >> -- weren't you working
Robert Haas wrote:
On Thu, Jun 3, 2010 at 11:15 PM, Andrew Dunstan
wrote:
The docs don't seem to contain any discussion I could find on why one might
not want hot_standby on. Maybe it's just too obvious to most people, but
this seems to be a bit lacking in the docs.
Well, if you don't
On Thu, May 27, 2010 at 9:22 AM, Heikki Linnakangas
wrote:
> On 27/05/10 12:39, Dimitri Fontaine wrote:
>>
>> Greg Stark writes:
>>>
>>> Fwiw I like the word "replica" but I don't see an obvious choice of
>>> word to pair it with
>>
>> I guess it's replica / origin, per choice of Jan Wieck to be
On Thu, Jun 3, 2010 at 11:15 PM, Andrew Dunstan
wrote:
> The docs don't seem to contain any discussion I could find on why one might
> not want hot_standby on. Maybe it's just too obvious to most people, but
> this seems to be a bit lacking in the docs.
Well, if you don't want your slave to proce
On Jun 8, 2010, at 16:17 , Robert Haas wrote:
>> (That's enough bikeshedding for me.)
>
> Test first, then post? :-)
What? :) If I was productively contributing, I wouldn't be bikeshedding, now
would I?
Michael Glaesemann
grzm seespotcode net
--
Sent via pgsql-hackers mailing list (pgs
On Jun 8, 2010, at 15:38 , Robert Haas wrote:
> On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure wrote:
>> hm. any chance of a shorter operator, like '#'? I kinda agree that
>> hstore_in and the operator don't have to be the same, but requiring
>> three letter token for the two most high traffi
On Wed, May 26, 2010 at 11:24 PM, Joshua Tolley wrote:
> On Wed, May 26, 2010 at 03:47:25PM -0400, Robert Haas wrote:
>> On Tue, May 25, 2010 at 4:34 AM, Jonathan Leto wrote:
>> > This tiny doc patch adds _PG_init to the skeleton example code for a
>> > PL. The information is quite valuable to PL
On Tue, Jun 8, 2010 at 3:56 PM, Michael Glaesemann wrote:
> On Jun 8, 2010, at 15:38 , Robert Haas wrote:
>> On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure wrote:
>>> hm. any chance of a shorter operator, like '#'? I kinda agree that
>>> hstore_in and the operator don't have to be the same, bu
Tom Lane wrote:
Pavel Stehule writes:
p.s. I hope so in 9.1 will be complete hstore module marked as deprecated
Really? And replaced with what? And why wouldn't the replacement use
the same operator names?
Yeah. I'll be looking for throats to cut if
Josh Berkus writes:
> Let's get 9.0 out the door, hey?
What we actually need is some testing effort. The lack of bug reports
against Hot Standby, in particular, is proof positive that no meaningful
testing is happening. (If you think it means HS is bug-free, I have a
nice bridge I'd like to int
Pavel Stehule writes:
> p.s. I hope so in 9.1 will be complete hstore module marked as deprecated
Really? And replaced with what? And why wouldn't the replacement use
the same operator names?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
2010/6/8 Merlin Moncure :
> On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas wrote:
>> I believe that the consensus was mostly in favor of deprecating => as
>> an operator name, with the intent to abolish it completely in a future
>> release. Attached is a patch to implement ==> as an alternative
>> o
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure wrote:
> On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas wrote:
>> I believe that the consensus was mostly in favor of deprecating => as
>> an operator name, with the intent to abolish it completely in a future
>> release. Attached is a patch to impleme
I wrote:
> I realized this while thinking about Jeff Amiel's report here:
> http://archives.postgresql.org/pgsql-general/2010-06/msg00351.php
> I can't prove that this is what's causing his crashes, but it could
> produce the symptom he's reporting.
Actually, no it can't: the case I'm envisioning
On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas wrote:
> I believe that the consensus was mostly in favor of deprecating => as
> an operator name, with the intent to abolish it completely in a future
> release. Attached is a patch to implement ==> as an alternative
> operator name for hstore, and to
I believe that the consensus was mostly in favor of deprecating => as
an operator name, with the intent to abolish it completely in a future
release. Attached is a patch to implement ==> as an alternative
operator name for hstore, and to make the backend throw a warning when
=> is used as an opera
The btree page deletion logic has a restriction that it cannot delete
the rightmost child page of any non-leaf btree page (see nbtree/README
for explanations). This is checked by _bt_parent_deletion_safe(),
which claims
* Note: it's OK to release page locks after checking, because a safe
* dele
On Tue, Jun 8, 2010 at 8:53 AM, Greg Stark wrote:
> On Tue, Jun 8, 2010 at 12:40 PM, Robert Haas wrote:
>> On Sun, Jun 6, 2010 at 10:24 AM, Alexander Korotkov
>> wrote:
>>> I think that such parameters don't have optimal value for all the cases;
>>
>> What makes you think that?
>
> Actually the
All,
Selena (and others) have done a terrific job on the Open Items list for
9.0.:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
However, I haven't see much progress in the last 10 days on closing any
of these issues, and quite a few people have moved on to 9.1 features.
If you are
Teodor Sigaev writes:
> The way to reproduce:
Well, of course plpython's error handling is fundamentally brain dead.
The immediate problem here seems to be that the PLy_error_in_progress
struct is stored in a memory context that's been cleared by the time
that control gets to the place in PLy_pr
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Hm. The problem with that is that one of the benefits we'd like to get
> from this is an efficiency win: the generated plan ought to only group
> by the PK, not uselessly sort/group by everything in the row. I suppose
> we could have the planner reverse-en
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Perhaps the correct fix would be to mark stored query trees as having a
>> dependency on the index, so that dropping the index/constraint would
>> force a drop of the rule too.
> Alternatively, we could rewrite the rule (not unlike
On Tue, Jun 8, 2010 at 3:21 PM, Tom Lane wrote:
> The question is why bother to recognize *any* cases of this form.
> I find it really semantically ugly to have the parser effectively
> doing one deduction of this form when the main engine for that type
> of deduction is elsewhere; so unless ther
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Perhaps the correct fix would be to mark stored query trees as having a
> dependency on the index, so that dropping the index/constraint would
> force a drop of the rule too. Just pushing the check to plan time, as
> I suggested yesterday, isn't a very nice
On 6/8/10 5:21 PM +0300, Tom Lane wrote:
Peter Eisentraut writes:
On tis, 2010-06-08 at 09:59 +0900, Hitoshi Harada wrote:
In addition, what if y is implicitly a constant? For example,
SELECT x, y FROM tab2 WHERE y = a AND a = 5 GROUP BY x;
Yes, as I said, my implementation is incomplete i
Peter Eisentraut writes:
> On tis, 2010-06-08 at 09:59 +0900, Hitoshi Harada wrote:
>> In addition, what if y is implicitly a constant? For example,
>>
>> SELECT x, y FROM tab2 WHERE y = a AND a = 5 GROUP BY x;
> Yes, as I said, my implementation is incomplete in the sense that it
> only recogni
On Tue, Jun 8, 2010 at 3:05 PM, Tom Lane wrote:
> Well, no, any cached plan will get invalidated if the index goes away.
> The big problem with this implementation is that you could create a
> *rule* (eg a view) containing a query whose validity depends on the
> existence of an index. Dropping th
On 6/8/2010 8:27 AM, Greg Stark wrote:
On Tue, Jun 8, 2010 at 2:26 AM, Stephen Frost wrote:
Just an off-the-wall thought, but, would it be possible to have a tool
which read WAL backwards and compared entries in the WAL against entries
on disk? I realize that you'd only see one version of a pa
Greg Stark writes:
> On Tue, Jun 8, 2010 at 4:16 AM, Tom Lane wrote:
>> The main objection to this is the same one I've had all along: it makes
>> the syntactic validity of a query dependent on what indexes exist for
>> the table. At minimum, that means that enforcing the check at parse
>> time
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> But YAML is not human-readable. There are human-readable subsets of
> it, but the general serializers do not produce them, and specific
> serializers are difficult to get right (as we've seen).
No, it *is* human readable. Indeed, that's one
* Greg Stark (gsst...@mit.edu) wrote:
> I assume you mean back out the changes incrementally until you find a
> full_page_write and see if it matches?
To be honest, you're already assuming I know more about how this all
works than I do. :) The gist of my thought was simply- we write out
block cha
On Tue, Jun 8, 2010 at 12:40 PM, Robert Haas wrote:
> On Sun, Jun 6, 2010 at 10:24 AM, Alexander Korotkov
> wrote:
>> I think that such parameters don't have optimal value for all the cases;
>
> What makes you think that?
Actually the whole signature method is a bit of a crock. I posted
about th
On Tue, Jun 8, 2010 at 4:16 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> I have developed a patch that partially implements the "functional
>> dependency" feature that allows some columns to be omitted from the
>> GROUP BY clause if it can be shown that the columns are functionally
>> depend
On Tue, Jun 8, 2010 at 2:26 AM, Stephen Frost wrote:
> Just an off-the-wall thought, but, would it be possible to have a tool
> which read WAL backwards and compared entries in the WAL against entries
> on disk? I realize that you'd only see one version of a particular
> block and then have to sk
Hi,
I tried getting the source using:
git clone http://git.postgresql.org/git/postgresql.git postgresql-git
but after a while (252MB) I always get:
[...]
Getting pack 61e1395a5bdacda95de5432123a0f8124fff05e6
which contains 476418893d3a2f366f47dbe4ce6d7522cc427545
error: Unable to get pack file
On Sun, Jun 6, 2010 at 10:24 AM, Alexander Korotkov
wrote:
> I think that such parameters don't have optimal value for all the cases;
What makes you think that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list (pgs
Hi Takahiro,
Here is an updated version of the patch.
Thanks Magnus H for the help :)
1.4: Ported to head. Updated tests. Removed pg_stat_report.
2010/5/25 Takahiro Itagaki
>
> Joel Jacobson wrote:
>
> > I applied all the changes on 9.0beta manually and then it compiled
> without
> > any as
The linux kernel also uses it when it's availabe, see e.g.
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/arch/x86/crypto/crc32c-intel.c
If you guys are interested I have a Core i7 here, could run a little
benchmark.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
On Mon, Jun 7, 2010 at 6:41 PM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> This is frequently requested by MySQL converts (and possibly others).
>
> I'd certainly love to see it- but let's not confuse people by implying
> that it would actually act the way MySQL does. I
The way to reproduce:
CREATE OR REPLACE FUNCTION foobar(a integer[])
RETURNS SETOF int8 AS
$$
def getplan(name, query, args):
if SD.has_key(name):
plpy.warning("Using cached plan %s" % name)
return SD[name]
plpy.warning("Prepare plan %s" % name);
On tis, 2010-06-08 at 09:59 +0900, Hitoshi Harada wrote:
> > Also, when a column is compared with a constant, it can appear
> > ungrouped:
> >
> > SELECT x, y FROM tab2 WHERE y = 5 GROUP BY x;
>
> I don't see why it should be allowed. I see the insist that y must be
> unique value so it is ok to b
* Greg Smith:
> Florian Weimer wrote:
>> It has been claimed before that YAML is a superset of JSON, so why
>> can't the YAML folks use the existing JSON output instead?
>>
>
> Because JSON just crosses the line where it feels like there's so much
> markup that people expect a tool is necessary
79 matches
Mail list logo
