Maybe this is related to the thread [HACKERS] regression failure in CVS
HEAD
I've installed postgresql-7.3.2 on HP-UX yesterday.
When running 'gmake -C regress check'
the process does not return.
File ./src/test/regress/regression.out shows
parallel group (13 tests): float8 int2 varchar text
X and Y? Well, the first thing that comes to mind is SSL
support. I'm
not sure if it's still that way, but at least it used to be
a pretty
ugly kludge there with the connection being dropped and
re-connected
in some cases.
SSL support is a bad example, since it would have to be
I agree, let's not wait for specific features. The issue was whether we
had enough significant features done for a release --- I didn't think we
did, so I am saying, let's get more features, rather than let's get
feature X.
As we fill in missing features, there will be less must-have features
Justin Clift wrote:
confidentiality level of the Win32/PITR patches at present, but I'd
guess there would be at least a few solid volunteers willing to
contribute to the Win32/PITR ports if we asked for people to step
forwards.
I'd like to help. I've been following the list for several
Hiroshi Inoue [EMAIL PROTECTED] writes:
What the driver has suffered from is to get the
fields' info of a query result or the parameters'
info of a statement. The info is needed even before
the execution of the statement(i.e it's only prepared).
Hm. Are you saying that you would like PREPARE
Magnus Hagander [EMAIL PROTECTED] writes:
The general idea was to make a framework there to make it easier to add
something like that in the future. Something that came up when adding
the SSL negotiation - since that was very kludgy to do with the current
protocol. But again, if you foresee
If there's a build of this available we'd love to test it in a major project
we're working on. The project is currently using the 7.2 build that was made
available, but we had to work around the lack of schema support by kludging
table names as namespace_table, so a 7.3 build would be great, with
Christoph Haller [EMAIL PROTECTED] writes:
I've installed postgresql-7.3.2 on HP-UX yesterday.
When running 'gmake -C regress check'
the process does not return.
See doc/FAQ_HPUX:
: The parallel regression test script (gmake check) is known to lock up
: when run under HP's Bourne shells:
Christoph Haller [EMAIL PROTECTED] writes:
I've installed postgresql-7.3.2 on HP-UX yesterday.
When running 'gmake -C regress check'
the process does not return.
See doc/FAQ_HPUX:
: The parallel regression test script (gmake check) is known to lock
up
: when run under HP's Bourne
Sure, Neil Conway updated Jan's patches for 7.3. It is in:
ftp://candle.pha.pa.us/pub/postgresql/mypatches/
---
Merlin Moncure wrote:
Justin Clift wrote:
confidentiality level of the Win32/PITR patches at
Seems possible that Lynx timed out and generated and sh left only an
empty file.
Guard against this by writing the output of lynx to a temporary file and
either check it for stuff you expect to be there (!-- comments --?) or
for some reasonable size. There are better was to do this, of course...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As far as the problem of generating an empty index file, you could have
the buildpage() function redirect the lynx output to a temporary file
($1.temp) and check that file for validity somehow (i.e. non-zero size
or grep for a known string
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Well, what would constitute a complete spec? I think I've told the group
what I would like to be able to do, what unanswered questions can I
(hopefully :-) ) answer?
I'm still unclear on exactly what your needs are. In the first place,
On Tue, Mar 11, 2003 at 10:40:08PM -, [EMAIL PROTECTED] wrote:
As far as the problem of generating an empty index file, you could have
the buildpage() function redirect the lynx output to a temporary file
($1.temp) and check that file for validity somehow (i.e. non-zero size
or grep
I have a customer porting an application from informix to postgres. They
require 2 things:
1) Cursors outside of transactions.
2) For update cursors as well as where current of
If anyone is interested in this work, please reply off list.
--
Dave Cramer [EMAIL PROTECTED]
Cramer Consulting
The way I understand it, grantMask in the LOCK struct (file Lock.h) could help us find out all the lock types already granted for an object associated with the LOCKTAG.
How do we do the bit manipulation to 'separate' the mask to get to the different lock types associated with the object that
On Mon, 10 Mar 2003, Tom Lane wrote:
One of the $64 questions that has to be answered is how much work we're
willing to expend on backwards compatibility. The path of least
resistance would be to handle it the same way we've done protocol
revisions in the past: the backend will be able to
On Mon, 10 Mar 2003, Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
The scenario that's appealing to me the most is this for the next release:
PostgreSQL 8.0
+ Includes PITR and the Win32 port
If the folks doing those things can get done in time, great. I'm even
willing to push
How do we get the actual pgproc object from the
SHMEM_OFFSET proc /* link to pgproc of owning backend*/ in the PROCLOCKTAG struct in file Lock.h
The same question also for SHMEM_OFFSET lock /*link to per-lockable-object information*/ in the same struct
Is SHMEM_OFFSETa pointer to an address which
what are the different types of lock modes available for row-level locks?
I found a documentation on different types of lock modes available for table-level locks at
http://developer.postgresql.org/docs/postgres/explicit-locking.html
where is the documentation on different types of lock modes for
On Tue, 11 Mar 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 10 Mar 2003, Tom Lane wrote:
One of the $64 questions that has to be answered is how much work we're
willing to expend on backwards compatibility. The path of least
resistance would be to handle it the same
Marc G. Fournier wrote:
So, what should we do? Should we go another month or two and just wait
until we have enough must-have features? While not waiting on specific
features, it _is_ waiting for something to warrant a release. I guess
the big question is whether we release on a
Hi everyone,
Thinking about the numbering further.
Would it be cool to decide on the version numbering of our next release
like this:
+ If it looks like we'll have Win32 and/or PITR recovery in time for
the next release, we call it PostgreSQL 8.0
+ If not, we call it 7.4
Win32 and PITR
Justin Clift wrote:
Win32 and PITR are great big features that will take us a long way to
the goal of Enterprise suitability. They're worth making some specific
marketing/branding efforts about and making a big fuss, that why I'd
like to see them in an 8.0 release.
From a marketing point of
Paul Ramsey wrote:
Justin Clift wrote:
Win32 and PITR are great big features that will take us a long way to
the goal of Enterprise suitability. They're worth making some
specific marketing/branding efforts about and making a big fuss, that
why I'd like to see them in an 8.0 release.
From a
Kevin Brown [EMAIL PROTECTED] writes:
doing more or less what other database vendors have done in response
to these underspecified issues is probably a sensible course of action
when there's no other obviously better answer.
A good point, indeed. Who wants to do the legwork to check up on
Justin Clift [EMAIL PROTECTED] writes:
Would it be cool to decide on the version numbering of our next release
like this:
+ If it looks like we'll have Win32 and/or PITR recovery in time for
the next release, we call it PostgreSQL 8.0
+ If not, we call it 7.4
Works for me: release
-Original Message-
From: Gavin Sherry [mailto:[EMAIL PROTECTED]
Sent: 11 March 2003 22:38
To: Dave Page
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Website build script
Seems possible that Lynx timed out and generated and sh left
only an empty file.
Guard against this
After a long battle with technology,Partho Bhowmick [EMAIL PROTECTED], an
earthling, wrote:
Well, I am running kernel-2.4.18-26. What's the limit on this baby?
Sounds like you didn't read what I wrote. Which filesystem? Which
version of GLIBC? By the way, have your applications been compiled
It's rumoured that Tom Lane once said:
Dave Page [EMAIL PROTECTED] writes:
What about the addition of pg_attribute.attrelid
pg_attribute.attname/attnum in RowDesription messages to identify the
underlying attribute (where appropriate)?
Well, we can talk about it, but I still think that any
It's rumoured that Bruce Momjian once said:
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
What about the addition of pg_attribute.attrelid
pg_attribute.attname/attnum in RowDesription messages to identify
the underlying attribute (where appropriate)?
Well, we can talk about it,
It's rumoured that Bruce Momjian once said:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I was willing to add a hack to enable default column labels to be
table.column --- that seemed like the least obtrusive.
Most of the definitional issues still apply: which table name are you
Tom Lane wrote:
I think such compatibility is sufficient. We can mention in the
releases notes that they should upgrade there servers before their
clients.
I'd be really happy if we can make that stick. There's enough work to
be done here without trying to
Quoth Partho Bhowmick [EMAIL PROTECTED]:
I am working on extending the functionality of PostgreSQL on Linux.
I need to know what's the largest filesize for a single file that I can have
under Linux?
That depends.
It depends on the size supported by the filesystem. Usually that's at
least
34 matches
Mail list logo
