Hi,
Testing the CHECK NOT VALID patch i found $subject... is this intended?
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
On Wed, Jun 15, 2011 at 12:58 AM, Fujii Masao wrote:
>
> http://forge.mysql.com/worklog/task.php?id=344
> According to the above page, one purpose of time-delayed replication is to
> protect against user mistakes on master. But, when an user notices his wrong
> operation on master, what should he
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
On Thu, Apr 21, 2011 at 12:18 PM, Robert Haas wrote:
> On Wed, Apr 20, 2011 at 11:15 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I am a bit concerned about the reliability of this approach. If there
>>> is some network lag, or some lag in processing from the master, we
>>> could easily get t
On 2011-06-15 05:01, Bruce Momjian wrote:
You might remember we added a postmaster/postgres -b switch to indicate
binary upgrade mode. The attached patch prevents any client without an
application_name of 'binary-upgrade' from connecting to the cluster
while it is binary upgrade mode. This help
Previous version (at7-alt-index-opfamily.patch):
http://archives.postgresql.org/message-id/20110113230124.ga18...@tornado.gateway.2wire.net
Design:
http://archives.postgresql.org/message-id/20110524104029.gb18...@tornado.gateway.2wire.net
Patches committed in 2011CF1 allow ALTER TABLE ... ALTER ..
On Tue, Jun 14, 2011 at 11:04 PM, Greg Sabino Mullane wrote:
>> For me, the litmus test is whether the change provides enough
>> improvement that it outweighs the disruption when the user runs into
>> it.
>
> For the procpid that started all of this, the clear answer is no. I'm
> surprised people
On Tue, Jun 14, 2011 at 6:17 PM, Greg Smith wrote:
> Who said anything about this being a commit candidate? The "WIP" in the
> subject says it's not intended to be. The community asks people to submit
> design ideas early so that ideas around them can be explored publicly. One
> of the things t
Tom Lane wrote:
> Bruce Momjian writes:
> > You might remember we added a postmaster/postgres -b switch to indicate
> > binary upgrade mode. The attached patch prevents any client without an
> > application_name of 'binary-upgrade' from connecting to the cluster
> > while it is binary upgrade mod
Bruce Momjian writes:
> You might remember we added a postmaster/postgres -b switch to indicate
> binary upgrade mode. The attached patch prevents any client without an
> application_name of 'binary-upgrade' from connecting to the cluster
> while it is binary upgrade mode. This helps prevent una
Yesterday on PGXN I just released the first version of planinstr, a
plugin module to append planner time to EXPLAIN. I post this here
since it is mostly for developers.
http://www.pgxn.org/dist/planinstr/
db1=# load '$libdir/planinstr';
LOAD
db1=# explain select * from pg_class;
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> For me, the litmus test is whether the change provides enough
> improvement that it outweighs the disruption when the user runs into
> it.
For the procpid that started all of this, the clear answer is no. I'm
surprised people seriously con
You might remember we added a postmaster/postgres -b switch to indicate
binary upgrade mode. The attached patch prevents any client without an
application_name of 'binary-upgrade' from connecting to the cluster
while it is binary upgrade mode. This helps prevent unauthorized users
from connecting
On Wed, Jun 15, 2011 at 11:41, Fujii Masao wrote:
> ISTM that the root problem is that dblink_send_query calls DBLINK_GET_CONN
> though it doesn't accept the connection string as an argument.
+1 for the fix. I have the same conclusion at the first glance.
> Since the first
> argument in dblink_s
On 06/14/2011 06:09 PM, Tom Lane wrote:
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
On Wed, Jun 15, 2011 at 5:34 AM, Peter Eisentraut wrote:
> 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 judgin
On Wed, Jun 15, 2011 at 2:50 AM, Bruce Momjian wrote:
> Agreed on moving '' and ' in transaction' into separate
> fields. If I had thought of it I would have done it that way years ago.
> (At least I think it was me.) Using angle brackets to put magic values
> in that field was clearly wrong.
I
On Tue, Jun 14, 2011 at 3:25 PM, Alvaro Herrera
wrote:
> pgindent moves strings back to the left when it thinks they fit within
> 80 columns. Yes, that seems pretty screwy.
I am losing track of the ways in which pgindent has managed to mangle
our source code :-/
Josh
--
Sent via pgsql-hackers
On Tue, Jun 14, 2011 at 12:15 PM, Merlin Moncure wrote:
> I did a quick review and test of your patch. It didn't quite apply
> cleanly due to recent non-related describe.c changes -- updated patch
> attached.
Thanks for looking at this. Your updated patch looks good to me.
> First, I'll give yo
Greg Smith wrote:
> 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 wi
On Jun 14, 2011, at 3:45 PM, Tom Lane wrote:
> I've committed patches that fix these issues on my own OS X machine,
> though it remains to be seen whether polecat and colugos will like
> them. It turns out that whatever setup Robert has got with
> '/Volumes/High Usage/' is really *not* fully ex
On Tue, Jun 14, 2011 at 4:41 PM, Jaime Casanova wrote:
> 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
On 15/06/11 02:52, Cédric Villemain wrote:
2011/6/3 Mark Kirkwood:
Corrected v4 patch with the test files, for completeness. Note that
discussion has moved on and there will be a v5 :-)
Mark, can you submit your updated patch ?
Thanks for the reminder! Here is v5. The changes are:
- guc i
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
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
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
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,
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
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
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
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
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
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,
> >
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
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
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
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
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:
>>
>
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
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
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
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
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_
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
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
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: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
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
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.
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
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
>>
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
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
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
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
>
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
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.
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 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
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
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
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
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
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
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"
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
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
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 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
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 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 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: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
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 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
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 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
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 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.
>
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.
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
>>
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
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
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 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-
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
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
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
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
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 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
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
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
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
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
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
>
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 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
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
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
1 - 100 of 123 matches
Mail list logo
