On Thu, 2011-06-30 at 12:28 +0200, Florian Pflug wrote:
> Well, arrays are containers, and we need two values to construct a range,
What about empty ranges? What about infinite ranges?
It seems quite a bit more awkward to shoehorn ranges into an array than
to use a real type (even if it's interme
On Thu, 2011-06-30 at 09:59 -0700, David E. Wheeler wrote:
> On Jun 30, 2011, at 9:34 AM, Jeff Davis wrote:
>
> > Then how do you get a text range that doesn't correspond to the
> > LC_COLLATE setting?
>
> You cast it.
My original solution was something like this, except involving domains.
With
On Fri, Jul 1, 2011 at 2:18 PM, Mikko Partio wrote:
> Hello list
> I have two a machine cluster with PostgreSQL 9.0.4 and streaming
> replication. In a normal situation I did a failover -- touched the trigger
> file in standby to promote it to production mode. I have done this
> previously without
On Fri, Jul 1, 2011 at 03:36, Alvaro Herrera wrote:
> Excerpts from Stephen Frost's message of jue jun 30 18:35:40 -0400 2011:
>
>> > I know of no such list, and I think this field
>> > useful/important enough that people who are using csv logging would
>> > want it anyway. +1 on just tacking on t
On Thu, 2011-06-30 at 09:58 -0700, David E. Wheeler wrote:
> On Jun 30, 2011, at 9:29 AM, Jeff Davis wrote:
>
> > Right. In that respect, it's more like a record type: many possible
> > record types exist, but you only define the ones you want.
>
> Well, okay. How is this same problem handled for
> On this commitfest, the goal of the patch is to be able to be
> recovered using "Minimum recovery ending location" in the control file.
Done.
Regards.
Jun Ishizuka
NTT Software Corporation
TEL：045-317-7018
E-Mail: ishizuka@po.ntts.co.jp
--
Fujii Masao writes:
> On Fri, Jul 1, 2011 at 2:25 AM, Robert Haas wrote:
>>> Some actions aren't even transactional, such as DROP DATABASE, amongst
>>
>> Good point. We'd probably need to add a timestamp to the drop
>> database record, as that's a case that people would likely want to
>> defend
Excerpts from Stephen Frost's message of jue jun 30 18:35:40 -0400 2011:
> > I know of no such list, and I think this field
> > useful/important enough that people who are using csv logging would
> > want it anyway. +1 on just tacking on the field and causing a flag day
> > for csv users.
>
> Hon
On Fri, Jul 1, 2011 at 3:25 AM, Robert Haas wrote:
> On Thu, Jun 30, 2011 at 1:51 PM, Kevin Grittner
> wrote:
>> I think doing anything in PostgreSQL around this beyond allowing
>> DBAs to trust their server clocks is insane. The arguments for
>> using and trusting ntpd is pretty much identical
On Fri, Jul 1, 2011 at 2:25 AM, Robert Haas wrote:
>> Some actions aren't even transactional, such as DROP DATABASE, amongst
>
> Good point. We'd probably need to add a timestamp to the drop
> database record, as that's a case that people would likely want to
> defend against with this feature.
On Thu, Jun 30, 2011 at 6:28 PM, Thom Brown wrote:
> On 27 June 2011 15:13, Robert Haas wrote:
>> I didn't get a lot of comments on my the previous version of my patch
>> to accelerate table locks.
>>
>> http://archives.postgresql.org/pgsql-hackers/2011-06/msg00953.php
>>
>> Here's a new version
On 06/30/2011 07:13 PM, Casey Havenor wrote:
When I run the patch I'm getting some Hunk fails? Is this because I'm not
using the same version that the author intended the patch for?
Yes. Welcome to the world of patch bitrot.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-h
Ok - loaded up Linux - fun stuff.
Figured out how to get the code PostgreSQL version 9.0.4 - Have that in a
directory.
Got the patch from above...
Placed into same directory.
Loaded the dependents for the final compile and install with .configure.
BUT
When I run the patch I'm getting some
* Alex Hunsaker (bada...@gmail.com) wrote:
> I think if Stephen was proposing 10 fields, or if there was a list of
> fields we were planning on adding in the next release or 3, it might
> be worth re-factoring.
I know of at least one person (in an earlier piece of the thread
discussing this patch
On 27 June 2011 15:13, Robert Haas wrote:
> I didn't get a lot of comments on my the previous version of my patch
> to accelerate table locks.
>
> http://archives.postgresql.org/pgsql-hackers/2011-06/msg00953.php
>
> Here's a new version anyway. In this version, I have:
>
> 1. Made pg_locks show
On Thu, 2011-06-30 at 07:50 -0400, Robert Haas wrote:
> I compare the performance of commit
> 431ab0e82819b31fcd1e33ecb52c2cd3b4b41da7 (post-patch) with commit
> 431ab0e82819b31fcd1e33ecb52c2cd3b4b41da7 (pre-patch).
I believe that is a copy/paste error.
Regards,
Jeff Davis
--
Sent via
On Thu, Jun 30, 2011 at 11:44 AM, Robert Haas wrote:
> On Thu, Jun 30, 2011 at 11:18 AM, Merlin Moncure wrote:
>>> I think the basic problem is that the cache pages are so large. It's
>>> hard to make them smaller because that increases the cost of accessing
>>> the cache, as you already noted,
On Thu, 2011-06-30 at 15:09 -0400, Alvaro Herrera wrote:
> I don't think we have a policy for this, but I have done it for some
> time now and nobody has complained, so I sort of assumed it was okay.
> Besides, some of the people pouring the money in does care about it;
> moreover, it provides a
On Jun 30, 2011, at 12:09 PM, Alvaro Herrera wrote:
> Robert Hass (whose name I misspelled in the commit message above) just
> mentioned to me (in an answer to my apologizing about it) that he didn't
> think that mentioning sponsors for patch development was a good idea.
>
> I don't think we have
Excerpts from Alvaro Herrera's message of jue jun 30 11:58:09 -0400 2011:
> Enable CHECK constraints to be declared NOT VALID
>
> [...]
>
> This patch was sponsored by Enova Financial.
Robert Hass (whose name I misspelled in the commit message above) just
mentioned to me (in an answer to my apol
On Thu, Jun 30, 2011 at 1:51 PM, Kevin Grittner
wrote:
> I think doing anything in PostgreSQL around this beyond allowing
> DBAs to trust their server clocks is insane. The arguments for
> using and trusting ntpd is pretty much identical to the arguments
> for using and trusting the OS file syste
Kevin,
> I think doing anything in PostgreSQL around this beyond allowing
> DBAs to trust their server clocks is insane. The arguments for
> using and trusting ntpd is pretty much identical to the arguments
> for using and trusting the OS file systems.
Oh, you don't want to implement our own NTP
Josh Berkus wrote:
> when we last had the argument about time synchronization,
> Kevin Grittner (I believe) pointed out that unsynchronized
> replication servers have an assortment of other issues ... like
> any read query involving now().
I don't remember making that point, although I think i
On 6/30/11 10:25 AM, Robert Haas wrote:
> So I think keeping it defined it terms of time is the
> right way forward, even though the need for external time
> synchronization is, certainly, not ideal.
Actually, when we last had the argument about time synchronization,
Kevin Grittner (I believe) poi
On Thu, Jun 30, 2011 at 6:45 AM, Simon Riggs wrote:
> The only way to control this is with a time delay that can be changed
> while the server is running. A recovery.conf parameter doesn't allow
> that, so another way is preferable.
True. We've talked about making the recovery.conf parameters in
On Thu, Jun 30, 2011 at 1:00 PM, Josh Berkus wrote:
> On 6/30/11 2:00 AM, Simon Riggs wrote:
Manual (or scripted) intervention is always necessary if you reach disk
>> 100% full.
>>> >
>>> > Wow, that's a pretty crappy failure mode... but I don't think we need
>>> > to fix it just on acc
On Thu, Jun 30, 2011 at 11:55 AM, Noah Misch wrote:
> On Wed, Jun 29, 2011 at 09:42:06AM -0400, Robert Haas wrote:
>> On Tue, Jun 28, 2011 at 3:40 PM, Noah Misch wrote:
>
>> > Here's the call stack in question:
>> >
>> > ? ? ? ?RelationBuildLocalRelation
>> > ? ? ? ?heap_create
>> > ? ? ? ?index_
On 6/30/11 2:00 AM, Simon Riggs wrote:
>>> Manual (or scripted) intervention is always necessary if you reach disk
>>> >> 100% full.
>> >
>> > Wow, that's a pretty crappy failure mode... but I don't think we need
>> > to fix it just on account of this patch. It would be nice to fix, of
>> > course
On Jun 30, 2011, at 9:34 AM, Jeff Davis wrote:
> Then how do you get a text range that doesn't correspond to the
> LC_COLLATE setting?
You cast it.
> Does that mean you couldn't dump/reload from a
> system with one collation and get the same values in a system with a
> different collation? That
On Jun 30, 2011, at 9:29 AM, Jeff Davis wrote:
> Right. In that respect, it's more like a record type: many possible
> record types exist, but you only define the ones you want.
Well, okay. How is this same problem handled for RECORD types, then?
>> By default, no range types would exists I beli
On Thu, Jun 30, 2011 at 11:18 AM, Merlin Moncure wrote:
>> I think the basic problem is that the cache pages are so large. It's
>> hard to make them smaller because that increases the cost of accessing
>> the cache, as you already noted, but at the same time, making an
>> eviction decision on a c
On Wed, 2011-06-29 at 12:34 -0400, Robert Haas wrote:
> But now that I'm thinking about this a little more, I'm worried about this
> case:
>
> CREATE TABLE foo AS RANGE('something'::funkytype, 'somethingelse'::funktype);
> DROP TYPE funkytype;
>
> It seems to me that the first statement had bett
On Wed, 2011-06-29 at 10:15 -0700, David E. Wheeler wrote:
> On Jun 29, 2011, at 10:13 AM, Florian Pflug wrote:
>
> > Because there might be more than one range type for a
> > base type. Say there are two range types over text, one
> > with collation 'de_DE' and one with collation 'en_US'.
> > Wha
On Thu, 2011-06-30 at 09:11 +0200, Florian Pflug wrote:
> > How would the system catalogs be initialized under that theory: surely
> > you're not going to seed (nr. of types) * (nr. of collations) * (nr. of
> > opclasses) range types in initdb?
>
> There's CREATE RANGE.
Right. In that respect, it
Excerpts from Robert Haas's message of sáb jun 18 23:53:17 -0400 2011:
> I agree. That's pretty contorted. How about something like this:
>
Thanks Jaime and Robert. I have pushed this patch with these fixes.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replica
On Wed, Jun 29, 2011 at 09:42:06AM -0400, Robert Haas wrote:
> On Tue, Jun 28, 2011 at 3:40 PM, Noah Misch wrote:
> > Here's the call stack in question:
> >
> > ? ? ? ?RelationBuildLocalRelation
> > ? ? ? ?heap_create
> > ? ? ? ?index_create
> > ? ? ? ?DefineIndex
> > ? ? ? ?ATExecAddIndex
> >
>
On Wed, Jun 29, 2011 at 3:18 PM, Robert Haas wrote:
>> With the algorithm as coded, to fully flush the cache you'd have to
>> find a series of *unhinted* tuples distributed across minimum of four
>> 64k wide page ranges, with the number of tuples being over the 5%
>> noise floor. Furthermore, to
Hi Jeff,
Thank you for review.
On Thu, Jun 30, 2011 at 8:50 AM, Jeff Janes wrote:
> So I tried provoking situations where this surrounding code section
>
would get executed, both patched and unpatched. I have been unable to
> do so--apparently this code is for an incredibly obscure situation
>
Excerpts from 花田 茂's message of jue jun 30 06:00:23 -0400 2011:
> I attached a patch which fixes file_fdw to check required option
> (filename) in its validator function. I think that such requirement
> should be checked again in PlanForeignScan(), as it had been so far.
> Note that this patch re
On 11-06-28 02:14 PM, Martin Pihlak wrote:
Hmm, I thought I thought about that. There was a check in the original
patch: "if (conn->sslRetryBytes || (conn->outCount - remaining)> 0)"
So if the SSL retry buffer was emptied it would return 1 if there was
something left in the regular output buffe
2011/6/27 _石头 :
> Hello!~
>
> Now i encounter a function call problem in PostgreSQL's psql module!
>
> The situation is as follow:
> In ./src/bin/psql/common.c, I want to call the
> function pqCatenateResultError().
> Function pqCatenateResultError() is declared in
> .
On Thu, Jun 30, 2011 at 5:47 AM, Peter Geoghegan wrote:
> I don't think that the way I've phrased my error messages is
> inconsistent with that style guide, excepty perhaps the pipe()
> reference, but if you feel it's important to try and use "could not",
> I have no objections.
I like Fujii's r
On Thu, Jun 30, 2011 at 1:49 AM, Hitoshi Harada wrote:
> 2011/6/30 Itagaki Takahiro :
>> On Thu, Jun 30, 2011 at 09:42, Tatsuo Ishii wrote:
>>> BTW I will talk to some Japanese speaking developers about my idea if
>>> community agree to add Japanese README to the source tree so that I am
>>> not
On Thu, Jun 30, 2011 at 12:31 AM, Jim Nasby wrote:
> Would it be reasonable to keep a second level cache that store individual
> XIDs instead of blocks? That would provide protection for XIDs that are
> extremely common but don't have a good fit with the pattern of XID ranges
> that we're cachi
On Tue, Jun 28, 2011 at 12:29 PM, Robert Haas wrote:
> On Tue, Jun 28, 2011 at 11:44 AM, Cédric Villemain
> wrote:
>> out of curiosity, does it affect the previous benchmarks of the feature ?
>
> I don't think there's much performance impact, because the only case
> where we actually have to do a
On 2011-06-30 09:39, Yeb Havinga wrote:
9) as remarked up a different thread, more than one clause could be
pushed down a subquery. The current patch only considers alternative
paths that have at most one clause pushed down. Is this because of the
call site of best_inner_subqueryscan, i.e. un
On Wed, Jun 29, 2011 at 7:11 PM, Robert Haas wrote:
> I don't really see how that's any different from what happens now. If
> (for whatever reason) the master is generating WAL faster than a
> streaming standby can replay it, then the excess WAL is going to pile
> up someplace, and you might run
On Wed, Jun 29, 2011 at 05:05:22PM +0100, Kohei KaiGai wrote:
> 2011/6/28 Noah Misch :
> > On Tue, Jun 28, 2011 at 10:11:59PM +0200, Kohei KaiGai wrote:
> > CREATE VIEW a AS SELECT * FROM ta WHERE ac = 5;
> > ALTER VIEW a OWNER TO alice;
> > CREATE VIEW b AS SELECT * FROM tb WHERE bc = 6;
> > ALTE
On Jun29, 2011, at 17:41 , Jeff Davis wrote:
>> Is it? That's actually too bad, since I kinda like it. But anyway,
>> if that's a concern it could also be
>> range_bounds(ARRAY[1,2]::int8range, '(]')
>
> What type would the result of that be? What value?
ARRAY[1,2]::int8range would return an int
On Jun30, 2011, at 10:33 , Radosław Smogura wrote:
> You may manually enter invalid xml too, You don't need xpath for this.
Please give an example, instead of merely asserting
I get
postgres=# select '<'::xml;
ERROR: invalid XML content at character 8
> Much more
> In PostgreSQL 9.0.1, compiled
(2011/06/29 21:23), Albe Laurenz wrote:
> If you invoke any of the SQL/MED CREATE or ALTER commands,
> the validator function is only called if an option list was given.
>
> That means that you cannot enforce required options at object creation
> time, because the validator function is not always
On 30 June 2011 08:58, Heikki Linnakangas
wrote:
> Here's a WIP patch with some mostly cosmetic changes I've done this far. I
> haven't tested the Windows code at all yet. It seems that no-one is
> objecting to removing silent_mode altogether, so I'm going to do that before
> committing this patc
On Thu, Jun 30, 2011 at 2:56 AM, Robert Haas wrote:
> On Wed, Jun 29, 2011 at 9:54 PM, Josh Berkus wrote:
>>> I am not sure exactly how walreceiver handles it if the disk is full.
>>> I assume it craps out and eventually retries, so probably what will
>>> happen is that, after the standby's pg_xl
2011/6/30 Yeb Havinga :
> On 2011-06-29 19:22, Hitoshi Harada wrote:
>>
>> Other things are all good points. Thanks for elaborate review!
>> More than anything, I'm going to fix the 6) issue, at least to find the
>> cause.
>>
> Some more questions:
> 8) why are cheapest start path and cheapest tota
On Wed, 29 Jun 2011 22:26:39 +0200, Florian Pflug wrote:
On Jun29, 2011, at 19:57 , Radosław Smogura wrote:
This is review of patch
https://commitfest.postgresql.org/action/patch_view?id=565
"Bugfix for XPATH() if expression returns a scalar value"
SELECT XMLELEMENT(name root, XMLATTRIBUTES(foo
On 30.06.2011 09:36, Fujii Masao wrote:
On Sat, Jun 25, 2011 at 10:41 AM, Peter Geoghegan wrote:
Attached is patch that addresses Fujii's third and most recent set of concerns.
Thanks for updating the patch!
I think that Heikki is currently taking another look at my work,
because he indicat
On 2011-06-29 19:22, Hitoshi Harada wrote:
Other things are all good points. Thanks for elaborate review!
More than anything, I'm going to fix the 6) issue, at least to find the cause.
Some more questions:
8) why are cheapest start path and cheapest total path in
best_inner_subqueryscan the sa
I wrote:
> If you invoke any of the SQL/MED CREATE or ALTER commands,
> the validator function is only called if an option list was given.
[...]
> Example:
[...]
The example is misleading. Here a better one:
CREATE SERVER myoradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (foo
'bar');
ERROR: inva
On Jun30, 2011, at 09:05 , Peter Eisentraut wrote:
> On tor, 2011-06-30 at 08:45 +0200, Florian Pflug wrote:
>> I don't think it will - as it stands, there isn't a single collatable
>> type RANGE but instead one *distinct* type per combination of base
>> type, btree opclass and collation. The reaso
On tor, 2011-06-30 at 08:45 +0200, Florian Pflug wrote:
> I don't think it will - as it stands, there isn't a single collatable
> type RANGE but instead one *distinct* type per combination of base
> type, btree opclass and collation. The reasons for that were discussed
> at length - the basic argum
On tor, 2011-06-30 at 09:42 +0900, Tatsuo Ishii wrote:
> Why don't you worry about message translations then? Translation is a
> human process and there's no way to guaranteer the translation is
> perfect.
At least for message translations we have a process and sophisticated
tools that ensure that
61 matches
Mail list logo
