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: rel
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
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 m
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 vi
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 ar
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
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
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
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_OFFSET a pointer to an address which
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
> will
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
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 acquir
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
-
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
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
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 comp
> -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 aga
-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 ("Post
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 (?) or
for some reasonable size. There are better was to do this, of course...
Gavin
---
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
lea
>
> 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
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:
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, wit
"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 for
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 PR
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 pre
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 mo
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 to
Tom Lane wrote:
(B>
(B> > I think such compatibility is sufficient. We can mention in the
(B> > releases notes that they should upgrade there servers before their
(B> > clients.
(B>
(B> I'd be really happy if we can make that stick. There's enough work to
(B> be done here without trying
> > 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 woul
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
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 ta
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 c
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 th
34 matches
Mail list logo
