On 9 November 2011 02:42, Robert Haas wrote:
> On Tue, Nov 8, 2011 at 8:12 PM, Thom Brown wrote:
>> Why is this marked as done on with Wiki's todo list?
>
> I assume you're referring to this item:
>
> --
> \dd is missing comments for several types of objects. Comments are
> not handled at all fo
Hi,
Consider the following sequence of events:
s1 #> CREATE SCHEMA test_schema;
s1 #> CREATE TABLE test_schema.c1(x int);
Now open another session s2 and via gdb issue a breakpoint on
heap_create_with_catalog() which is called by DefineRelation().
s2 #> CREATE TABLE test_schema.c2(y int);
The
Christopher Browne wrote:
>> I think that JDBC and Npgsql should also support disabling
compression.
>
> That's the *real* problem here...
>
> You're quite right that if we allow controlling this on the libpq
> side, it is surely desirable to allow controlling this via JDBC,
> Npgsql, and other me
On Wed, Nov 9, 2011 at 3:38 AM, Thom Brown wrote:
> On 9 November 2011 02:42, Robert Haas wrote:
>> On Tue, Nov 8, 2011 at 8:12 PM, Thom Brown wrote:
>>> Why is this marked as done on with Wiki's todo list?
>>
>> I assume you're referring to this item:
>>
>> --
>> \dd is missing comments for sev
Hi guys,
I was thinking that could be great to add a column in \dx showing the available
options for each foreign data wrapper.
Seems reasonable?
--
--
Emanuel Calvo
Helpame.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
Excerpts from Jaime Casanova's message of mar nov 08 18:12:25 -0300 2011:
> On Sun, Nov 6, 2011 at 5:38 AM, Magnus Hagander wrote:
> >
> > Looks pretty useful.
>
> thanks for the review, attached is a new version of it
Note that AFAIK you shouldn't update the 1.0 extension script ... you
have t
On Wed, Nov 9, 2011 at 4:56 AM, Nikhil Sontakke wrote:
> Consider the following sequence of events:
>
> s1 #> CREATE SCHEMA test_schema;
>
> s1 #> CREATE TABLE test_schema.c1(x int);
>
> Now open another session s2 and via gdb issue a breakpoint on
> heap_create_with_catalog() which is called by D
I'd like to propose the attached patch, which changes
get_object_address() in a manner similar to what we did in
RangeVarGetRelid() in commit 4240e429d0c2d889d0cda23c618f94e12c13ade7.
The basic idea is that, if we look up an object name, acquire the
corresponding lock, and then find that the objec
On 15 December 2009 02:31, Jaime Casanova wrote:
> On Mon, Dec 14, 2009 at 7:29 PM, Simon Riggs wrote:
>> On Fri, 2009-12-04 at 09:00 +, Simon Riggs wrote:
>>> On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
>>> > Here is an update partitioning syntax patch.
>>> >
>>> > A bug repor
On Wed, Nov 9, 2011 at 9:06 AM, Heikki Linnakangas
wrote:
> In COPY, insert tuples to the heap in batches.
>
> This greatly reduces the WAL volume, especially when the table is narrow.
> The overhead of locking the heap page is also reduced. Reduced WAL traffic
> also makes it scale a lot better,
2011/11/9 Robert Haas :
> I'd like to propose the attached patch, which changes
> get_object_address() in a manner similar to what we did in
> RangeVarGetRelid() in commit 4240e429d0c2d889d0cda23c618f94e12c13ade7.
> The basic idea is that, if we look up an object name, acquire the
> corresponding
On Tue, Nov 8, 2011 at 9:23 PM, Kevin Grittner
wrote:
> That page describes three components: creating MVs, updating MVs, and
> having the planner automatically detect when an MV matches some
> portion of a regular query and using the MV instead of the specified
> tables in such cases. I have hi
On Wed, Nov 9, 2011 at 8:37 AM, Cédric Villemain
wrote:
> Maybe I miss something but:
> The ERROR message is misleading: the schema 'x' does exist.
No, it doesn't. The concurrent transaction has dropped it.
> And also
> why a drop schema would fail and a drop+create would success ?!
Because y
On Wed, Nov 9, 2011 at 8:26 AM, Thom Brown wrote:
>
> So will this be revived any time soon? Were there any subsequent
> proposals which were posted?
>
there was an updated patch, you can find in this thread:
http://archives.postgresql.org/message-id/20100114181323.9a33.52131...@oss.ntt.co.jp
n
> > We definitely need some interlocking to handle this. For lack of better
> > APIs, we could do a LockDatabaseObject() call in AccessShareLock mode on
> the
> > namespace and release the same on completion of the creation of the
> object.
> >
> > Thoughts?
>
> In general, we've been reluctant to
Robert Haas writes:
> I'd like to propose the attached patch, which changes
> get_object_address() in a manner similar to what we did in
> RangeVarGetRelid() in commit 4240e429d0c2d889d0cda23c618f94e12c13ade7.
I would think you need to drop the now-useless lock, and I sure hope
that RangeVarGetRe
On Wed, Nov 9, 2011 at 9:54 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'd like to propose the attached patch, which changes
>> get_object_address() in a manner similar to what we did in
>> RangeVarGetRelid() in commit 4240e429d0c2d889d0cda23c618f94e12c13ade7.
>
> I would think you need to drop
On Wed, Nov 9, 2011 at 9:51 AM, Nikhil Sontakke wrote:
> Yeah thanks, that does the object locking. For pre-9.1 versions, we will
> need a similar solution. I encountered the issue on 8.3.x..
I don't think we should back-patch a fix of this type. There is a lot
of cruftiness of this type scatter
On Wed, Nov 9, 2011 at 9:35 AM, Jaime Casanova wrote:
> On Wed, Nov 9, 2011 at 8:26 AM, Thom Brown wrote:
>>
>> So will this be revived any time soon? Were there any subsequent
>> proposals which were posted?
>>
>
> there was an updated patch, you can find in this thread:
> http://archives.postg
Thomas Munro writes:
> I am a long time user and fan of PostgreSQL and have built various
> projects large and small on every major release since 6.5. Recently
> I decided to try doing something more with the source than just
> compiling it, and spent some time 'constifying' some parts of the cod
On 9 November 2011 15:15, Robert Haas wrote:
> On Wed, Nov 9, 2011 at 9:35 AM, Jaime Casanova wrote:
>> On Wed, Nov 9, 2011 at 8:26 AM, Thom Brown wrote:
>>>
>>> So will this be revived any time soon? Were there any subsequent
>>> proposals which were posted?
>>>
>>
>> there was an updated patc
2011/11/9 Emanuel Calvo :
> Hi guys,
>
> I was thinking that could be great to add a column in \dx showing the
> available
> options for each foreign data wrapper.
>
> Seems reasonable?
>
Sorry the spam guys,
it necesary the sme for index collations. They appear in "\d+ table"
but with "\di+"
it
Robert Haas writes:
> On Wed, Nov 9, 2011 at 9:54 AM, Tom Lane wrote:
>> I would think you need to drop the now-useless lock, and I sure hope
>> that RangeVarGetRelid does likewise.
> It doesn't currently. The now-useless lock doesn't really hurt
> anything, aside from taking up space in the lo
Tom Lane wrote:
>> Perhaps there should be a few more 'XXX_const' accessor function
>> variants, for example list_nth_const,
>
> This is exactly what was bothering Robert and me about Peter's
> patch.If you go down this road you soon start needing duplicate
> functions for no other reason than t
Peter Geoghegan writes:
> On 9 November 2011 15:24, Tom Lane wrote:.
>> If you go down this road you soon start needing duplicate functions
>> for no other reason than that one takes/returns "const" and one doesn't.
> Why would you have to do that?
list_nth is an example. Now admittedly you ca
2011/11/9 Robert Haas :
> On Wed, Nov 9, 2011 at 8:37 AM, Cédric Villemain
> wrote:
>> Maybe I miss something but:
I read that the error was produced by first session and didn't check
carefuly (it fails silently in 9.0! and 'works' as expected in 9.1)
No objection, but I would like to still be a
"Kevin Grittner" writes:
> Tom Lane wrote:
>> This is exactly what was bothering Robert and me about Peter's
>> patch.If you go down this road you soon start needing duplicate
>> functions for no other reason than that one takes/returns "const"
>> and one doesn't.
> What about existing function
On Wed, Nov 9, 2011 at 10:45 AM, Kevin Grittner
wrote:
> Tom Lane wrote:
>>> Perhaps there should be a few more 'XXX_const' accessor function
>>> variants, for example list_nth_const,
>>
>> This is exactly what was bothering Robert and me about Peter's
>> patch.If you go down this road you soon
> > Yeah thanks, that does the object locking. For pre-9.1 versions, we will
> > need a similar solution. I encountered the issue on 8.3.x..
>
> I don't think we should back-patch a fix of this type. There is a lot
> of cruftiness of this type scattered throughout the code base, and if
> we start
On Wed, Nov 9, 2011 at 10:33 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Nov 9, 2011 at 9:54 AM, Tom Lane wrote:
>>> I would think you need to drop the now-useless lock, and I sure hope
>>> that RangeVarGetRelid does likewise.
>
>> It doesn't currently. The now-useless lock doesn't rea
hi,
how about making heap_form_tuple and its variants use smaller natts for
tuples whose trailing columns are NULL? depending on the schema, it can
save considerable space.
the most of code are ready to deal with such tuples for ALTER TABLE ADD
COLUMN anyway. (except system catalogs?)
YAMAMOTO
hi,
> I've been playing with the attached patch, which adds an additional
> light-weight lock mode, LW_SHARED2. LW_SHARED2 conflicts with
> LW_SHARED and LW_EXCLUSIVE, but not with itself. The patch changes
> ProcArrayEndTransaction() to use this new mode. IOW, multiple
> processes can commit a
On 9 November 2011 15:24, Tom Lane wrote:.
> If you go down this road you soon start needing duplicate functions
> for no other reason than that one takes/returns "const" and one doesn't.
Why would you have to do that?
To my mind, the fact that const "spreads" is a feature, not a deficiency.
-
This commit adds a new warning on my machine:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d326d9e8ea1d690cf6d968000efaa5121206d231
copy.c: In function *DoCopy*:
copy.c:1861:14: warning: *bufferedTuples* may be used uninitialized
in this function
-Kevin
--
Sent via pgsq
On Wed, Nov 9, 2011 at 10:50 AM, Cédric Villemain
wrote:
> 2011/11/9 Robert Haas :
>> On Wed, Nov 9, 2011 at 8:37 AM, Cédric Villemain
>> wrote:
>>> Maybe I miss something but:
>
> I read that the error was produced by first session and didn't check
> carefuly (it fails silently in 9.0! and 'work
On Wed, Nov 9, 2011 at 11:12 AM, Kevin Grittner
wrote:
> This commit adds a new warning on my machine:
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d326d9e8ea1d690cf6d968000efaa5121206d231
>
> copy.c: In function *DoCopy*:
> copy.c:1861:14: warning: *bufferedTuples* may be
We still seem to have some dependency issues with parallel builds. I
just got this on a fresh F16 box against git tip, when running "make -j 3":
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-sec
Robert Haas wrote:
> My feeling is that there's no harm (and possibly some benefit) in
> const-ifying functions that do very simple things. But as soon as
> you get to functions where the const-ness starts growing all over
> the system like kudzu, it's time to run away screaming.
The patch at
Andrew Dunstan writes:
> We still seem to have some dependency issues with parallel builds. I
> just got this on a fresh F16 box against git tip, when running "make -j 3":
> ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels
> -Wm
On Tue, Nov 8, 2011 at 7:19 PM, Greg Smith wrote:
> On 11/08/2011 05:07 PM, Robert Treat wrote:
>>
>> It's already easy to get "good enough" numbers based on user space
>> tools with very little overhead, so I think it's more important that
>> the server side tool be accurate rather than fast.
>
>
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
> how about making heap_form_tuple and its variants use smaller natts for
> tuples whose trailing columns are NULL?
This idea has been proposed before, and rejected on the basis that it's
unlikely to save enough to be worth the cycles needed to che
On 11/09/2011 11:35 AM, Tom Lane wrote:
Andrew Dunstan writes:
We still seem to have some dependency issues with parallel builds. I
just got this on a fresh F16 box against git tip, when running "make -j 3":
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-aft
Rebased with head.
--
With best regards,
Alexander Korotkov.
arrayanalyze-0.7.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.org/mailpref/pgsql-hackers
On Wed, Nov 9, 2011 at 11:28 AM, Kevin Grittner
wrote:
>> The kicker is that it's a lot of work for an unbelievably tiny
>> benefit, sometimes a negative benefit.
>
> Assuming duplicate declarations with and without const are off the
> table, where do you see the negative?
If it doesn't uglify th
On Wed, Nov 9, 2011 at 11:46 AM, Andrew Dunstan wrote:
> On 11/09/2011 11:35 AM, Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>>
>>> We still seem to have some dependency issues with parallel builds. I
>>> just got this on a fresh F16 box against git tip, when running "make -j
>>> 3":
>>> cc
On Wed, Nov 9, 2011 at 7:57 AM, Emanuel Calvo wrote:
> I was thinking that could be great to add a column in \dx showing the
> available
> options for each foreign data wrapper.
>
> Seems reasonable?
\dx doesn't list foreign data wrappers.
\dew+ lists the actual options supplied to a foreign da
On Tue, Nov 8, 2011 at 4:49 PM, Thom Brown wrote:
> I found the following error message misleading:
>
> test=# create table cows2 (LIKE cows);
> ERROR: inherited relation "cows" is not a table
> STATEMENT: create table cows2 (LIKE cows);
>
> I'm not trying to inherit a relation, I'm trying to ba
2011/11/9 Robert Haas :
> On Wed, Nov 9, 2011 at 7:57 AM, Emanuel Calvo wrote:
>> I was thinking that could be great to add a column in \dx showing the
>> available
>> options for each foreign data wrapper.
>>
>> Seems reasonable?
>
> \dx doesn't list foreign data wrappers.
>
I was confused, for
Robert Haas writes:
>> On 11/09/2011 11:35 AM, Tom Lane wrote:
>>> I think you have a broken version of "make". ecpg/preproc/Makefile
>>> is perfectly clear that parser.o depends on preproc.h.
> Either make 3.82 is broken, or there's something about it's behavior
> we don't understand. We've ha
On Wednesday, November 9, 2011, Albe Laurenz wrote:
> Christopher Browne wrote:
> >> I think that JDBC and Npgsql should also support disabling
> compression.
> >
> > That's the *real* problem here...
> >
> > You're quite right that if we allow controlling this on the libpq
> > side, it is surely
On 9 Nov 2011, at 05:06, Magnus Hagander wrote:
> I definitely think they are important enough to trigger a release. But as you
> say, I think we need confirmation that they actually fix the problem...
>
Would you consider it a blocker for a rollout on production system ?
> I definitely think they are important enough to trigger a release. But as
> you say, I think we need confirmation that they actually fix the problem...
Just last night Heroku was offering to help us test replication stuff.
I'll take them up on it.
Link for the patch and issue in question?
--
On 9 Nov 2011, at 16:16, Robert Haas wrote:
> On Wed, Nov 9, 2011 at 11:12 AM, Kevin Grittner
> wrote:
>> This commit adds a new warning on my machine:
>>
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d326d9e8ea1d690cf6d968000efaa5121206d231
>>
>> copy.c: In function *Do
On 9 Nov 2011, at 15:33, Peter Geoghegan wrote:
> On 9 November 2011 15:24, Tom Lane wrote:.
>> If you go down this road you soon start needing duplicate functions
>> for no other reason than that one takes/returns "const" and one doesn't.
>
> Why would you have to do that?
>
> To my mind, the
On 11/09/2011 01:12 PM, Greg Jaskiewicz wrote:
Would you consider it a blocker for a rollout on production system ?
I wouldn't. Good process for checking your backups should find this
problem if it pops up, and it's not that easy to run into. That's why I
was saying there are workarounds he
On 09.11.2011 15:25, Simon Riggs wrote:
On Wed, Nov 9, 2011 at 9:06 AM, Heikki Linnakangas
wrote:
In COPY, insert tuples to the heap in batches.
This greatly reduces the WAL volume, especially when the table is narrow.
The overhead of locking the heap page is also reduced. Reduced WAL traffic
Hi,
The task in $subject is something I will have to do repeatedly for
completing the Command Trigger patch. I've been doing some of them
manually, covering initdb. Then I've been scripting away the editing.
The script takes a Node number as input (because that's what you're
given in ERROR mess
Robert Haas writes:
> e.g. Suppose that you have a table with a unique index on column a.
> Transaction A deletes the tuple where a = 1. Transaction B attempts to
That's DML, I agree with you there, no need. In DML we have MVCC.
Back to the problem you raised, it's DDL and we're sitting in betw
On Wed, Nov 9, 2011 at 2:35 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> If it doesn't uglify the code, there aren't any negatives. I'm
>> just saying we may not be able to get very far before we run up
>> against that issue. For example, in the OP, Thomas wrote:
>>
>> 7. I made a list_
On Wed, Nov 9, 2011 at 3:40 PM, Dimitri Fontaine wrote:
> Back to the problem you raised, it's DDL and we're sitting in between
> SnapshotNow and catalog cache entries. Not so comfy. I would guess
> that the problem (I confess didn't read carefully enough) happens after
> having done a cache loo
Thom Brown writes:
> Whenever I cross the topic of
> partitioning in PostgreSQL, it's always a tad embarrassing to explain
> that it's still hacky compared to other database systems (and this
> came up again last week), so this is of particular interest to me. At
The more I think about this prob
On Wed, Nov 9, 2011 at 12:58 PM, Daniel Farina wrote:
> On Tue, Nov 8, 2011 at 9:06 PM, Magnus Hagander wrote:
>> I definitely think they are important enough to trigger a release. But as
>> you say, I think we need confirmation that they actually fix the problem...
>
> I have confirmed that the
Hello,
I'm a new programmer in postgreSQL source code..
Is possible use MPI functions in postgreSQL source code?
Help me please!
Best Regards.
Rudyar.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
On Wed, Nov 9, 2011 at 3:46 PM, Simon Riggs wrote:
> Holding buffer pins for a long time is a problem in Hot Standby also,
> not just vacuum.
Agreed.
> AFAIK seq scans already work page at a time for normal tables. So the
> issue is when we *aren't* using a seq scan, e.g. nested loops joins.
>
>
On Tue, Nov 8, 2011 at 3:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs wrote:
>>> I think we need to avoid long pin hold times generally.
>
>> In the case of a suspended sequential scan, which is the case where
>> this has most recently bitten me on
Robert Haas wrote:
> So what happens when someone wants to use list_nth in one of the
> outfuncs? Would we then rip all these back out?
If we just go this far and don't create a separate const flavor of
the one function and two macros, then we would at least need to rip
out the const keyword
On Tue, Nov 8, 2011 at 9:06 PM, Magnus Hagander wrote:
> I definitely think they are important enough to trigger a release. But as
> you say, I think we need confirmation that they actually fix the problem...
I have confirmed that the clog/subtrans fixes allow us to start up
while in hot standby
"Kevin Grittner" writes:
> If people aren't inclined to support this on the grounds of API
> clarity, maybe we should do some sort of benchmark run while we have
> a patch which applies cleanly before writing off the possible
> performance impact, but I'm not sure what makes a good stress-test
> f
On Wed, Nov 9, 2011 at 9:12 PM, Robert Haas wrote:
> Well, I'm not sure of the details of how page-at-a-time mode works for
> seq scans, but I am absolutely 100% sure that you can reproduce this
> problem using a cursor over a sequential scan. Just do this:
>
> create table test (a text);
> inse
Tom Lane wrote:
> I don't doubt that just duplicating macros and inlineable
> functions is a wash performance-wise (in fact, in principle it
> shouldn't change the generated code at all).
I had the impression that compilers these days could sometimes
better optimize across calls to functions w
On 9 November 2011 21:05, Dimitri Fontaine wrote:
> Thom Brown writes:
>> Whenever I cross the topic of
>> partitioning in PostgreSQL, it's always a tad embarrassing to explain
>> that it's still hacky compared to other database systems (and this
>> came up again last week), so this is of particu
On Wed, Nov 9, 2011 at 9:48 PM, simon wrote:
> On Wed, Nov 9, 2011 at 9:12 PM, Robert Haas wrote:
>
>> Well, I'm not sure of the details of how page-at-a-time mode works for
>> seq scans, but I am absolutely 100% sure that you can reproduce this
>> problem using a cursor over a sequential scan.
"Kevin Grittner" writes:
>> In C, the impedance match is a lot worse, so you have to pick and
>> choose where const is worth the trouble.
>
> Agreed. And I'm not sure how much of what Thomas is proposing is
> worth it; it just seems prudent to consider it while the offer is
> being made to do t
More than a year ago, I wrote in
http://archives.postgresql.org/message-id/14624.1283463...@sss.pgh.pa.us
> Awhile back I ranted about replacing the planner's concept of inner
> indexscans with a more generalized notion of "parameterized paths":
> http://archives.postgresql.org/pgsql-hackers/2009-
Robert Haas writes:
> As for what to do about all this, I think Tom's idea would work for
> good tuples, but the current freezing code can't handle dead tuples;
> it counts on those having been already removed.
I have not gone back to look at the code, but are you worried about the
fact that it d
Simon Riggs writes:
> heapgetpage() gets a page and a pin, but holds the pin until it reads
> the next page. Wow!
> That is both annoying and very dumb. It should hold the pin long
> enough to copy the data and then release the pin.
I don't find that anywhere near as obvious as you seem to. I t
On 11/09/2011 03:58 PM, Daniel Farina wrote:
On Tue, Nov 8, 2011 at 9:06 PM, Magnus Hagander wrote:
I definitely think they are important enough to trigger a release. But as
you say, I think we need confirmation that they actually fix the problem...
I have confirmed that the clog/sub
On Nov9, 2011, at 22:38 , Tom Lane wrote:
> I think that "const" works materially better in C++ where you can
> overload foo(struct *) and foo(const struct *) and let the compiler sort
> out which is being called. In C, the impedance match is a lot worse,
> so you have to pick and choose where con
Magnus Hagander writes:
> On Wednesday, November 9, 2011, Albe Laurenz wrote:
>> Is the following proposal acceptable:
>>
>> - Add a GUC ssl_compression, defaulting to "on".
>> - Add a client option "sslcompression" and an environment variable
>> PGSSLCOMPRESSION, defaulting to "1".
> Seems like
Thomas Munro wrote:
> There is another option: if list_head is changed to take a pointer
> to const List and return a pointer to non-const ListCell
> (something I was trying to avoid before), then no XXX_const
> functions/macros are necessary, and all of the functions from the
> first patch can
On Nov9, 2011, at 22:54 , Kevin Grittner wrote:
> Tom Lane wrote:
>
>> I don't doubt that just duplicating macros and inlineable
>> functions is a wash performance-wise (in fact, in principle it
>> shouldn't change the generated code at all).
>
> I had the impression that compilers these days co
On 11/09/2011 04:05 PM, Dimitri Fontaine wrote:
The more I think about this problem, the more I think that the reason
why we still don't have declarative partitioning is that it basically
sucks.
I think that we don't have it because no one has ever dumped the much
larger than might be expected
Florian Pflug writes:
> If we're concerned about helping the compiler produce better code,
> I think we should try to make our code safe under strict aliasing
> rules. AFAIK, that generally helps much more than const-correctness.
> (Dunno how feasible that is, though)
The last time we talked abou
On Wed, Nov 9, 2011 at 2:24 PM, Greg Smith wrote:
> I think Daniel has run into this problem more than anyone else, so hearing
> it's fixed for him makes me feel a lot better that it's been resolved. I'd
> characterize this problem as a medium grade data corruption issue. It's not
> security iss
We have a cluster running 9.1.1 where pg_dump hangs when we try to dump
some a database inside of the cluster. The server is running AIX.
I can see this on clean cluster where we do an initdb, followed by a
createdb and try running pg_dump.
I've tracked the issue down to collectSecLabels in
"Kevin Grittner" writes:
> Thomas Munro wrote:
>> There is another option: if list_head is changed to take a pointer
>> to const List and return a pointer to non-const ListCell
>> (something I was trying to avoid before), then no XXX_const
>> functions/macros are necessary, and all of the functio
On Wed, Nov 9, 2011 at 10:20 PM, Tom Lane wrote:
> Simon Riggs writes:
>> heapgetpage() gets a page and a pin, but holds the pin until it reads
>> the next page. Wow!
>
>> That is both annoying and very dumb. It should hold the pin long
>> enough to copy the data and then release the pin.
>
> I d
On 11/09/2011 04:10 PM, Rudyar Cortés wrote:
I'm a new programmer in postgreSQL source code..
Is possible use MPI functions in postgreSQL source code?
To do this the proper way, you would need to modify the database's
"configure" step to:
-Check if the OpenMPI libraries are available and inc
Steve Singer writes:
> I've tracked the issue down to collectSecLabels in pg_dump.c
> SELECT label, provider, classoid, objoid, objsbid FROM
> pg_catalog.pg_seclabel;
> returns 0 rows.
> The code in collectSecLabels() is not prepared to deal with a zero row
> result and tries to malloc 0 byte
> Hi,
> when I insert/update many rows at once using INSERT ... SELECT into a
> table which has plenty of CHECK constraints, the error message that
> Postgres returns has no indication of which row failed the constraint
> check. The attached patch tries to provide information in a similar way
> to
Tom Lane wrote:
> In general I don't have an objection to adding "const" to
> individual routines, so long as it doesn't create propagating
> requirements to const-ify other code. This may be the only way to
> do it.
As I understand it (although I'm no C expert), a "const" qualifier
on a func
> So that's my take on it. It's not a "tomorrow" severity release
> (we've been living with the workaround for months, even though it is
> blocking some things), but I would really appreciate an expedited
> release to enable unattended hot-standby operation and to avoid
> scaring those who encoun
On Wed, Nov 9, 2011 at 1:05 PM, Dimitri Fontaine wrote:
> Thom Brown writes:
>> Whenever I cross the topic of
>> partitioning in PostgreSQL, it's always a tad embarrassing to explain
>> that it's still hacky compared to other database systems (and this
>> came up again last week), so this is of p
On Nov9, 2011, at 23:53 , Daniel Farina wrote:
> I think a novice user would be scared half to death: I know I was the
> first time. That's not a great impression for the project to leave
> for what is not, at its root, a vast defect, and the fact it's
> occurring for people when they use rsync ra
On 11/09/2011 03:56 PM, Josh Berkus wrote:
So that's my take on it. It's not a "tomorrow" severity release
(we've been living with the workaround for months, even though it is
blocking some things), but I would really appreciate an expedited
release to enable unattended hot-standby operation
> Ehhh That week is kind of moot for most of the United States.
> Shouldn't it be like Tuesday the week after?
Given that we start packaging on Thursday, that would mean waiting an
additional 2 weeks.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers ma
On Wed, Nov 9, 2011 at 5:12 PM, Tom Lane wrote:
> More than a year ago, I wrote in
> http://archives.postgresql.org/message-id/14624.1283463...@sss.pgh.pa.us
>
>> Awhile back I ranted about replacing the planner's concept of inner
>> indexscans with a more generalized notion of "parameterized path
On Wed, Nov 9, 2011 at 5:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> As for what to do about all this, I think Tom's idea would work for
>> good tuples, but the current freezing code can't handle dead tuples;
>> it counts on those having been already removed.
>
> I have not gone back to look
On Wed, Nov 9, 2011 at 6:10 PM, Simon Riggs wrote:
> On Wed, Nov 9, 2011 at 10:20 PM, Tom Lane wrote:
>> Simon Riggs writes:
>>> heapgetpage() gets a page and a pin, but holds the pin until it reads
>>> the next page. Wow!
>>
>>> That is both annoying and very dumb. It should hold the pin long
>
On Wed, Nov 9, 2011 at 9:03 PM, Josh Berkus wrote:
>> Ehhh That week is kind of moot for most of the United States.
>> Shouldn't it be like Tuesday the week after?
>
> Given that we start packaging on Thursday, that would mean waiting an
> additional 2 weeks.
Yeah, I don't see what's wrong wi
1 - 100 of 109 matches
Mail list logo
