On 4/13/11 5:46 AM, Heikki Linnakangas wrote:
> On 13.04.2011 14:22, Andrew Dunstan wrote:
>> I wish we could get some buildfarm coverage for HPUX. I've whined about
>> this in the past, but nobody's ever made an offer to provide suitable
>> platform(s) that I know of.
>
> I only have temporary ac
I wish we could get some buildfarm coverage for HPUX. I've whined about this in
the past, but nobody's ever made an offer to provide suitable platform(s) that I
know of.
cheers
I've got two HP-UX 11 boxes, PA-RISC and IA64.
From uname:
HP-UX B.11.23 U 9000/785
HP-UX B.11.23 U ia64
They ar
Robert Haas writes:
> If we adopt the elsewhere-proposed approach of forbidding the use of
> rowtypes to create typed tables, the circularity-checking logic here
> can become simpler. I think it's not actually water-tight right now:
> rhaas=# create table a (x int);
> CREATE TABLE
> rhaas=# crea
"A.M." writes:
> 1. As long one keeps SysV shared memory around, the postgresql project
> has to maintain the annoying platform-specific document on how to
> configure the poorly named kernel parameters.
No, if it's just a small area, I don't see that that's an issue.
You're going to max out on o
On Fri, Apr 8, 2011 at 5:12 PM, Noah Misch wrote:
> Implemented as attached. The first patch just adds the ALTER TABLE
> subcommands
> to attach and detach a table from a composite type. A few open questions
> concerning typed tables will probably yield minor changes to these
> subcommands.
>
On Sat, Apr 9, 2011 at 6:57 PM, Noah Misch wrote:
> While looking at the typed table/pg_upgrade problem, I ran into a few smaller
> problems in the area. I'm not envisioning a need for much code shift to fix
> them, but there are a few points of policy.
>
> * Table row types used in typed tables
On Mon, Apr 11, 2011 at 1:39 PM, Зотов Роман wrote:
> 11.04.2011 5:19, Robert Haas пишет:
>>
>> You only sent this to me, I think; I assume you meant to copy the list.
>>
>> ...Robert
>>
>> On Mar 16, 2011, at 12:46 AM, Zotov wrote:
>
> I send full patch, prev patch could be not so full, because
On Wed, Apr 13, 2011 at 6:11 PM, A.M. wrote:
>> I don't see why we need to get rid of SysV shared memory; needing less
>> of it seems just as good.
>
> 1. As long one keeps SysV shared memory around, the postgresql project has to
> maintain the annoying platform-specific document on how to config
On Sun, Apr 10, 2011 at 5:23 AM, Noah Misch wrote:
> On Sun, Apr 10, 2011 at 07:35:53AM -0400, Robert Haas wrote:
>> On Sun, Apr 10, 2011 at 6:36 AM, Noah Misch wrote:
>> > 3. Make AlterTableCreateToastTable acquire only ShareUpdateExclusiveLock
>> > and
>> > remove the pass-usage heuristic from
On Apr 13, 2011, at 8:36 PM, Robert Haas wrote:
>
> I don't see why we need to get rid of SysV shared memory; needing less
> of it seems just as good.
1. As long one keeps SysV shared memory around, the postgresql project has to
maintain the annoying platform-specific document on how to configu
Robert Haas writes:
> In answer to your off-list question, one of the principle ways I've
> seen fcntl() locking fall over and die is when someone removes the
> lock file. You might think that this could be avoided by picking
> something important like pg_control as the log file, but it turns out
On Wed, Apr 13, 2011 at 7:20 AM, A.M. wrote:
> The goal of this patch is to eliminate SysV shared memory, not to implement
> NFS-capable locking which, as you point out, is virtually impossible.
>
> As far as I can tell, in the worst case, my patch does not change how
> postgresql handles the NF
On Wed, 13 Apr 2011 10:45:25 +0200, Magnus Hagander
wrote:
So per your experience, all we really need to do is to define what the
*max* level of the Windows SDK we can use is, to make sure people
don't get the VS2010 compiler instead?
(And adding the note that VS2010 isn't supported with or wi
Peter Eisentraut writes:
> pg_regress supports a --multibyte option, which can also be invoked
> using the MULTIBYTE make variable when you run make check. I think this
> is fairly unknown, but we are now documenting it as part of how to run
> the collation regression tests. I think it would als
An off-list discussion with Leo Carson of SDSC led to the following
test case, which reproducibly crashes 8.4:
-- do this in the regression database, or use some other base table
create or replace view vv as
select a.unique1, b.unique2, c.tenthous, 'label'::text as lab
from tenk1 a
left join tenk1
On Tue, Apr 12, 2011 at 4:14 PM, Andres Freund wrote:
> Also add some regression tests for that behaviour.
>
> Found after seing a report about it in IRC by Daniel Grace.
This patch didn't apply cleanly for me, but I committed the basic fix.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.
pg_regress supports a --multibyte option, which can also be invoked
using the MULTIBYTE make variable when you run make check. I think this
is fairly unknown, but we are now documenting it as part of how to run
the collation regression tests. I think it would also be useful in the
PL/Python regre
The attached patches fixes a pg_upgrade crash in 9.0 caused by a new
cluster database that doesn't exist in the old cluster; instead throw
an error. This was reported to me by EnterpriseDB testing staff. This
bug does not exist in git head.
--
Bruce Momjian http://momjian.us
Enter
On Apr 13, 2011, at 2:06 AM, Tom Lane wrote:
> "A.M." writes:
>> On Apr 11, 2011, at 7:13 PM, Tom Lane wrote:
>>> Robert Haas writes:
I mean I'm not convinced that fcntl() locking will be as reliable.
>
>>> I'm not either. Particularly not on NFS.
>
>> Is there an example of a recent sy
On 13.04.2011 14:22, Andrew Dunstan wrote:
I wish we could get some buildfarm coverage for HPUX. I've whined about
this in the past, but nobody's ever made an offer to provide suitable
platform(s) that I know of.
I only have temporary access to this HPUX box, but I'm trying to arrange
that.
On 04/13/2011 05:12 AM, Heikki Linnakangas wrote:
The code we added recently to the stack-depth check to also check the
register stack on ia64 doesn't compile on HP-UX B.11.31, using the HP
aCC compiler:
cc -Ae +O2 -g -I../../../src/include -D_XOPEN_SOURCE_EXTENDED -c -o
postgres.o postgr
The code we added recently to the stack-depth check to also check the
register stack on ia64 doesn't compile on HP-UX B.11.31, using the HP
aCC compiler:
cc -Ae +O2 -g -I../../../src/include -D_XOPEN_SOURCE_EXTENDED -c -o
postgres.o postgres.c
"postgres.c", line 3002: warning #2837-D: omiss
On Tue, Apr 12, 2011 at 22:36, Brar Piening wrote:
> On Tue, 12 Apr 2011 08:51:57 -0400, Andrew Dunstan
> wrote:
>>>
>>> that's in the SDK? If not, I still think that should be our primary
>>> option - I certainly don't see how it's obsolete. (and you can,
>>> afaics, still get the platform sdk w
On Tuesday 12 April 2011 01.02:35 Lucas Cotta wrote:
> Does postgre execute the queries following a execution plan tree, where
> the leafs are table scans, and the nodes are joins?
yes, see the "EXPLAIN" SQL command (EXPLAIN SELECT * FROM ), it will
shwo this tree.
http://www.postgresql.org/
24 matches
Mail list logo
