> I still think that's headed in the wrong direction.
> (http://archives.postgresql.org/pgsql-hackers/2011-05/msg01405.php)
Please check these mails, and teach the reason for content of the wrong
direction.
(http://archives.postgresql.org/pgsql-hackers/2011-06/msg00209.php)
(http://archives.post
On 14.06.2011 09:03, Jun Ishiduka wrote:
> ( Quotation from
>http://archives.postgresql.org/pgsql-hackers/2011-05/msg01396.php )
>
>> STEP1: Make startup process to acquire backup-end-position from
>> not only backup-end record but also backup-history-file .
>>* startup
( Quotation from
http://archives.postgresql.org/pgsql-hackers/2011-05/msg01396.php )
> STEP1: Make startup process to acquire backup-end-position from
> not only backup-end record but also backup-history-file .
> * startup process allows to acquire backup-end-position
>
hi people, postgresql goes down on a WindowsXP SP3 machine.
there a script to reproduce. (on XP with 8.4 works fine)
CREATE DATABASE teste
WITH OWNER = postgres
ENCODING = 'UTF8'
TABLESPACE = pg_default
LC_COLLATE = 'Portuguese_Brazil.1252'
LC_CTYPE = 'Portuguese_
Robert Haas writes:
> On Mon, Jun 13, 2011 at 7:47 PM, Bruce Momjian wrote:
>> No, it does not. Under what circumstances should I issue a suggestion
>> to reindex, and what should the text be?
> It sounds like GIN indexes need to be reindexed after upgrading from <
> 9.1 to >= 9.1.
Only if you
On Mon, Jun 13, 2011 at 04:41:11PM +0100, Simon Riggs wrote:
> On Thu, Jun 9, 2011 at 10:38 PM, Noah Misch wrote:
> > On Fri, Apr 22, 2011 at 11:10:34AM -0400, Noah Misch wrote:
> >> In an attempt to resuscitate this thread, here's my own shot at that.
> >> ?Apologies
> >> in advance if it's just
Bruce Momjian writes:
> Tom Lane wrote:
>> No, pg_upgrade should not be unilaterally refusing that.
> Uh, isn't there some physical files in pg_twophase/ that stick around to
> keep prepared transactions --- if so, pg_upgrade does not copy them from
> the old cluster to the new one. I am also he
On Mon, Jun 13, 2011 at 04:16:06PM +0100, Simon Riggs wrote:
> On Mon, Jun 13, 2011 at 3:11 AM, Robert Haas wrote:
> > On Sun, Jun 12, 2011 at 3:01 PM, Noah Misch wrote:
> >> Assuming that conclusion, I do think it's worth starting
> >> with something simple, even if it means additional bloat on
On Tue, Jun 14, 2011 at 13:09, Alvaro Herrera
wrote:
> I noticed that pgbench's doCustom (the function highest in the profile
> posted) returns doing nothing if the connection is supposed to be
> "sleeping"; seems an open door for busy waiting.
pgbench uses select() with/without timeout in the ca
Excerpts from Jeff Janes's message of lun jun 13 20:27:15 -0400 2011:
> On Mon, Jun 13, 2011 at 7:03 AM, Stefan Kaltenbrunner
> wrote:
> ...
> >
> >
> > so it seems that sysbench is actually significantly less overhead than
> > pgbench and the lower throughput at the higher conncurency seems to be
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of lun jun 13 18:38:46 -0400 2011:
> > Andrew Dunstan wrote:
>
> > > Is putting remotes in your ~/.gitconfig good practice? I certainly
> > > don't have any in mine.
> >
> > Putting 'github' in there allows me to push/pull from githu
Robert Haas wrote:
> On Mon, Jun 13, 2011 at 7:47 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Sun, Jun 12, 2011 at 8:40 AM, Florian Pflug wrote:
> >> > Note that this restriction was removed in postgres 9.1 which
> >> > is currently in beta. However, GIT indices must be re-created
> >
On 06/13/2011 07:55 AM, Stefan Kaltenbrunner wrote:
all those tests are done with pgbench running on the same box - which
has a noticable impact on the results because pgbench is using ~1 core
per 8 cores of the backend tested in cpu resoures - though I don't think
it causes any changes in the re
On Mon, Jun 13, 2011 at 9:41 PM, Alvaro Herrera
wrote:
> Excerpts from Josh Berkus's message of lun jun 13 18:11:54 -0400 2011:
>> Alvaro, Dean,
>>
>> >> I think that you also need to update the constraint exclusion code
>> >> > (get_relation_constraints() or nearby), otherwise the planner might
On Mon, Jun 13, 2011 at 7:47 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sun, Jun 12, 2011 at 8:40 AM, Florian Pflug wrote:
>> > Note that this restriction was removed in postgres 9.1 which
>> > is currently in beta. However, GIT indices must be re-created
>> > with REINDEX after upgradin
On Mon, Jun 13, 2011 at 8:19 PM, Andrew Dunstan wrote:
> I think we can be a bit more liberal about build patches than things that
> can affect the runtime behaviour.
I agree. I wouldn't go nuts with it, but I don't see any reason to
worry about fixing this case.
--
Robert Haas
EnterpriseDB: h
On 06/13/2011 08:27 PM, Jeff Janes wrote:
pgbench sends each query (per connection) and waits for the reply
before sending another.
Do we know whether sysbench does that, or if it just stuffs the
kernel's IPC buffer full of queries without synchronously waiting for
individual replies?
sysb
Excerpts from Bruce Momjian's message of lun jun 13 18:38:46 -0400 2011:
> Andrew Dunstan wrote:
> > Is putting remotes in your ~/.gitconfig good practice? I certainly
> > don't have any in mine.
>
> Putting 'github' in there allows me to push/pull from github branches
> without having to speci
(2011/06/13 21:30), Robert Haas wrote:
> Committed, with some additional word-smithing.
Thanks.
> Incidentally, are you planning to revive the PostgreSQL FDW for 9.2?
> That would be a killer feature.
Yes, I would like to work on pgsql_fdw and other SQL/MED issues in 9.2
development cycle. I'm
Apologies - I meant to CC in the list but forgot.
I have gone through and changed all the related functions except
``update_attstats''.
Do you have any advice of how to handle the inner loops, such as those
initializing ``stakindN''. The entries before can be handled just like in this
patch, b
I needed to talk to the database from an app that builds in Visual Studio 2010
only at the moment.
The binary that EnterpriseDB provides for windows was built with VS2005 I think
and causes the weird error linking of "cannot open Files.obj" (there is no
Files.cpp)
I was able to download the sou
On Tue, Jun 14, 2011 at 09:27, Jeff Janes wrote:
> pgbench sends each query (per connection) and waits for the reply
> before sending another.
We can use -j option to run pgbench in multiple threads to avoid
request starvation. What setting did you use, Stefan?
>> for those curious - the profile
Excerpts from Josh Berkus's message of lun jun 13 18:11:54 -0400 2011:
> Alvaro, Dean,
>
> >> I think that you also need to update the constraint exclusion code
> >> > (get_relation_constraints() or nearby), otherwise the planner might
> >> > exclude a relation on the basis of a CHECK constraint
Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 13.06.2011 21:31, Tom Lane wrote:
> >> So far as I can tell, that breaks pg_upgrade (if there are any open
> >> prepared transactions) for no redeeming social benefit.
>
> > Surely pg_upgrade can't work anyway if there's any open prepared
> > t
On Mon, Jun 13, 2011 at 7:03 AM, Stefan Kaltenbrunner
wrote:
...
>
>
> so it seems that sysbench is actually significantly less overhead than
> pgbench and the lower throughput at the higher conncurency seems to be
> cause by sysbench being able to stress the backend even more than
> pgbench can.
On 06/13/2011 08:05 PM, Tom Lane wrote:
I looked into $SUBJECT. There appear to be two distinct issues:
1. On colugos (OS X with LLVM), the plperl link step is spitting up
because Apple's ExtUtils::Embed puts some -arch switches into
perl_embed_ldflags. We found out about that some time ago,
On Sun, Jun 12, 2011 at 2:39 PM, Robert Haas wrote:
...
>
> Profiling reveals that the system spends enormous amounts of CPU time
> in s_lock. LWLOCK_STATS reveals that the only lwlock with significant
> amounts of blocking is the BufFreelistLock;
This is curious. Clearly the entire working set
I looked into $SUBJECT. There appear to be two distinct issues:
1. On colugos (OS X with LLVM), the plperl link step is spitting up
because Apple's ExtUtils::Embed puts some -arch switches into
perl_embed_ldflags. We found out about that some time ago, and fixed
it for 9.0 and up here:
http://gi
Robert Haas wrote:
> On Sun, Jun 12, 2011 at 8:40 AM, Florian Pflug wrote:
> > Note that this restriction was removed in postgres 9.1 which
> > is currently in beta. However, GIT indices must be re-created
> > with REINDEX after upgrading from 9.0 to leverage that
> > improvement.
>
> Does pg_upg
On 14/06/2011 01:11, Josh Berkus wrote:
Hmmm. Is this the behavior we want with NOT VALID constraints though?
I know that if I'm pouring 100m rows into a new partition as part of a
repartitioning scheme, I don't want to *ever* check them if I know
they're correct because of how I created the tab
> I can see why you would want that, but I'd say that's a separate feature
> you need to explicitly request when creating the constraint. Consider
> what happens in the "old data is garbage, but I want the new data to be
> validated" use case if we allow constraint exclusion on NOT VALID
> constr
On 06/13/2011 06:38 PM, Bruce Momjian wrote:
Andrew Dunstan wrote:
On 06/13/2011 02:26 PM, Bruce Momjian wrote:
I found the cause. When I added 'github' to ~/.gitconfig a few months
ago, I copied this line from .git/config:
fetch = +refs/heads/*:refs/remotes/origin/*
If this line i
Andrew Dunstan wrote:
>
>
> On 06/13/2011 02:26 PM, Bruce Momjian wrote:
> > I found the cause. When I added 'github' to ~/.gitconfig a few months
> > ago, I copied this line from .git/config:
> >
> > fetch = +refs/heads/*:refs/remotes/origin/*
> >
> > If this line is in ~/.gitconfig for both
Alvaro, Dean,
>> I think that you also need to update the constraint exclusion code
>> > (get_relation_constraints() or nearby), otherwise the planner might
>> > exclude a relation on the basis of a CHECK constraint that is not
>> > currently VALID.
> Ouch, yeah, thanks for pointing that out. Fo
Excerpts from Dean Rasheed's message of sáb jun 11 09:32:15 -0400 2011:
> On 1 June 2011 23:47, Alvaro Herrera wrote:
> >
> > Here's a complete patch with all this stuff, plus doc additions and
> > simple regression tests for the new ALTER DOMAIN commands.
> >
> > Enable CHECK constraints to be
Excerpts from Tom Lane's message of lun jun 13 09:57:50 -0400 2011:
> Jaime Casanova writes:
> > On Sat, Jun 11, 2011 at 8:01 PM, Robert Haas wrote:
> >> "can't reassign objects owned by %s because this user is internal to
> >> the database system" ?
>
> > that message is not that clear... it se
I was reading the partitioning docs when I spotted this. I think it means to
highlight the advantages of DROP TABLE over DELETE rather than ALTER TABLE.
Best,
David
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 4c9fc5d..0cdb800 100644
*** a/doc/src/sgml/ddl.sgml
--- b/doc/src
On Mon, Jun 13, 2011 at 03:33:24PM -0400, Tom Lane wrote:
> We can either change that now, or undo the
> unnecessary change in existing RM IDs. I vote for the latter.
Sounds good to me. I'd offer a patch, but it'd probably take you longer
to apply than to make the change yourself.
Dan
--
Dan R
Peter Eisentraut writes:
> Surely we don't need parse.pl and parse2.pl? parse.pl, the one that's
> not used, it already showing signs of semi-bit-rot:
> Use of assignment to $[ is deprecated at ./parse.pl line 21.
> I propose that we move parse2.pl to parse.pl and only keep the one.
Yes. This
On 06/13/2011 02:26 PM, Bruce Momjian wrote:
I found the cause. When I added 'github' to ~/.gitconfig a few months
ago, I copied this line from .git/config:
fetch = +refs/heads/*:refs/remotes/origin/*
If this line is in ~/.gitconfig for both 'origin' and 'github', git
cannot create .g
On Mon, Jun 13, 2011 at 08:21:05AM -0400, Robert Haas wrote:
> On Mon, Jun 13, 2011 at 1:12 AM, Noah Misch wrote:
> > This probably would not replace a backend-local counter of processed
> > messages
> > for RangeVarLockRelid()'s purposes. ?It's quite possibly a good way to
> > reduce
> > SInval
On 6/13/11 11:29 AM, Robert Haas wrote:
> On Mon, Jun 13, 2011 at 2:25 PM, Josh Berkus wrote:
>> As a reminder, CommitFest 1 for PostgreSQL 9.2 development starts in
>> less than two days.
>>
>> If you have a patch for 9.2 which is ready for review, please add it to
>> the commitfest application r
Surely we don't need parse.pl and parse2.pl? parse.pl, the one that's
not used, it already showing signs of semi-bit-rot:
Use of assignment to $[ is deprecated at ./parse.pl line 21.
I propose that we move parse2.pl to parse.pl and only keep the one.
--
Sent via pgsql-hackers mailing list (p
Dave Page writes:
> I've already implemented some simple qual pushdown in the redis FDW,
> and am planning to do something similar for MySQL - however I won't be
> surprised if I have to rewrite redisGetQual in
> https://github.com/dpage/redis_fdw/blob/master/redis_fdw.c for
> example.
OK, *now*
Heikki Linnakangas writes:
> On 13.06.2011 21:31, Tom Lane wrote:
>> So far as I can tell, that breaks pg_upgrade (if there are any open
>> prepared transactions) for no redeeming social benefit.
> Surely pg_upgrade can't work anyway if there's any open prepared
> transactions in the database. W
On Mon, Jun 13, 2011 at 10:22:19PM +0300, Heikki Linnakangas wrote:
> As far as I can tell it was for purely cosmetic reasons, to have lock
> and predicate lock lines together.
Yes, that is the only reason.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent
On ons, 2011-06-08 at 10:14 +0200, Florian Pflug wrote:
> But then you lose the ability to evaluate user-supplied
> XPath expressions, because there's no way of telling which of these
> function to use.
Perhaps having both variants, one type-safe and one not, would work. I
don't agree with doing
On 13.06.2011 21:31, Tom Lane wrote:
So I finally started actually reading the SSI changes, and I am a tad
distressed by this:
diff --git a/src/include/access/twophase_rmgr.h
b/src/include/access/twophase_rmgr.h
index a541d0f..1c7d8bb 100644
--- a/src/include/access/twophase_rmgr.h
+++ b/src/in
Tom Lane wrote:
> What was the rationale for changing the assignments of existing
> 2PC IDs? So far as I can tell, that breaks pg_upgrade (if there
> are any open prepared transactions) for no redeeming social
> benefit. Is there a reason why TWOPHASE_RM_PREDICATELOCK_ID has
> to be 2 and not
On Mon, Jun 13, 2011 at 8:16 AM, Robert Haas wrote:
> If the data type is hashable, you could consider building a hash table
> on the MCVs and then do a probe for each element in the array. I
> think that's better than the other way around because there can't be
> more than 10k MCVs, whereas the
On Mon, Jun 13, 2011 at 7:08 PM, Robert Haas wrote:
> But my point is: any FDW code Dave rights now is not going to have
> major dependencies on the planner that will potentially require
> extensive reworking in the future because it won't have any real
> dependencies on the planner at all. It's
2011/6/13 Robert Haas :
> On Mon, Jun 13, 2011 at 1:40 PM, Kohei KaiGai wrote:
>> 2011/6/13 Robert Haas :
>>> On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai wrote:
The attached patch is an update revision of security label support
for shared database objects.
>>>
>>> I'm kind of unexcit
So I finally started actually reading the SSI changes, and I am a tad
distressed by this:
diff --git a/src/include/access/twophase_rmgr.h
b/src/include/access/twophase_rmgr.h
index a541d0f..1c7d8bb 100644
--- a/src/include/access/twophase_rmgr.h
+++ b/src/include/access/twophase_rmgr.h
@@ -23,8 +
On Mon, Jun 13, 2011 at 2:25 PM, Josh Berkus wrote:
> As a reminder, CommitFest 1 for PostgreSQL 9.2 development starts in
> less than two days.
>
> If you have a patch for 9.2 which is ready for review, please add it to
> the commitfest application right now.
You forgot part #2: please also volu
Robert Haas wrote:
> On Sun, Jun 12, 2011 at 7:59 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >> > Did the system create the .git/config '[branch "REL9_1_STABLE"]' section
> >> > for you or did you create it manually?
> >>
> >> git created them for me. ?I did no conf
Hackers,
As a reminder, CommitFest 1 for PostgreSQL 9.2 development starts in
less than two days.
If you have a patch for 9.2 which is ready for review, please add it to
the commitfest application right now.
Thanks!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsq
Robert Haas writes:
> But my point is: any FDW code Dave rights now is not going to have
> major dependencies on the planner that will potentially require
> extensive reworking in the future because it won't have any real
> dependencies on the planner at all. It's not like we have an API and
> we
Dave Page writes:
> On Mon, Jun 13, 2011 at 6:56 PM, Tom Lane wrote:
>> I think we're talking past each other.
> Hmm, I wonder if you're correct (as usual :-p). I thought you were
> talking about the API as defined here:
> http://www.postgresql.org/docs/9.1/static/fdw-routines.html, not
> intern
On Mon, Jun 13, 2011 at 1:40 PM, Kohei KaiGai wrote:
> 2011/6/13 Robert Haas :
>> On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai wrote:
>>> The attached patch is an update revision of security label support
>>> for shared database objects.
>>
>> I'm kind of unexcited about this whole idea. Addin
On Mon, Jun 13, 2011 at 1:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote:
>>> BTW; it seems to me this should be documented, as it could really hack
>>> off developers. I can't see anything in the docs to imply the API
>>> might be radically red
On Mon, Jun 13, 2011 at 6:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote:
>>> BTW; it seems to me this should be documented, as it could really hack
>>> off developers. I can't see anything in the docs to imply the API
>>> might be radically red
Robert Haas writes:
> On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote:
>> BTW; it seems to me this should be documented, as it could really hack
>> off developers. I can't see anything in the docs to imply the API
>> might be radically redesigned.
> And I'm still unconvinced that it's needed.
2011/6/13 Robert Haas :
> On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai wrote:
>> The attached patch is an update revision of security label support
>> for shared database objects.
>
> I'm kind of unexcited about this whole idea. Adding a shared catalog
> for a feature that's only of interest to
Simon Riggs wrote:
> On Sun, Jun 12, 2011 at 2:23 AM, Robert Haas wrote:
> > On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake
> > wrote:
> >> On 6/11/2011 1:23 PM, Bruce Momjian wrote:
> >>>
> There is a difference between a project name and something that directly
> affects usability.
On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai wrote:
> The attached patch is an update revision of security label support
> for shared database objects.
I'm kind of unexcited about this whole idea. Adding a shared catalog
for a feature that's only of interest to a small percentage of our
user p
Hi,
Drs. Jeffrey Carver, Rosanna Guadagno, Debra McCallum, and Mr. Amiangshu
Bosu, University of Alabama, and Dr. Lorin Hochstein, University of
Southern California, are conducting a survey of open-source software
developers. This survey seeks to understand how developers on distributed,
virtual
On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote:
> On Mon, Jun 13, 2011 at 5:29 PM, Christopher Browne
> wrote:
>> On Mon, Jun 13, 2011 at 4:08 PM, Aidan Van Dyk wrote:
>>> On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote:
>>>
Yeah - MySQL is one of the ones I've been hacking on. It's h
On Mon, Jun 13, 2011 at 5:29 PM, Christopher Browne wrote:
> On Mon, Jun 13, 2011 at 4:08 PM, Aidan Van Dyk wrote:
>> On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote:
>>
>>> Yeah - MySQL is one of the ones I've been hacking on. It's hard to be
>>> motivated if its going to need a complete rewri
On Mon, Jun 13, 2011 at 4:08 PM, Aidan Van Dyk wrote:
> On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote:
>
>> Yeah - MySQL is one of the ones I've been hacking on. It's hard to be
>> motivated if its going to need a complete rewrite within a year
>> though. I'll still have to work on it, as I've
Thanks Bob for your lead. I was finally able to solve my issue. I had
earlier installed the binary version of postgresql. As I had to compile
certain contrib/modules sometime back, I had chosen to set USE PGXS=1 in my
.zshrc file. This was causing these errors. It was silly mistake from my
end. Tha
On Mon, Jun 13, 2011 at 11:56 AM, Simon Riggs wrote:
> +1
>
> If we were going to make changes like this, I'd suggest we save them
> up in a big bag for when we change major version number. Everybody in
> the world thinks that PostgreSQL v8 is compatible across all versions
> (8.0, 8.1, 8.2, 8.3,
On Mon, Jun 13, 2011 at 11:09 AM, Tom Lane wrote:
> I wrote:
>>> Historically this i++ approach has been used in a lot of places that
>>> fill in system catalog tuples. We've fixed some of them over
>>> time, but I doubt this is the only one remaining. If we're going
>>> to try to remove it here
2011/6/13 Robert Haas :
> On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai wrote:
>> For syscache, length of a typical security label in selinux is
>> less than 64 bytes. If we assume an entry consume 128bytes
>> including Oid pairs or pointers, its consumption is 128KBytes
>> per 1,000 of tables or
On Mon, Jun 13, 2011 at 10:37 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of sáb jun 11 21:01:55 -0400 2011:
>> On Thu, Jun 9, 2011 at 1:26 PM, Jaime Casanova wrote:
>> > on shdepReassignOwned() we have this message, which is obviously wrong
>> > we are not dropping objects ju
On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote:
> Yeah - MySQL is one of the ones I've been hacking on. It's hard to be
> motivated if its going to need a complete rewrite within a year
> though. I'll still have to work on it, as I've committed to giving
> talks on it, but others might not both
On Sun, Jun 12, 2011 at 2:23 AM, Robert Haas wrote:
> On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake
> wrote:
>> On 6/11/2011 1:23 PM, Bruce Momjian wrote:
>>>
There is a difference between a project name and something that directly
affects usability. +1 on fixing this. IMO, we don't
On Mon, Jun 13, 2011 at 4:38 PM, Andrew Dunstan wrote:
>
>
> On 06/13/2011 10:25 AM, Dave Page wrote:
>>
>>> Don't hold your breath. We'll probably be making enough changes in the
>>> FDW infrastructure (particularly planner support) that making an FDW
>>> work on both 9.1 and 9.2 would be an exe
On Mon, Jun 13, 2011 at 09:01:45AM +0200, Florian Pflug wrote:
> Hm, that's less bulky but more kludgy, I'd say. But wait a minute...
>
> If ANY and ALL are reserved anyway, should it be possible to
> make "(ANY(..) )" and "(ALL(...) )"
> work grammar-wise? (Note the enclosing parens)
This woul
On Thu, Jun 9, 2011 at 10:38 PM, Noah Misch wrote:
> On Fri, Apr 22, 2011 at 11:10:34AM -0400, Noah Misch wrote:
>> On Tue, Mar 15, 2011 at 10:22:59PM -0400, Noah Misch wrote:
>> > On Mon, Mar 14, 2011 at 01:56:22PM +0200, Heikki Linnakangas wrote:
>> > > On 12.03.2011 12:40, Noah Misch wrote:
>>
On Jun 13, 2011, at 10:22 AM, Robert Haas wrote:
>> A synonym feature would definitely be useful for cases like this. We have a
>> poorly named database at work; it's been that way for years and the only
>> reason it's never been cleaned up is because it would require simultaneously
>> changing
On 06/13/2011 10:25 AM, Dave Page wrote:
Don't hold your breath. We'll probably be making enough changes in the
FDW infrastructure (particularly planner support) that making an FDW
work on both 9.1 and 9.2 would be an exercise in frustration, if it's
even possible.
Oh joy. There's a GSoC st
Excerpts from Robert Haas's message of sáb jun 11 21:01:55 -0400 2011:
> On Thu, Jun 9, 2011 at 1:26 PM, Jaime Casanova wrote:
> > on shdepReassignOwned() we have this message, which is obviously wrong
> > we are not dropping objects just reassigning them...
> > """
> > erepo
On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
> On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut wrote:
> > On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
> >> On Tue, May 17, 2011 at 12:19 PM, Robert Haas
> >> wrote:
> >> >
> >> > The more controversial question is w
Dave Page writes:
> On Mon, Jun 13, 2011 at 3:36 PM, Tom Lane wrote:
>> Oh, that's by no means a waste of time --- we need some examples to help
>> us figure out where the pain points are. I'm just saying that the best
>> ways to do things will probably change quite a bit as we introduce
>> solu
On Mon, Jun 13, 2011 at 11:20 AM, Jim Nasby wrote:
> On Jun 11, 2011, at 9:36 PM, Robert Haas wrote:
>>> This is at least a use-case for something^Wfeature like 'create
>>> synonym', allowing smooth end-user's application upgrade on schema
>>> update. I am not claiming that we need that, it just s
On Mon, Jun 13, 2011 at 10:20 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 13, 2011 at 9:03 AM, Aidan Van Dyk wrote:
>>> On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote:
Incidentally, are you planning to revive the PostgreSQL FDW for 9.2?
That would be a killer feature
On Jun 11, 2011, at 9:36 PM, Robert Haas wrote:
>> This is at least a use-case for something^Wfeature like 'create
>> synonym', allowing smooth end-user's application upgrade on schema
>> update. I am not claiming that we need that, it just seems a good
>> usecase for column alias/synonym.
>
> I h
On Mon, Jun 13, 2011 at 3:11 AM, Robert Haas wrote:
> On Sun, Jun 12, 2011 at 3:01 PM, Noah Misch wrote:
>> I fully agree. That said, if this works on the standby, we may as well also
>> use
>> it opportunistically on the master, to throttle bloat.
>
> As long as the performance cost is de mini
I wrote:
>> Historically this i++ approach has been used in a lot of places that
>> fill in system catalog tuples. We've fixed some of them over
>> time, but I doubt this is the only one remaining. If we're going
>> to try to remove it here, maybe we ought to try to fix them all
>> rather than ju
On Mon, Jun 13, 2011 at 10:29 AM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> On 06/12/2011 11:39 PM, Robert Haas wrote:
>>> Profiling reveals that the system spends enormous amounts of CPU time
>>> in s_lock.
>
>> just to reiterate that with numbers - at 160 threads with both patches
>> ap
On Mon, Jun 13, 2011 at 3:36 PM, Tom Lane wrote:
> Dave Page writes:
>> On Mon, Jun 13, 2011 at 3:20 PM, Tom Lane wrote:
>>> Don't hold your breath. We'll probably be making enough changes in the
>>> FDW infrastructure (particularly planner support) that making an FDW
>>> work on both 9.1 and 9
On Mon, Jun 13, 2011 at 8:55 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 13, 2011 at 2:41 AM, Jaime Casanova
>> wrote:
>>> btw, i'm allowed to use ALTER TABLE to assign a new owner (even an
>>> unprivileged one) to a system catalog, probably that's a bug.
>
>> +1 for tightening tha
Dave Page writes:
> On Mon, Jun 13, 2011 at 3:20 PM, Tom Lane wrote:
>> Don't hold your breath. We'll probably be making enough changes in the
>> FDW infrastructure (particularly planner support) that making an FDW
>> work on both 9.1 and 9.2 would be an exercise in frustration, if it's
>> even
Stefan Kaltenbrunner writes:
> On 06/12/2011 11:39 PM, Robert Haas wrote:
>> Profiling reveals that the system spends enormous amounts of CPU time
>> in s_lock.
> just to reiterate that with numbers - at 160 threads with both patches
> applied the profile looks like:
> samples %image
On Mon, Jun 13, 2011 at 3:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 13, 2011 at 9:03 AM, Aidan Van Dyk wrote:
>>> On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote:
Incidentally, are you planning to revive the PostgreSQL FDW for 9.2?
That would be a killer feature.
Robert Haas writes:
> On Mon, Jun 13, 2011 at 9:03 AM, Aidan Van Dyk wrote:
>> On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote:
>>> Incidentally, are you planning to revive the PostgreSQL FDW for 9.2?
>>> That would be a killer feature.
>> Even more killer would be that it could be built/pa
On 06/13/2011 10:07 AM, Robert Haas wrote:
Some languages use =~ and some use just ~... I was just
wondering if anyone thought the commutator of =~ was ~=...
My feeling is it's a bit dangerous. It's too easy to fat-finger the
reverse op, and get something quite unintended.
cheers
andrew (
On 06/13/2011 09:55 AM, Tom Lane wrote:
Robert Haas writes:
On Mon, Jun 13, 2011 at 2:41 AM, Jaime Casanova wrote:
btw, i'm allowed to use ALTER TABLE to assign a new owner (even an
unprivileged one) to a system catalog, probably that's a bug.
+1 for tightening that up in 9.2.
Nonsense.
On Mon, Jun 13, 2011 at 3:01 AM, Florian Pflug wrote:
> On Jun13, 2011, at 05:12 , Robert Haas wrote:
>> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote:
>>> So I the end, I had to wrap the sub-query in a SQL-language
>>> function and use that in the check constraint. While this
>>> solved m
Robert Haas writes:
> On Sun, Jun 12, 2011 at 7:26 AM, wrote:
>> It's a readability improvement in src/backend/commands/comment.c
>> (CreateComments function), which changes the existing code from incrementing
>> a variable for use as the array index, to use explicit ``values'' instead.
> Wow
1 - 100 of 123 matches
Mail list logo
