On Wed, May 25, 2011 at 12:28 AM, Fujii Masao wrote:
> On Wed, May 25, 2011 at 2:16 PM, Heikki Linnakangas
>>>
>>> To achieve that, I'm thinking to change walsender so that, when the
>>> standby
>>> has caught up with the master, it sends back the message indicating that
>>> to
>>> the standby. An
On Wed, May 25, 2011 at 2:16 PM, Heikki Linnakangas
wrote:
> On 25.05.2011 07:42, Fujii Masao wrote:
>>
>> For reliable high-availability, when the master crashes, the clusterware
>> must
>> know whether it can promote the standby safely without any data loss,
>> before actually promoting it. IOW,
On 25.05.2011 07:42, Fujii Masao wrote:
For reliable high-availability, when the master crashes, the clusterware must
know whether it can promote the standby safely without any data loss,
before actually promoting it. IOW, it must know whether the standby has
already caught up with the primary. O
Hi,
For reliable high-availability, when the master crashes, the clusterware must
know whether it can promote the standby safely without any data loss,
before actually promoting it. IOW, it must know whether the standby has
already caught up with the primary. Otherwise, failover might cause data l
Robert Haas wrote:
> 2. The other fairly obvious alternative is to adjust our existing WAL
> record types to be idempotent - i.e. to not rely on the existing page
> contents. For XLOG_HEAP_INSERT, we currently store the target tid and
> the tuple contents. I'm not sure if there's anything else, b
Excerpts from Stephen Frost's message of mar may 24 22:56:21 -0400 2011:
> A couple of notes regarding the patch:
>
> First, it uses ffs(), which might not be fully portable.. We could
> certainly implement the same thing in userspace and use ffs() when
> it's available.
Err, see RIGHTM
On Tue, May 24, 2011 at 4:44 PM, Tom Lane wrote:
> There's a complaint here
> http://archives.postgresql.org/pgsql-general/2011-05/msg00714.php
> about the fact that 9.1 pg_dump always dumps CREATE EXTENSION commands
> for all loaded extensions. Should we change that? A reasonable
> compromise m
* Stephen Frost (sfr...@snowman.net) wrote:
> Finally, sorry it's kind of a fugly patch, it's just a proof of
> concept and I'd be happy to clean it up if others feel it's worthwhile
> and a reasonable approach, but I really need to get it out there and
> take a break from it (I've been a b
Greetings,
Someone (*cough*Haas*cough) made a claim over beers at PGCon that it
would be very difficult to come up with a way to pre-allocate List
entries and maintain the current List API. I'll admit that it wasn't
quite as trivial as I had *hoped*, but attached is a proof-of-concept
p
On Tue, 2011-05-24 at 16:34 -0400, Robert Haas wrote:
> As I think about it a bit more, we'd
> need to XLOG not only the parts of the page we actually modifying, but
> any that the WAL record would need to be correct on replay.
I don't understand that statement. Can you clarify?
Regards,
On Tue, May 24, 2011 at 8:52 PM, Fujii Masao wrote:
> + primary_xlp_magic = atoi(PQgetvalue(res, 0, 2));
>
> You wrongly get the third field (i.e., current xlog location) as the
> WAL version.
> You should call PQgetvalue(res, 0, 3), instead.
>
>> errdetail("Expected 1 tuple with 3 fields,
On 05/24/2011 01:35 PM, Josh Berkus wrote:
I would suggest instead adding a new page to postgresql.org/developer
which lists the development schedule, rather than linking to that wiki
page. Maybe on this page?
http://www.postgresql.org/developer/roadmap
Now that I look at the roadmap page
On Wed, May 25, 2011 at 8:26 AM, Jaime Casanova wrote:
> On Fri, May 20, 2011 at 12:50 PM, Magnus Hagander wrote:
>>
>> Yes. It might be useful to note it, and then ust make an override
>> flag. My pointm, though, was that doing it for walreceiver is more
>> important and a more logical first ste
On 05/24/2011 05:03 PM, Peter Eisentraut wrote:
On mån, 2011-05-23 at 22:44 -0400, Greg Smith wrote:
-Given that work in August is particularly difficult to line up with
common summer schedules around the world, having the other>1 month
gap in the schedule go there makes sense.
You mi
On Tue, May 24, 2011 at 04:18:37AM -0500, Kevin Grittner wrote:
> These proofs show that
> there is no legitimate cycle which could cause an anomaly which the
> move from row-based to tuple-based logic will miss. They don't prove
> that the change will generate all the same serialization failures;
On Fri, May 20, 2011 at 12:50 PM, Magnus Hagander wrote:
>
> Yes. It might be useful to note it, and then ust make an override
> flag. My pointm, though, was that doing it for walreceiver is more
> important and a more logical first step.
>
ok, patch attached.
--
Jaime Casanova www.2ndQ
Andrew,
From: "Andrew Dunstan"
builddoc.bat failed on my system and reading it made my head hurt. So I
did what I've done with other bat files and rewrote it in Perl. The
result is attached. It works for me, and should be a dropin replacement.
Just put it in the src/tools/msvc directory and run
On Tue, May 24, 2011 at 5:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, May 21, 2011 at 5:47 PM, Peter Eisentraut wrote:
>>> I noticed the 9.1 release notes claim that the new
>>> EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is
>>> actually a psql variable.
>>>
Robert Haas writes:
> On Sat, May 21, 2011 at 5:47 PM, Peter Eisentraut wrote:
>> I noticed the 9.1 release notes claim that the new
>> EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is
>> actually a psql variable.
>> This is perhaps sort of a Freudian slip.
> It's probabl
Peter Eisentraut writes:
> On lör, 2011-05-21 at 15:46 +0200, Fabien COELHO wrote:
>> From a language definition perspective, it is helpful to have a name for
>> every case instead of an implicit fallback, without any word to describe
>> it. See for instance "CREATE USER CREATEDB/NOCREATEDB" or
Robert Haas writes:
> On Tue, May 24, 2011 at 4:36 PM, Peter Eisentraut wrote:
>>> That's an intriguing possibility. But part of the point of the
>>> original feature was to be able to say:
>>>
>>> \ef somefunc 10
>>>
>>> ...and end up on line 10 of somefunc, perhaps in response to an error
>>
On mån, 2011-05-23 at 22:44 -0400, Greg Smith wrote:
> -Given that work in August is particularly difficult to line up with
> common summer schedules around the world, having the other >1 month
> gap in the schedule go there makes sense.
You might want to add a comment on the schedule page about
Robert Haas wrote:
> On Sun, May 22, 2011 at 1:38 PM, Joshua Berkus wrote:
> >> Another point is that parsing overhead is quite obviously not the
> >> reason for the massive performance gap between one core running simple
> >> selects on PostgreSQL and one core running simple selects on MySQL.
> >
There's a complaint here
http://archives.postgresql.org/pgsql-general/2011-05/msg00714.php
about the fact that 9.1 pg_dump always dumps CREATE EXTENSION commands
for all loaded extensions. Should we change that? A reasonable
compromise might be to suppress extensions in the same cases where we
su
Attached is the latest revision of the latch implementation that
monitors postmaster death, plus the archiver client that now relies on
that new functionality and thereby works well without a tight
PostmasterIsAlive() polling loop.
On second thought, it is reasonable for the patch to be evaluated
On lör, 2011-05-21 at 15:46 +0200, Fabien COELHO wrote:
> Hello,
>
> Please find attached a minor stylish patch. It compiles and the update
> test cases work for me.
>
> Description:
>
> Add "AS EXPLICIT" to "CREATE CAST"
>
> This gives a name to the default case of "CREATE CAST", which create
On Tue, May 24, 2011 at 4:36 PM, Peter Eisentraut wrote:
>> That's an intriguing possibility. But part of the point of the
>> original feature was to be able to say:
>>
>> \ef somefunc 10
>>
>> ...and end up on line 10 of somefunc, perhaps in response to an error
>> message complaining about that
On sön, 2011-05-22 at 06:30 +0200, Pavel Stehule wrote:
> A idea with other options are
> interesting. More usable can be store these option inside psql
> variable (be consistent with current state). Maybe in
> EDITOR_OPTIONS ?
There isn't really a need for that, since if you want to pass options
On lör, 2011-05-21 at 20:39 -0400, Robert Haas wrote:
> On Sat, May 21, 2011 at 5:47 PM, Peter Eisentraut wrote:
> > I noticed the 9.1 release notes claim that the new
> > EDITOR_LINENUMBER_SWITCH thing is an environment variable, whereas it is
> > actually a psql variable.
> It's probably the re
While eating good Indian food and talking about aviation accidents on
the last night of PGCon, Greg Stark, Heikki Linnakangas, and I found
some time to brainstorm about possible ways to reduce the impact of
full_page_writes. I'm not sure that these ideas are much good, but
for the sake of posterit
In the TODO list is this item:
*Modify the planner to better estimate caching effects
*
Tom mentioned this in his presentation at PGCON, and I also chatted with Tom
about it briefly afterwards.
Based on last year's discussion of this TODO item, it seems thoughts have
been focused on estimating ho
Tom Lane wrote:
> Robert Haas writes:
> > On Tue, May 24, 2011 at 2:48 PM, Bruce Momjian wrote:
> >> Yes, the problem is the sample will change, but the $PGDATA will not, so
> >> anyone doing a diff of the two files to see the localized changes will
> >> see the changes that came in as part of th
Robert Haas wrote:
> On Mon, May 23, 2011 at 2:57 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Mon, May 23, 2011 at 8:26 AM, Bruce Momjian wrote:
> >> > Sorry, I was unclear. ?The question is whether the case of _name_ of the
> >> > locale is significant, meaning can you have two local
Robert Haas writes:
> 2011/5/24 Kohei Kaigai :
>> The attached patch enables to abort configure script when we run it with
>> '--with-selinux'
>> option, but libselinux is older than minimum requirement to SE-PostgreSQL.
> Looks to me like you need to adjust the wording of the error message.
> M
Peter Eisentraut writes:
> Quick patch for verification. I chose the naming -z/--gzip to mirror
> GNU tar.
I would argue that -Z ought to turn on "gzip" without my having to write
-z as well (at least when the argument is greater than zero; possibly
-Z0 should be allowed as meaning "no compressi
Robert Haas writes:
> On Tue, May 24, 2011 at 2:48 PM, Bruce Momjian wrote:
>> Yes, the problem is the sample will change, but the $PGDATA will not, so
>> anyone doing a diff of the two files to see the localized changes will
>> see the changes that came in as part of that commit.
> I don't thin
On Tue, May 24, 2011 at 2:48 PM, Bruce Momjian wrote:
> Yes, the problem is the sample will change, but the $PGDATA will not, so
> anyone doing a diff of the two files to see the localized changes will
> see the changes that came in as part of that commit.
I don't think that's a serious problem.
"David E. Wheeler" writes:
> On May 24, 2011, at 11:30 AM, Tom Lane wrote:
>> I guess that the question that's immediately at hand is sort of a
>> variant of that, because using a polymorphic function declared to take
>> ANYARRAY on a domain-over-array really is using a portion of the base
>> type
Magnus Hagander wrote:
> >> > As I mentioned offlist, I'd like it in teal please.
> >>
> >> Applied with some further minor bikeshedding (remove trailing spaces,
> >> rewrap so columns aren't wider than 80 chars, etc)
> >
> > Let me just point out that people who have already run initdb during
> >
On sön, 2011-05-22 at 16:43 -0400, Magnus Hagander wrote:
> On Fri, May 20, 2011 at 17:45, Peter Eisentraut wrote:
> > On fre, 2011-05-20 at 14:19 -0400, Magnus Hagander wrote:
> >> > I suggest we add an argument-less option -z that means "compress",
> >> and
> >> > then -Z can be relegated to cho
Robert Haas writes:
> Excellent. Are you going to look at MauMau's patch for bug #6011 also?
No. I don't do Windows, so I can't test it.
(On general principles, I don't think that hacking write_eventlog the
way he did is appropriate; such a function should write the log, not
editorialize. But
Noah Misch writes:
> Adding a memory definedness check to printtup() turned up one more culprit:
> tsquery_and.
Patch applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On May 24, 2011, at 11:30 AM, Tom Lane wrote:
> Well, if they actually were first-class types, they probably wouldn't
> be born with an implicit cast to some other type to handle 99% of
> operations on them ;-). I think the hard part here is having that cake
> and eating it too, ie, supporting do
"David E. Wheeler" writes:
> On May 24, 2011, at 10:11 AM, Tom Lane wrote:
>> On the other hand it feels like we'd be taking yet another step away
>> from allowing domains to be usefully used in function declarations.
> I agree. It sure seems to me like DOMAINs should act exactly like any
> other
On Tue, May 24, 2011 at 2:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, May 24, 2011 at 2:11 PM, Noah Misch wrote:
>>> QTN2QT() allocates memory for a TSQuery using palloc(). TSQuery contains an
>>> array of QueryItem, which contains three bytes of padding between its first
>>> and
>
Robert Haas writes:
> On Tue, May 24, 2011 at 2:11 PM, Noah Misch wrote:
>> QTN2QT() allocates memory for a TSQuery using palloc(). TSQuery contains an
>> array of QueryItem, which contains three bytes of padding between its first
>> and
>> second members. Those bytes don't get initialized, so
On May 24, 2011, at 10:11 AM, Tom Lane wrote:
> regression=# select negate(42::pos);
> ERROR: return type mismatch in function declared to return pos
> DETAIL: Actual return type is integer.
> CONTEXT: SQL function "negate" during inlining
>
> If we smashed to base type then this issue would g
On Tue, May 24, 2011 at 2:11 PM, Noah Misch wrote:
>> OK, I can't see what's broken. Help?
>
> QTN2QT() allocates memory for a TSQuery using palloc(). TSQuery contains an
> array of QueryItem, which contains three bytes of padding between its first
> and
> second members. Those bytes don't get
Heikki Linnakangas writes:
> So the default is indeed non-standard. But I wonder if we should use -Aa
> instead?
Probably not; at least on older HPUX versions, -Aa turns off access to
assorted stuff that we do want, eg "long long". "man cc" on my box
saith
-Amode Specify the compi
2011/5/24 Kohei Kaigai :
> The attached patch enables to abort configure script when we run it with
> '--with-selinux'
> option, but libselinux is older than minimum requirement to SE-PostgreSQL.
>
> As the documentation said, it needs libselinux-2.0.93 at least, because this
> or later
> version
On Tue, May 24, 2011 at 02:05:33PM -0400, Robert Haas wrote:
> On Mon, May 23, 2011 at 1:12 AM, Noah Misch wrote:
> > On Tue, Apr 26, 2011 at 11:51:35PM -0400, Noah Misch wrote:
> >> On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote:
> >> [input functions aren't the only problematic source
On Mon, May 23, 2011 at 1:12 AM, Noah Misch wrote:
> On Tue, Apr 26, 2011 at 11:51:35PM -0400, Noah Misch wrote:
>> On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote:
>> [input functions aren't the only problematic source of uninitialized datum
>> bytes]
>>
>> > We've run into other manife
On 24.05.2011 20:56, Andrew Dunstan wrote:
I have been whining for years about the lack of HP-UX support (both for
gcc and their compiler) on the buildfarm. I really really wish HP would
come to the party and supply some equipment and software. Failing that,
some spare cycles being made available
On Tue, May 24, 2011 at 01:28:38PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Tue, May 24, 2011 at 12:12:55PM -0400, Tom Lane wrote:
> >> This is a consequence of the changes I made to fix bug #5717,
> >> particularly the issues around ANYARRAY matching discussed here:
> >> http://archives
On 24.05.2011 20:44, Tom Lane wrote:
BTW, is it really true that HP decided they could make the compiler's
default behavior violate the C standard so flagrantly? I could believe
offering a switch that you had to specify to save a few cycles at the
cost of nonstandard behavior; but if your report
On 05/24/2011 01:44 PM, Tom Lane wrote:
Ibrar Ahmed writes:
I have found a problem which is specifically related to "HP-UX" compiler.
All 'libm' functions on "HP-UX Integrity server" do not set "errno" by
default. For 'errno' setting we should compile the code using +Olibmerrno
option. So we
On Tue, May 24, 2011 at 12:34 PM, Tom Lane wrote:
>> Oh, I see. I have a general gripe with nested loop plans: we already
>> consider too many of them. IIRC, when I last fooled around with this,
>> the number of nested loop paths that we generate far exceeded the
>> number of merge or hash join
> Actually, you're responding to Greg, not me.
Sorry.
> But +1 for your suggestions.
Any objections before I post something? Greg?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
Ibrar Ahmed writes:
> I have found a problem which is specifically related to "HP-UX" compiler.
> All 'libm' functions on "HP-UX Integrity server" do not set "errno" by
> default. For 'errno' setting we should compile the code using +Olibmerrno
> option. So we should add this option in "/src/make
On Tue, May 24, 2011 at 1:35 PM, Josh Berkus wrote:
> Robert,
Actually, you're responding to Greg, not me.
But +1 for your suggestions.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Tue, May 24, 2011 at 12:34 PM, Noah Misch wrote:
> There's a potentially-unbounded delay between when the subject backend reads
> strong_lock_counts[] and when it sets its fast-path-used flag. (I didn't mean
> "not yet seen" in the sense that some memory load would not show the latest
> value.
Robert,
> -Publish information about the full schedule to some of the more popular
> mailing lists
I think that posting to pgsql-announce and PostgreSQL.org news, and this
list would be sufficient. I'm happy to take care of that.
> -Link to this page more obviously from postgresql.org (fixed re
2011/5/25 Tom Lane :
> Robert Haas writes:
>> That was my first thought, too, but then I wondered if I was getting
>> cheap.
>
> Yeah, it's certainly possible that we're worrying too much. Usually
> I only get concerned about added planner logic if it will impact the
> planning time for simple qu
The attached patch enables to abort configure script when we run it with
'--with-selinux'
option, but libselinux is older than minimum requirement to SE-PostgreSQL.
As the documentation said, it needs libselinux-2.0.93 at least, because this or
later
version support selabel_lookup(3) for databas
So, first of all, thanks for putting some effort and thought into
this. Despite the large number of improvements in this area in 8.3
and 8.4, this is still a pain point, and it would be really nice to
find a way to make some further improvements.
On Tue, May 24, 2011 at 2:58 AM, Pavan Deolasee
w
Noah Misch writes:
> On Tue, May 24, 2011 at 12:12:55PM -0400, Tom Lane wrote:
>> This is a consequence of the changes I made to fix bug #5717,
>> particularly the issues around ANYARRAY matching discussed here:
>> http://archives.postgresql.org/pgsql-hackers/2010-10/msg01545.php
> We discussed t
I have found a problem which is specifically related to "HP-UX" compiler.
All 'libm' functions on "HP-UX Integrity server" do not set "errno" by
default. For 'errno' setting we should compile the code using +Olibmerrno
option. So we should add this option in "/src/makefiles/Makefile.hpux".
Otherwi
Merlin Moncure writes:
> On Tue, May 24, 2011 at 11:12 AM, Tom Lane wrote:
>> 1. If a domain type is passed to an ANYARRAY argument, automatically
>> downcast it to its base type (which of course had better then be an
>> array).
> Does that mean that plpgsql %type variable declarations will see
"David E. Wheeler" writes:
> On May 24, 2011, at 9:12 AM, Tom Lane wrote:
>> An alternative rule we could use in place of #2 is just "smash domains
>> to base types always, when they're matched to ANYELEMENT". That would
>> be simpler and more in keeping with #1, but it might change the behavior
On Tue, May 24, 2011 at 12:12:55PM -0400, Tom Lane wrote:
> In http://archives.postgresql.org/pgsql-bugs/2011-05/msg00171.php
> Regina Obe complains that this fails in 9.1, though it worked before:
>
> regression=# CREATE DOMAIN topoelementarray AS integer[];
> CREATE DOMAIN
> regression=# SELECT
Hi,
I'd like to propose cascade replication feature (i.e., allow the
standby to accept
replication connection from another standby) for 9.2. This feature is useful to
reduce the overhead of the master since by using that we can decrease the
number of standbys directly connecting to the master.
I
David Fetter wrote:
I thought we'd agreed on the timing for the first CF, and that I was
to announce it in the PostgreSQL Weekly News, so I did just that.
Yes, and excellent. The other ideas were:
-Publish information about the full schedule to some of the more popular
mailing lists
-Li
On May 24, 2011, at 9:12 AM, Tom Lane wrote:
> An alternative rule we could use in place of #2 is just "smash domains
> to base types always, when they're matched to ANYELEMENT". That would
> be simpler and more in keeping with #1, but it might change the behavior
> in cases where the historical
On Tue, May 24, 2011 at 11:12 AM, Tom Lane wrote:
> 1. If a domain type is passed to an ANYARRAY argument, automatically
> downcast it to its base type (which of course had better then be an
> array). This would include inserting an implicit cast into the
> expression tree, so that if the functio
On Tue, May 24, 2011 at 11:52:54AM -0400, Robert Haas wrote:
> On Tue, May 24, 2011 at 11:38 AM, Noah Misch wrote:
> >> Another random idea for optimization: we could have a lock-free array
> >> with one entry per backend, indicating whether any fast-path locks are
> >> present. ?Before acquiring
Robert Haas writes:
> On Tue, May 24, 2011 at 11:11 AM, Tom Lane wrote:
>> The point I was trying to make is that the ultimate reason for having a
>> parameterized portion-of-a-plan will be that there's a parameterized
>> indexscan somewhere down at the bottom.
> Oh, I see. I have a general gri
On Tue, May 24, 2011 at 11:54:19AM -0400, Robert Haas wrote:
> On Tue, May 24, 2011 at 11:33 AM, David Fetter wrote:
> > On Mon, May 23, 2011 at 10:44:20PM -0400, Greg Smith wrote:
> >> At the developer meeting last week:
> >> http://wiki.postgresql.org/wiki/PgCon_2011_Developer_Meeting there
> >>
In http://archives.postgresql.org/pgsql-bugs/2011-05/msg00171.php
Regina Obe complains that this fails in 9.1, though it worked before:
regression=# CREATE DOMAIN topoelementarray AS integer[];
CREATE DOMAIN
regression=# SELECT array_upper(ARRAY[[1,2], [3,4]]::topoelementarray, 1);
ERROR: functi
On Tue, May 24, 2011 at 11:33 AM, David Fetter wrote:
> On Mon, May 23, 2011 at 10:44:20PM -0400, Greg Smith wrote:
>> At the developer meeting last week:
>> http://wiki.postgresql.org/wiki/PgCon_2011_Developer_Meeting there
>> was an initial schedule for 9.2 hammered out and dutifully
>> transcri
On Tue, May 24, 2011 at 11:38 AM, Noah Misch wrote:
>> Another random idea for optimization: we could have a lock-free array
>> with one entry per backend, indicating whether any fast-path locks are
>> present. Before acquiring its first fast-path lock, a backend writes
>> a 1 into that array and
On 05/19/2011 06:29 PM, MauMau wrote:
From: "Andrew Dunstan"
On Thu, May 19, 2011 10:32 am, Robert Haas wrote:
2011/5/16 MauMau :
Can't open perl script "make-errcodes-table.pl": No such file or
directory
I think this is the root of the problem. We have no script called
make-errcodes-tab
On Tue, May 24, 2011 at 11:11 AM, Tom Lane wrote:
>> I must be misunderstanding you, because index scans are the thing we
>> already *do* parameterize; and what else would make any sense?
>
> The point I was trying to make is that the ultimate reason for having a
> parameterized portion-of-a-plan
On Tue, May 24, 2011 at 10:35:23AM -0400, Robert Haas wrote:
> On Tue, May 24, 2011 at 10:03 AM, Noah Misch wrote:
> > Let's see if I understand the risk better now: the new system will handle
> > lock
> > load better, but when it does hit a limit, understanding why that happened
> > will be more
On Mon, May 23, 2011 at 10:44:20PM -0400, Greg Smith wrote:
> At the developer meeting last week:
> http://wiki.postgresql.org/wiki/PgCon_2011_Developer_Meeting there
> was an initial schedule for 9.2 hammered out and dutifully
> transcribed at
> http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Devel
Robert Haas writes:
> On Mon, May 23, 2011 at 4:02 PM, Tom Lane wrote:
>> Yeah. For simple scan/join queries it seems likely that we only care
>> about parameterizing indexscans, since the main opportunity for a win is
>> to not scan all of a large table. Restricting things that way would
>> he
On Tue, May 24, 2011 at 10:53, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Thu, May 19, 2011 at 11:09, Dave Page wrote:
>> > On Thu, May 19, 2011 at 2:44 PM, Selena Deckelmann
>> > wrote:
>> >> On Wed, May 18, 2011 at 8:20 PM, Alvaro Herrera
>> >> wrote:
>> >>> Excerpts from Greg Smith
Robert Haas wrote:
> On Thu, May 19, 2011 at 3:17 PM, Alvaro Herrera
> wrote:
> > Is there a reason we don't allow moving the toast table to a separate
> > tablespace, other than unimplemented feature? ?If not, I propose such a
> > syntax as
> >
> > ALTER TABLE foo SET TOAST TABLESPACE bar;
>
>
Magnus Hagander wrote:
> On Thu, May 19, 2011 at 11:09, Dave Page wrote:
> > On Thu, May 19, 2011 at 2:44 PM, Selena Deckelmann
> > wrote:
> >> On Wed, May 18, 2011 at 8:20 PM, Alvaro Herrera
> >> wrote:
> >>> Excerpts from Greg Smith's message of mi? may 18 23:07:13 -0400 2011:
> Two thin
On Tue, May 24, 2011 at 10:03 AM, Noah Misch wrote:
> Let's see if I understand the risk better now: the new system will handle lock
> load better, but when it does hit a limit, understanding why that happened
> will be more difficult. Good point. No silver-bullet ideas come to mind for
> avoidi
On Tue, May 24, 2011 at 10:10:34AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > PostgreSQL 9.1 will implement ALTER TABLE ALTER TYPE operations that use a
> > binary coercion cast without rewriting the table or unrelated indexes. It
> > will always rewrite any indexes and recheck any foreign k
Noah Misch writes:
> PostgreSQL 9.1 will implement ALTER TABLE ALTER TYPE operations that use a
> binary coercion cast without rewriting the table or unrelated indexes. It
> will always rewrite any indexes and recheck any foreign key constraints that
> depend on a changing column. This is unnece
On Tue, May 24, 2011 at 08:53:11AM -0400, Robert Haas wrote:
> On Tue, May 24, 2011 at 5:07 AM, Noah Misch wrote:
> > This drops the part about only transferring fast-path entries once when a
> > strong_lock_counts cell transitions from zero to one.
>
> Right: that's because I don't think that's
On Tue, May 24, 2011 at 5:07 AM, Noah Misch wrote:
> This drops the part about only transferring fast-path entries once when a
> strong_lock_counts cell transitions from zero to one.
Right: that's because I don't think that's what we want to do. I
don't think we want to transfer all per-backend
Robert Haas wrote:
> On Mon, May 23, 2011 at 8:26 AM, Bruce Momjian wrote:
> > Sorry, I was unclear. ?The question is whether the case of _name_ of the
> > locale is significant, meaning can you have two locale names that differ
> > only by case and behave differently?
>
> That would seem surpris
Robert Haas wrote:
> On Sun, May 22, 2011 at 11:49 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> I believe, however, that applying this will invalidate the contents of
> >> any hash indexes on array types that anyone has built using 9.1beta1.
> >> Do we need to do something about that?
> >
> >
During preparing patch of my GSoC project I found reasonable to
move childoffnum (GISTInsertStack structure) from parent to child. This
means that now child have childoffnum of parent's link to child. It allows
to maintain entire parts of tree in that GISTInsertStack structures. Also it
simplifies
On Tue, May 24, 2011 at 6:57 AM, Kohei KaiGai wrote:
> 2011/5/23 Robert Haas :
>> On Sun, May 22, 2011 at 5:52 AM, Kohei KaiGai wrote:
>>> The attached patch fixes up case handling in foreign tables.
>>>
>>> Now it didn't assign security label on foreign table on its creation
>>> time, and didn't
2011/5/23 Robert Haas :
> On Sun, May 22, 2011 at 5:52 AM, Kohei KaiGai wrote:
>> The attached patch fixes up case handling in foreign tables.
>>
>> Now it didn't assign security label on foreign table on its creation
>> time, and didn't check access rights on the dml hook.
>> This patch fixes the
PostgreSQL 9.1 will implement ALTER TABLE ALTER TYPE operations that use a
binary coercion cast without rewriting the table or unrelated indexes. It
will always rewrite any indexes and recheck any foreign key constraints that
depend on a changing column. This is unnecessary for 100% of core binar
"Kevin Grittner" wrote:
> Dan Ports wrote:
>> Does that make sense to you?
>
> Makes sense to me. Like the proof I offered, you have shown that
> there is no cycle which can develop with the locks copied which
> isn't there anyway if we don't copy the locks.
I woke up with the nagging though
1 - 100 of 101 matches
Mail list logo
