On Mon, Jun 13, 2011 at 8:44 PM, Tom Lane wrote:
> 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/redi
On 14 June 2011 05:17, Franklin Haut wrote:
> 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_COLL
On Mon, Jun 13, 2011 at 10:59:38PM +0300, Peter Eisentraut wrote:
> I propose that we move parse2.pl to parse.pl and only keep the one.
I agree, thanks for taking care.
Originally I wanted to keep parse.pl around for a bit, so I could run both and
compare the output over the development cycle. Bu
Hi,
I would like to propose support for per-column generic option, which is
defined in the SQL/MED standard. In 9.0 release, support for foreign
tables and per-table generic option have been added, but support for
per-column generic option hasn't.
Please examine the description below and attache
On Jun14, 2011, at 07:15 , Tom Lane wrote:
> 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 a
On 13.06.2011 22:33, 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 Jun13, 2011, at 21:24 , Peter Eisentraut wrote:
> 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 t
On Jun13, 2011, at 16:19 , Andrew Dunstan wrote:
> 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
>
On Jun13, 2011, at 05:44 , Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote:
>>> (B) There should be a way to use ANY()/ALL() with the
>>> array elements becoming the left arguments of the operator.
>
>> It seems to me that if we provided some way of
On 10.06.2011 19:05, Kevin Grittner wrote:
I found that pgindent would like to tweak whitespace in three places
in that patch, and I found an unnecessary include that I would like
to remove. Normally, I would post a new version of the patch with
those adjustments, but there's been a disquieting
On Mon, Jun 13, 2011 at 8:10 PM, Jeff Janes wrote:
> 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 BufFre
On Tue, Jun 14, 2011 at 1:17 AM, Franklin Haut wrote:
> hi people, postgresql goes down on a WindowsXP SP3 machine.
> there a script to reproduce. (on XP with 8.4 works fine)
There is a crash related to time zone handling that was fixed in 9.1beta2.
--
Robert Haas
EnterpriseDB: http://www.ente
On Mon, Jun 13, 2011 at 4:04 PM, Noah Misch wrote:
> 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.
The attached patch is a preparation to rework implementation of DROP statement
using a common code. That intends to apply get_object_address() to resolve name
of objects to be removed, and eventually minimizes the number of places to put
permission checks.
Its first step is an enhancement of get_o
On Tue, Jun 14, 2011 at 1:15 AM, Tom Lane wrote:
> I'm not sure that pg_upgrade is a good vehicle for dispensing such
> advice, anyway. At least in the Red Hat packaging, end users will never
> read what it prints, unless maybe it fails outright and they're trying
> to debug why.
In my experienc
On Mon, Jun 13, 2011 at 10:54 PM, Bruce Momjian wrote:
> 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.
>> >
>>
Heikki Linnakangas wrote:
> Ok, I've renumbered the existing RMs back the way they were.
Don't we also need something like the attached?
-Kevin
ssi-twophase-c.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
I haven't looked at the patch yet, but here are a few comments on the
design, which overall looks good.
2011/6/14 Shigeru Hanada :
> 1) psql should support describing per-column generic options, so \dec
> command was added. If the form \dec+ is used, generic options are also
> displayed. Output
On 14.06.2011 15:14, Kevin Grittner wrote:
Heikki Linnakangas wrote:
Ok, I've renumbered the existing RMs back the way they were.
Don't we also need something like the attached?
Yes. I just committed a fix for that after noticing that the buildfarm
didn't like it. Sorry..
--
Heikki Li
On Mon, Jun 13, 2011 at 4:10 PM, wrote:
> 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 ent
On Tue, Jun 14, 2011 at 6:10 AM, Florian Pflug wrote:
> On Jun13, 2011, at 05:44 , Tom Lane wrote:
>> Robert Haas writes:
>>> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote:
(B) There should be a way to use ANY()/ALL() with the
array elements becoming the left arguments of the op
Hass,
there problem are fixed in 9.1beta2, and now works.
thanks
2011/6/14 Robert Haas
> On Tue, Jun 14, 2011 at 1:17 AM, Franklin Haut
> wrote:
> > hi people, postgresql goes down on a WindowsXP SP3 machine.
> > there a script to reproduce. (on XP with 8.4 works fine)
>
> There is a crash
Robert Haas wrote:
> On Mon, Jun 13, 2011 at 10:54 PM, Bruce Momjian wrote:
> > 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
> >> >
Magnus Hagander wrote:
> >> > I understand now --- that it is risky to create an "origin" branch in
> >> > ~/.gitconfig. ?I am now using an alias:
> >> >
> >> > ? ? ? ?[alias]
> >> > ? ? ? ? ? ? ? ?pgclone = clone
> >> > ssh://g...@gitmaster.postgresql.org/postgresql.git
> >> >
> >> > I assume the
On Tue, Jun 14, 2011 at 14:40, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Jun 13, 2011 at 10:54 PM, Bruce Momjian wrote:
>> > Alvaro Herrera wrote:
>> >> Excerpts from Bruce Momjian's message of lun jun 13 18:38:46 -0400 2011:
>> >> > Andrew Dunstan wrote:
>> >>
>> >> > > Is putting rem
On Mon, Jun 13, 2011 at 5:44 PM, David E. Wheeler wrote:
> 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.
I guess they might mean ALTER TABLE .. NO INHERIT. But I think I
agree that DROP
Tom Lane wrote:
> 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
On Jun14, 2011, at 14:29 , Robert Haas wrote:
> On Tue, Jun 14, 2011 at 6:10 AM, Florian Pflug wrote:
>> On Jun13, 2011, at 05:44 , Tom Lane wrote:
>>> Robert Haas writes:
On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote:
> (B) There should be a way to use ANY()/ALL() with the
>
Excerpts from richhguard-monotone's message of lun jun 13 16:10:17 -0400 2011:
> 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 thos
Version of patch with few more comments and some fixes.
--
With best regards,
Alexander Korotkov.
arrayanalyze-0.4.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
2011/5/16 Greg Smith :
> Cédric Villemain wrote:
>>
>>
>> http://git.postgresql.org/gitweb?p=users/c2main/postgres.git;a=shortlog;h=refs/heads/analyze_cache
>>
>
> This rebases easily to make Cedric's changes move to the end; I just pushed
> a version with that change to
> https://github.com/greg2n
Alvaro Herrera writes:
> Excerpts from richhguard-monotone's message of lun jun 13 16:10:17 -0400 2011:
>> 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, by using the symbolic cons
Excerpts from David E. Wheeler's message of lun jun 13 17:44:05 -0400 2011:
> 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.
I think the point of the existing wording is to point out
ALTER
On Tue, Jun 14, 2011 at 10:30 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from richhguard-monotone's message of lun jun 13 16:10:17 -0400
>> 2011:
>>> Do you have any advice of how to handle the inner loops, such as those
>>> initializing ``stakindN''. The entries before can be han
Excerpts from Tom Lane's message of mar jun 14 10:30:28 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from richhguard-monotone's message of lun jun 13 16:10:17 -0400
> > 2011:
> >> Do you have any advice of how to handle the inner loops, such as those
> >> initializing ``stakindN''. The entr
2011/6/3 Mark Kirkwood :
> On 02/06/11 18:34, Jaime Casanova wrote:
>>
>>
>> - the patch adds this to serial_schedule but no test has been added...
>>
>> diff --git a/src/test/regress/serial_schedule
>> b/src/test/regress/serial_schedule
>> index bb654f9..325cb3d 100644
>> --- a/src/test/regress/se
Heikki Linnakangas wrote:
> I did some further changes, refactoring SkipSerialization so that
> it's hopefully more readable, and added a comment about the
> side-effects. See attached. Let me know if I'm missing something.
I do think the changes improve readability. I don't see anything
miss
Alvaro Herrera writes:
> Excerpts from David E. Wheeler's message of lun jun 13 17:44:05 -0400 2011:
>> 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.
> I think the point of the existing
On Tue, Jun 14, 2011 at 10:29 AM, Cédric Villemain
wrote:
> 0001-Add-reloscache-column-to-pg_class.patch
> 0002-Add-a-function-to-update-the-new-pg_class-cols.patch
> 0003-Add-ANALYZE-OSCACHE-VERBOSE-relation.patch
> 0004-Add-a-Hook-to-handle-OSCache-stats.patch
> 0005-Add-reloscache-to-Index-Rel-
On Wed, May 25, 2011 at 3:05 PM, Simon Riggs wrote:
> Yes, that's correct. We can remove them from the normal commit record
> when nmsgs == 0.
Leonardo, can you submit an updated version of this patch today that
incorporates Simon's suggestion? The CommitFest starts tomorrow. If
not, please fee
On Fri, Jun 10, 2011 at 6:16 AM, Hitoshi Harada wrote:
> 2011/2/24 Andrew Tipton :
>> While playing around with the BOX and POINT datatypes, I was surprised to
>> note that BOX @> POINT (and likewise POINT <@ BOX) queries were not using
>> the GiST index I had created on the BOX column. The attac
I have left update_attstat which I'm unsure about, and have attached the
updated patch handling the other cases. This will be linked in via the
commitfest page.
I picked commands/comment.c randomly and found the i = 0, i++ method of
initializing the array made it harder for me to visualize it's
2011/6/14 Robert Haas :
> On Tue, Jun 14, 2011 at 10:29 AM, Cédric Villemain
> wrote:
>> 0001-Add-reloscache-column-to-pg_class.patch
>> 0002-Add-a-function-to-update-the-new-pg_class-cols.patch
>> 0003-Add-ANALYZE-OSCACHE-VERBOSE-relation.patch
>> 0004-Add-a-Hook-to-handle-OSCache-stats.patch
>>
On Sat, May 7, 2011 at 2:40 PM, Josh Kupershmidt wrote:
> Hi all,
>
> I use psql's -E mode every now and then, copy-and-pasting and further
> tweaking the SQL displayed. Most queries are displayed terminated by a
> semicolon, but quite a few aren't, making copy-and-paste just a bit
> more tedious.
On Jun 14, 2011, at 8:03 AM, Tom Lane wrote:
>> - ALTER TABLE is far faster than a bulk operation.
>> + ALTER TABLE (to split out a sub-table from the partitioned
>> + table) and DROP TABLE (to remove a partition altogether)
>> are
>> + both far faster than a bulk operation.
>
Excerpts from David E. Wheeler's message of mar jun 14 12:33:27 -0400 2011:
> On Jun 14, 2011, at 8:03 AM, Tom Lane wrote:
>
> >> - ALTER TABLE is far faster than a bulk operation.
> >> + ALTER TABLE (to split out a sub-table from the
> >> partitioned
> >> + table) and DROP TABLE (
On Jun 13, 2011, at 10:56 AM, Simon Riggs wrote:
> 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, 8.4), and it
Jim Nasby wrote:
> On Jun 13, 2011, at 10:56 AM, Simon Riggs wrote:
> > 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,
On Jun 13, 2011, at 6:05 PM, Tom Lane wrote:
> I looked into $SUBJECT. There appear to be two distinct issues:
>
> 1. On colugos (OS X with LLVM), the
...
> However, because when using gcc that only results in a warning,
> we didn't back-patch it. Now it appears that it's an error when using
Alvaro Herrera writes:
> Done that way (9.0 and beyond).
Re-reading the actual commit, I notice that there's now a grammatical
problem: the following sentence says
It also entirely avoids the VACUUM
overhead caused by a bulk DELETE.
which was okay when "it" referred to "ALTER TABL
On 06/14/2011 11:04 AM, Robert Haas wrote:
Even if the data were accurate and did not cause plan stability, we
have no evidence that using it will improve real-world performance.
That's the dependency Cédric has provided us a way to finally make
progress on. Everyone says there's no evide
On Tue, Jun 14, 2011 at 1:10 PM, Greg Smith wrote:
> On 06/14/2011 11:04 AM, Robert Haas wrote:
>> Even if the data were accurate and did not cause plan stability, we
>> have no evidence that using it will improve real-world performance.
>
> That's the dependency Cédric has provided us a way to fi
On 06/14/2011 11:44 AM, Jim Nasby wrote:
Wouldn't it be better still to have both the new and old columns
available for a while? That would produce the minimum amount of
disruption to tools, etc.
Doing this presumes the existence of a large number of tools where the
author is unlikely to be k
On Tue, Jun 14, 2011 at 12:06 PM, Cédric Villemain
wrote:
>> 1. ANALYZE happens far too infrequently to believe that any data taken
>> at ANALYZE time will still be relevant at execution time.
>
> ANALYZE happens when people execute it, else it is auto-analyze and I
> am not providing auto-analyze
On Tue, Jun 14, 2011 at 12:25 PM, Greg Smith wrote:
>
> Anyway, I want a larger change to pg_stat_activity than this one
Well, Simon recomended to have a big bag of changes that justify break
tools... and you have presented a good one item for that bag...
Maybe we should start a wiki page for thi
ProcGlobalShmemSize() currently includes code to allow space for
startupBufferPinWaitBufId. But I think that's redundant, because that
variable is stored in PROC_HDR *ProcGlobal, for which this function is
separately allocating space.
So I propose to apply the attached patch, barring objections.
On Tue, Jun 14, 2011 at 1:43 PM, Jaime Casanova wrote:
> On Tue, Jun 14, 2011 at 12:25 PM, Greg Smith wrote:
>>
>> Anyway, I want a larger change to pg_stat_activity than this one
>
> Well, Simon recomended to have a big bag of changes that justify break
> tools... and you have presented a good o
Greg Smith wrote:
> Doing this presumes the existence of a large number of tools where
> the author is unlikely to be keeping up with PostgreSQL
> development. I don't believe that theorized set of users actually
> exists.
There could be a number of queries used for monitoring or
administrati
Currently, the planner and executor are mostly independent of each
other: the planner doesn't really know when the plan will be executed,
and the executor doesn't know how recently the plan was made.
We can work out the various paths through the traffic cop to see when
a plan will be a "one-shot"
Simon Riggs wrote:
> Currently, the planner and executor are mostly independent of each
> other: the planner doesn't really know when the plan will be executed,
> and the executor doesn't know how recently the plan was made.
>
> We can work out the various paths through the traffic cop to see when
On Tue, Jun 14, 2011 at 4:21 PM, Robert Haas wrote:
> On Wed, May 25, 2011 at 3:05 PM, Simon Riggs wrote:
>> Yes, that's correct. We can remove them from the normal commit record
>> when nmsgs == 0.
>
> Leonardo, can you submit an updated version of this patch today that
> incorporates Simon's su
On Tue, Jun 14, 2011 at 7:28 PM, Bruce Momjian wrote:
> Simon Riggs wrote:
>> Currently, the planner and executor are mostly independent of each
>> other: the planner doesn't really know when the plan will be executed,
>> and the executor doesn't know how recently the plan was made.
>>
>> We can w
Hello,
Because, I work a little bit on streaming protocol and from time to
time I have crashes. I want ask if you wont crash reporting (this is one
of minors products from mmap playing) those what I have there is mmaped
areas, and call stacks, and some other stuff. This based reports works
fo
Simon Riggs wrote:
> On Tue, Jun 14, 2011 at 7:28 PM, Bruce Momjian wrote:
> > Simon Riggs wrote:
> >> Currently, the planner and executor are mostly independent of each
> >> other: the planner doesn't really know when the plan will be executed,
> >> and the executor doesn't know how recently the
On Mon, Jun 13, 2011 at 10:44 PM, David E. Wheeler wrote:
> 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
Bruce Momjian wrote:
> > This argument seems a tad peculiar, since the *entire* *point* of
> > pg_upgrade is to push physical files from one installation into another
> > even though compatibility isn't guaranteed. It is the program's duty to
> > understand enough to know whether it can transport
On Tue, Jun 14, 2011 at 2:31 PM, Simon Riggs wrote:
> We don't need to be in a hurry here. As the reviewer I'm happy to give
> Leonardo some time, obviously no more than the end of the commit fest.
Well, we certainly have the option to review and commit the patch any
time up until feature freeze.
2011/6/14 Robert Haas :
> On Tue, Jun 14, 2011 at 12:06 PM, Cédric Villemain
> wrote:
>>> 1. ANALYZE happens far too infrequently to believe that any data taken
>>> at ANALYZE time will still be relevant at execution time.
>>
>> ANALYZE happens when people execute it, else it is auto-analyze and I
Excerpts from Tom Lane's message of mar jun 14 13:04:30 -0400 2011:
> Alvaro Herrera writes:
> > Done that way (9.0 and beyond).
>
> Re-reading the actual commit, I notice that there's now a grammatical
> problem: the following sentence says
>
>It also entirely avoids the VACUUM
>
Excerpts from Josh Kupershmidt's message of sáb may 07 16:40:35 -0300 2011:
> And while I'm griping about describe.c, is it just me or is the source
> code indentation in that file totally screwy? I'm using emacs and I've
> loaded the snippet for pgsql-c-mode from
> ./src/tools/editors/emacs.sampl
How much do we care about applying perltidy, as described in
src/tools/msvc/README, everywhere? I just ran it across the entire
tree, using
perltidy -b -bl -nsfs -naws -l=100 -ole=unix **/*.pl **/*.pm
and it generated 6531 lines of (unified) diff, of which 357 are in
src/tools/msvc/ itself. So
Peter Eisentraut wrote:
> How much do we care about applying perltidy, as described in
> src/tools/msvc/README, everywhere? I just ran it across the entire
> tree, using
>
> perltidy -b -bl -nsfs -naws -l=100 -ole=unix **/*.pl **/*.pm
>
> and it generated 6531 lines of (unified) diff, of which 3
On Tue, Jun 14, 2011 at 21:39, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> How much do we care about applying perltidy, as described in
>> src/tools/msvc/README, everywhere? I just ran it across the entire
>> tree, using
>>
>> perltidy -b -bl -nsfs -naws -l=100 -ole=unix **/*.pl **/*.pm
>>
On Mon, Jun 13, 2011 at 9:09 PM, 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. I didn't check the
> rest of the code to see if t
Seref Arikan writes:
> This is actually a request for documentation guidance. I intend to
> develop an extension to postgresql. Basically I'd like to place calls
> to network using ZeroMQ, and I need to have detailed information about
You didn't tell us about what you want to achieve, only how.
Stack trace, nothing else. Now that the horse has left the barn, I changed to keep error builds...Process: postgres [17457]Path: /Volumes/High Usage/usr/local/src/build-farm-4.4/builds/HEAD/pgsql.6849/src/test/regress/tmp_check/install/usr/local/src/build-farm-4.4/builds/HEAD/in
On 06/14/2011 02:27 AM, Jeff Janes wrote:
> 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
Robert Creager wrote:
> Stack trace, nothing else.
> 3 postgres 0x00010005cafa
> multixact_twophase_postcommit + 74 (multixact.c:1367)
> 4 postgres 0x00010005deab
> ProcessRecords + 91 (twophase.c:1407)
> 5 postgres
On 06/14/2011 02:20 PM, Kevin Grittner wrote:
Just on our Wiki pages we have some queries available for copy/paste
which would need multiple
versions while both column names were in supported versions of the
software:
http://wiki.postgresql.org/wiki/Lock_dependency_information
http://wiki.postg
Excerpts from Bruce Momjian's message of mar jun 14 12:59:15 -0400 2011:
> Well, someone doing SELECT *, which is probably 90% of the users, are
> going to be pretty confused by duplicate columns, asking, "What is the
> difference"? For those people this would make things worse than they
> are no
Excerpts from Cédric Villemain's message of mar jun 14 10:29:36 -0400 2011:
> Attached are updated patches without the plugin itself. I've also
> added the cache_page_cost GUC, this one is not per tablespace, like
> others page_cost.
>
> There are 6 patches:
>
> 0001-Add-reloscache-column-to-pg_
With gcc 4.6, I get this warning:
dblink.c: In function ‘dblink_send_query’:
dblink.c:620:7: warning: variable ‘freeconn’ set but not used
[-Wunused-but-set-variable]
I don't know much about the internals of dblink, but judging from the
surrounding code, I guess that this fix is necessary:
diff
Simon Riggs writes:
> Currently, the planner and executor are mostly independent of each
> other: the planner doesn't really know when the plan will be executed,
> and the executor doesn't know how recently the plan was made.
> We can work out the various paths through the traffic cop to see when
Robert Creager wrote:
> You believe it was related to the flurry of errors that popped up
> then.
I haven't looked at all the error in the "flurry". I think your
particular report is consistent with being caused by this commit:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=b8
On tis, 2011-06-14 at 13:50 -0400, Robert Haas wrote:
> There are real problems with the idea of having one release where we
> break everything that we want to break - mostly from a process
> standpoint. We aren't always good at being organized and disciplined,
> and coming up with a multi-year pl
2011/6/14 Alvaro Herrera :
> Excerpts from Cédric Villemain's message of mar jun 14 10:29:36 -0400 2011:
>
>> Attached are updated patches without the plugin itself. I've also
>> added the cache_page_cost GUC, this one is not per tablespace, like
>> others page_cost.
>>
>> There are 6 patches:
>>
>
Excerpts from Alvaro Herrera's message of lun jun 13 18:08:12 -0400 2011:
> Excerpts from Dean Rasheed's message of sáb jun 11 09:32:15 -0400 2011:
> > I think that you also need to update the constraint exclusion code
> > (get_relation_constraints() or nearby), otherwise the planner might
> > exc
Excerpts from Cédric Villemain's message of mar jun 14 17:10:20 -0400 2011:
> If we can have ALTER TABLE running on heavy workload, why not.
> I am bit scared by the effect of such reloption, it focus on HINT
> oriented strategy when I would like to allow a dynamic strategy from
> the server. This
On Tue, Jun 14, 2011 at 4:14 PM, Alvaro Herrera
wrote:
> Excerpts from Alvaro Herrera's message of lun jun 13 18:08:12 -0400 2011:
>> Excerpts from Dean Rasheed's message of sáb jun 11 09:32:15 -0400 2011:
>
>> > I think that you also need to update the constraint exclusion code
>> > (get_relation
Andrew Dunstan writes:
> On 06/13/2011 08:05 PM, Tom Lane wrote:
>> I looked into $SUBJECT. There appear to be two distinct issues:
>> ...
> I think we can be a bit more liberal about build patches than things
> that can affect the runtime behaviour.
> So +1 for fixing both of these.
I've com
Peter Eisentraut wrote:
> On tis, 2011-06-14 at 13:50 -0400, Robert Haas wrote:
> > There are real problems with the idea of having one release where we
> > break everything that we want to break - mostly from a process
> > standpoint. We aren't always good at being organized and disciplined,
> >
Peter Eisentraut writes:
> On tis, 2011-06-14 at 13:50 -0400, Robert Haas wrote:
>> There are real problems with the idea of having one release where we
>> break everything that we want to break - mostly from a process
>> standpoint. We aren't always good at being organized and disciplined,
>> an
On 06/14/2011 05:45 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 06/13/2011 08:05 PM, Tom Lane wrote:
I looked into $SUBJECT. There appear to be two distinct issues:
...
I think we can be a bit more liberal about build patches than things
that can affect the runtime behaviour.
So +1 for f
Alvaro Herrera writes:
> Excerpts from Cédric Villemain's message of mar jun 14 10:29:36 -0400 2011:
>> 0001-Add-reloscache-column-to-pg_class.patch
> Hmm, do you really need this to be a new column? Would it work to have
> it be a reloption?
If it's to be updated in the same way as ANALYZE up
Andrew Dunstan writes:
> On 06/14/2011 05:45 PM, Tom Lane wrote:
>> I've committed patches that fix these issues on my own OS X machine,
> Well, OSX is just using our usual *nix paraphernalia, so if it's broken
> won't all such platforms probably be broken too?
Yes, certainly. The reason I spe
On 06/14/2011 01:16 PM, Robert Haas wrote:
But there's no reason that code (which may or may not eventually prove
useful) has to be incorporated into the main tree. We don't commit
code so people can go benchmark it; we ask for the benchmarking to be
done first, and then if the results are favor
Greg Smith wrote:
> On 06/14/2011 01:16 PM, Robert Haas wrote:
> > But there's no reason that code (which may or may not eventually prove
> > useful) has to be incorporated into the main tree. We don't commit
> > code so people can go benchmark it; we ask for the benchmarking to be
> > done first,
Greg Smith writes:
> On 06/14/2011 01:16 PM, Robert Haas wrote:
>> But there's no reason that code (which may or may not eventually prove
>> useful) has to be incorporated into the main tree. We don't commit
>> code so people can go benchmark it; we ask for the benchmarking to be
>> done first, a
On 06/14/2011 07:08 PM, Tom Lane wrote:
I concur with Robert's desire to not push experimental code into the
main repository, but we need to have *some* way of working with it.
Maybe a separate repo where experimental branches could hang out would
be helpful?
Well, this one is sitting aroun
On 06/14/2011 06:00 PM, Tom Lane wrote:
As far as Greg's proposal is concerned, I don't see how a proposed
addition of two columns would justify renaming an existing column.
Additions should not break any sanely-implemented application, but
renamings certainly will.
It's not so much justifi
1 - 100 of 123 matches
Mail list logo
