Robert Haas writes:
> On Wed, Nov 9, 2011 at 9:03 PM, Josh Berkus wrote:
>> Given that we start packaging on Thursday, that would mean waiting an
>> additional 2 weeks.
> Yeah, I don't see what's wrong with the 21st.
One advantage of waiting two more weeks is that we could declare it to
be the
Florian Pflug wrote:
> On Oct27, 2011, at 23:02 , Bruce Momjian wrote:
> > Florian Pflug wrote:
> >> On Oct21, 2011, at 16:42 , Phil Sorber wrote:
> >>> If you did want to make them immutable, I also like Florian's idea of
> >>> a dependency graph. This would make the dumps less readable though.
>
[Sorry for not CC'ing the list before, I'm still getting used to the
new Gmail interface]
On Tue, Nov 8, 2011 at 11:05 PM, Josh Kupershmidt wrote:
> On Tue, Nov 8, 2011 at 10:04 PM, Tom Lane wrote:
>> Josh Kupershmidt writes:
>>> We're essentially pretending that we support all server versions
2011/11/9 José Arthur Benetasso Villanova :
> postgres=# create table test1(id serial primary key, value text);
> NOTICE: CREATE TABLE will create implicit sequence "test1_id_seq" for
> serial column "test1.id"
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "test1_pkey" for tab
On 11/09/2011 06:15 PM, Robert Haas wrote:
2011/11/9 Devrim GÜNDÜZ:
On Wed, 2011-11-09 at 21:12 -0500, Robert Haas wrote:
The point is that all the packaging will be done *before* people leave
to go eat Turkey.
Eating me?
:-)
No, just your country.
I hear it is a little dry.
--
Comma
On Wed, Nov 09, 2011 at 05:26:14PM -0500, Tom Lane wrote:
> 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 envi
On Wed, Nov 9, 2011 at 12:31 PM, Emanuel Calvo wrote:
>> \dew+ lists the actual options supplied to a foreign data wrapper already.
>
> Checked, but the options doesn't appear (the column exists, but is empty).
Well, that just means that you didn't specify any options when you ran
CREATE FOREIGN
2011/11/9 Devrim GÜNDÜZ :
> On Wed, 2011-11-09 at 21:12 -0500, Robert Haas wrote:
>> The point is that all the packaging will be done *before* people leave
>> to go eat Turkey.
>
> Eating me?
:-)
No, just your country.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Post
On Wed, 2011-11-09 at 21:12 -0500, Robert Haas wrote:
> The point is that all the packaging will be done *before* people leave
> to go eat Turkey.
Eating me?
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certifie
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
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 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 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
> 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 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
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 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
> 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
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
> 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
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
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
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
"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
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
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
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 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
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
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
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
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
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
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
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
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-
"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
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.
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
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 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
"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 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
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 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
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.
>
>
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 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
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 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
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_
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
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
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
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 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 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
> 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 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 ?
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
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
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
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
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 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 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
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 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
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 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.
>
>
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
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
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
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
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
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 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.
-
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
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
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
> > 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: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
"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
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
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
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
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
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
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
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 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
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: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
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
> > 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
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
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 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
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 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,
1 - 100 of 109 matches
Mail list logo
