> Feels like we've been isolating a whole bunch of bugs in 7.3.2 recently,
> some of which are causing crashes out in the real world.
>
> Wondering when we feel it'd be good to start assembling a 7.3.3? I'm
> thinking in about two weeks or so, to give a bit more time to catch bugs
> and stuff.
I
Hi guys,
Feels like we've been isolating a whole bunch of bugs in 7.3.2 recently,
some of which are causing crashes out in the real world.
Wondering when we feel it'd be good to start assembling a 7.3.3? I'm
thinking in about two weeks or so, to give a bit more time to catch bugs
and stuff.
On Wed, 5 Mar 2003, Bruce Momjian wrote:
>
> Is this to be applied to CVS? My guess is no.
>
me too. I think we could submit new version after we'll have
documentation.
> ---
>
> Teodor Sigaev wrote:
> > Changes:
> > 1 Fix
Joe Conway <[EMAIL PROTECTED]> writes:
> Taking it a bit further...
There are (at least) two distinct problems involved here. One is
getting plpgsql to deal correctly with rowtypes that include dropped
columns. The other is getting it to react when someone alters a table
whose rowtype is relied
Rod Taylor <[EMAIL PROTECTED]> writes:
> [ optimizing for small frequent queries ]
What if the client doesn't come back with another query for awhile?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscri
* Merlin Moncure <[EMAIL PROTECTED]> [2003-03-05 10:03]:
> This is just about a total conversion of the backend to an xml document
> server. The marriage of xml and sql is awkward and not easily
> retrofitted to existing databases.
>
> Its pretty much proven that hierarchal storage techniques (xm
Christopher Kings-Lynne wrote:
I want to fix this bug, however I can't see how the example below is
failing... (Obeys dropped columns) I'm not up with my SRFs, so would
someone be able to post a concise SQL script that demonstrates the failure?
I can see in the code that it should be failing, but
It would be nice if PGAvd could receive row level stats without a large
hit to simple queries.
Ran a simple test. Calling pgstat_report_tabstat() at a frequency of
once per second reduces the time taken for row level stats to be
negligible:
500k select TRUE statements took:
6:50 with stats off
8
Christopher Kings-Lynne wrote:
I want to fix this bug, however I can't see how the example below is
failing... (Obeys dropped columns) I'm not up with my SRFs, so would
someone be able to post a concise SQL script that demonstrates the failure?
I can see in the code that it should be failing, but
Tatsuo Ishii wrote:
> Sorry, but it does not help. The page says we could use
> FlushFileBuffers() to sync the kernel buffer to the
> disk. Unfortunately, it requires a file descriptor to flush for its
> argument. Thus it could not be a replacement of sync(). Actually I
> have modified the buffer m
Marc G. Fournier wrote:
Justin put them up, but I believe that any bug reports for them should be
sent to [EMAIL PROTECTED] ...
Yep, that's the first "Proof of Concept" build, and it *prominently* has
a message at the start of the installation that says to email me with
any problems about it.
I'
mlw <[EMAIL PROTECTED]> writes:
> I had written a piece of code about two years ago that used the aggregate
> feature of PostgreSQL to create an array of integers from an aggregate, as:
>
> select int_array_aggregate( column ) from table group by column
I found this and am using it extensively.
* Merlin Moncure <[EMAIL PROTECTED]> [2003-03-05 10:02]:
> > Acually, the difficult part has been getting the information back
> > into the database. Getting it out is a very simple query. I imagine
> > that every language/environment has an SQL->XML library somewhere,
> > but I wasn't able to fin
Hi,
I tried to go buy a shirt off the pgsql.com site, but when it comes to
shipping it just has:
international shipping zone 1
international shipping zone 2
international shipping zone 3
international shipping zone 4
international shipping zone 5
How am I supposed to know which zone Australia is
FYI, my contract with SRA has been renewed for another year, meaning I
will continue the next year working on PostgreSQL full time.
I want to thank SRA for their support of the PostgreSQL effort by
employing me. As you may know, Tatsuo Ishii also works for SRA full
time and he is a great help t
Just a reminder on the purpose of the core group --- it is to handle
items that require confidentiality, like confidential discussions with
companies and for discipline.
Marc wants the core group to do as little as possible, so that almost
all activity is done in the open, and the other core group
Added to TODO:
> o Have ALTER TABLE rename SERIAL sequences
Seems we at least need this. Doesn't dependency tracking make this
easy to do now?
---
Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writ
I want to fix this bug, however I can't see how the example below is
failing... (Obeys dropped columns) I'm not up with my SRFs, so would
someone be able to post a concise SQL script that demonstrates the failure?
I can see in the code that it should be failing, but I need a demonstrated
example
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I also think that psql is not the place to implement something like this.
>
> Agreed.
>
> > It's most likely best put in the backend, as a function like
> > xmlfoo('select * from t1;')
> That seems a little bizarre. Wouldn't we want to have
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> I think we should stick with the existing naming convention.
^^
> Non-colliding?
No; see above.
> Otherwise, it'd be ludicrous to fail a table rename because
> a sequence with the
> I think we should stick with the existing naming convention. The only
> actual problem that's been pointed out here is that an ALTER TABLE
> (or COLUMN) RENAME on a serial column doesn't update the sequence name
> to match. Seems to me we could fix that with less effort than any of
> these solu
If it turns out to be that simple, great - my first goal would be not to
touch the backend at all. But I suspect there are some significant semantic
issues lurking in the spec that may make that goal unattainable. In any
event, I agree with the impulse to change nothing in the backend unless
absolu
Tom Lane wrote:
This is also a good time to stop and ask whether the frontend/backend
protocol needs to change to support this. Not having read the spec,
I have no idea what the low-level transport needs are for XML output,
but I suspect our present protocol is not it ...
It might be interesting t
> I like PostgreSQL just as it is, and truth be told, I'd like to see some
> additional features in PL/pgSQL that are completely unrelated to the whole
> XML issue. But I see some interesting possibilities for PostgreSQL to make
> inroads in enterprise development if it were the first open source d
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I also think that psql is not the place to implement something like this.
Agreed.
> It's most likely best put in the backend, as a function like
> xmlfoo('select * from t1;')
That seems a little bizarre. Wouldn't we want to have a switch that
j
Thanks for the link - I think I just may give it a go. :)
- Bob
%% -Original Message-
%% From: [EMAIL PROTECTED]
%% [mailto:[EMAIL PROTECTED] Behalf Of Peter Eisentraut
%% Sent: Wednesday, March 05, 2003 5:39 PM
%% To: Bob Calco
%% Cc: Merlin Moncure; Alan Gutierrez; [EMAIL PROTECTED]
%%
Thanks, Merlin, for your thoughtful comments. There is no question that the
marriage of XML and SQL is wrought with semantic difficulties. I'm not sure
the win is compelling enough to justify re-writing the PostgreSQL back end;
on the other hand, it is a juicy technical challenge!
I like PostgreSQ
Justin put them up, but I believe that any bug reports for them should be
sent to [EMAIL PROTECTED] ...
On Wed, 5 Mar 2003, Peter Eisentraut wrote:
> There are Windows binaries on the PostgreSQL FTP server mirrors, for
> example,
>
> http://ftp.de.postgresql.org/mirror/postgresql/binary/v7.3.1/W
There are Windows binaries on the PostgreSQL FTP server mirrors, for
example,
http://ftp.de.postgresql.org/mirror/postgresql/binary/v7.3.1/Windows/
that users are having problems with. Apparently there is no name or
address of any creator available. So who did this and would like to fix
the pac
Is this to be applied to CVS? My guess is no.
---
Teodor Sigaev wrote:
> Changes:
> 1 Fixed compile problem on Solaris
> 2 Add search by weight of lexem.
>
> Readme: http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/R
Bob Calco writes:
> I would like to see PostgreSQL eventually support XQuery:
The specification is here:
ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-14-XML-2002-03.txt
Go for it.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
Andrew Dunstan writes:
> One thing I have noticed about the schemes that are being advanced is that
> they seem to be inherently unspecifiable, formally, because column names are
> being used as tags.
The SQL/XML draft addresses this by specifying that a mapping from SQL
things to XML things spit
[EMAIL PROTECTED] writes:
> I think all psql needs is a simple output, similar to the ones used by
> Oracle, Sybase, and MySQL; the calling application should then process
> it in some way as needed (obviously this is not for interactive use).
> Where can one find a "standard table model?"
I thin
Rod Taylor <[EMAIL PROTECTED]> writes:
> 200N spec proposes 'NEXT VALUE FOR '.
> Tom will shoot me if I submit that though (VALUE as a keyword again). I
> suppose one could make it a variable, and confirm it's value is VALUE?
> Anyway, once again we could extend to include:
> NEXT VALUE ON table(
While I can see a subquery in UPDATE as working in most cases:
UPDATE tab
SET col - t.col
FROM (SELECT col from xx) AS t
WHERE ...
but I don't see that working for correlated subqueries, where you want
to set a column based on a value you are updating. (Many use
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Is the so-called debug TTY functionality that you can set in libpq in
> various ways still existing? I can't seem to activate it and the code
> doesn't show much reference to it.
(a) I believe the TTY option is disabled in the normal postmaster
conte
mlw wrote:
I had written a piece of code about two years ago that used the
aggregate feature of PostgreSQL to create an array of integers from an
aggregate, as:
select int_array_aggregate( column ) from table group by column
While it seems pointless to create an array on a select, it has a
pur
I am back from China and Japan. Most of my visitations were private,
but I did speak at Renmin University in China.
I will catch up on my email in the next few days.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If
I had written a piece of code about two years ago that used the
aggregate feature of PostgreSQL to create an array of integers from an
aggregate, as:
select int_array_aggregate( column ) from table group by column
While it seems pointless to create an array on a select, it has a
purpose in OLA
Yes, our sequence name/column linkage should be much more automatic than
it is now, and if we do that, we can start to think about sequence name
collision avoidance.
---
Rod Taylor wrote:
-- Start of PGP signed section.
> On
The idea of a RAM disk based database and reliable storage are in
complete opposition. Forget it.
The question is: What do you need the *raw* speed of a RAM disk for, and
what can you tollerate for overhead for reliability?
You have posed a question about how to implement a flawed solution, wha
On Wed, 2003-03-05 at 14:37, Bruce Momjian wrote:
> Interesting idea. The bigger problem is that apps who use the sequence
> name also would have problems running after the restore. Seems we need
> column.nextval() so you can increment the sequence without knowing the
> sequence name, just the co
Interesting idea. The bigger problem is that apps who use the sequence
name also would have problems running after the restore. Seems we need
column.nextval() so you can increment the sequence without knowing the
sequence name, just the column name. Of course, this related to this
TODO item:
Chris,
> The concern of course is if something happends to the RAM drive we are
> S.O.L. and have to go to the last backup (pg_dump happens each night).
This is the drawback to RAM drives, period. If there was some way to use a
RAM drive without risking your data, everyone would do it (or at l
Is the so-called debug TTY functionality that you can set in libpq in
various ways still existing? I can't seem to activate it and the code
doesn't show much reference to it.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6:
On Wed, 5 Mar 2003, Dave Page wrote:
>
>
> > -Original Message-
> > From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
> > Sent: 05 March 2003 02:23
> > To: [EMAIL PROTECTED]
> > Subject: [HACKERS] Win32 Powerfail testing
> >
> > So far we found interesting facts. Our Win32 port passes his
>
Tom Lane <[EMAIL PROTECTED]> writes:
> Eric D Nielsen <[EMAIL PROTECTED]> writes:
> > In either case is this a place where "exceeding" the spec would be a good
> > thing or a bad thing?
>
> Unless there is an obvious definition of what updating a join means
> (obvious not only to the implementor
On Wed, 5 Mar 2003, Eric D Nielsen wrote:
> I see how that is what the spec says, but aren't the majority of joins that
> people use/want to update a join of some type? I thought that SQL99 allowed
> updating view created by joins.
>
> In either case is this a place where "exceeding" the spec wou
On Wed, 2003-03-05 at 10:39, Eric D Nielsen wrote:
> > Gavin Sherry <[EMAIL PROTECTED]> writes:
> > > I haven't had time to look into it further, but it occurs to me that
> > > handling views which rely on joins would be far from trivial.
> >
> > Views containing joins would not be updatable; prob
On Wed, 2003-03-05 at 10:36, Bruce Momjian wrote:
> Ewe. There would no longer be a guaranteed name for the serial column
> sequence. Of course, pg_depend has the information, but how do you get
> at that when you create the dump file, and be _sure_ you are going to
> hit the right name, especial
On Tue, Mar 04, 2003 at 11:04:03PM -0500, Tom Lane wrote:
>
> There is still barely enough time to do the long-threatened protocol
> revision for 7.4, if we suck it up and get started on that now. I've
> been avoiding the issue myself, because it seems generally boring and
> thankless work, but m
I've done a lot with XML lately, so I'll throw in my $0.02 worth.
One thing I have noticed about the schemes that are being advanced is that
they seem to be inherently unspecifiable, formally, because column names are
being used as tags.
An alternative might look something like this:
Eric D Nielsen <[EMAIL PROTECTED]> writes:
> In either case is this a place where "exceeding" the spec would be a good
> thing or a bad thing?
Unless there is an obvious definition of what updating a join means
(obvious not only to the implementor, but to the user) I think this
is dangerous terri
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > I haven't had time to look into it further, but it occurs to me that
> > handling views which rely on joins would be far from trivial.
>
> Views containing joins would not be updatable; problem solved.
I see how that is what the spec says, but aren'
Ewe. There would no longer be a guaranteed name for the serial column
sequence. Of course, pg_depend has the information, but how do you get
at that when you create the dump file, and be _sure_ you are going to
hit the right name, especially if you restore only part of the dump.
Seems this kill
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I haven't had time to look into it further, but it occurs to me that
> handling views which rely on joins would be far from trivial.
Views containing joins would not be updatable; problem solved. The set
of views the automatic-rule-generation machinery n
This is just about a total conversion of the backend to an xml document
server. The marriage of xml and sql is awkward and not easily
retrofitted to existing databases.
Its pretty much proven that hierarchal storage techniques (xml included)
are more difficult to manage and use than traditional s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> The *last* thing we need is a half-baked stopgap solution that we'll
> have to be backwards-compatible with forevermore. Fix it right or
> don't do it at all, is MHO.
I agree.
> There is still barely enough time to do the long-threatened protoco
> On Tue, 2003-03-04 at 15:26, Eric D Nielsen wrote:
> > The one place I haven't been able to use PostGreSQL to experiment is with
> > regards to updateable views. I've found a few threads in -general and -hac
> kers
> > (including one linked from the ToDo list), but they all seem to die out wit
>
[EMAIL PROTECTED] writes:
> What about a variable that allowed the codes to be switched on so a
> number is returned instead of a string? This would be off by default
> so as not to break existing applications. Similarly, we can return
> other information (FILE, LINE, etc.) with different variab
On Tue, 4 Mar 2003, Eric D Nielsen wrote:
> The one place I haven't been able to use PostGreSQL to experiment is
> with regards to updateable views. I've found a few threads in
> -general and -hackers (including one linked from the ToDo list), but
> they all seem to die out without really reachin
I would like to see PostgreSQL eventually support XQuery:
http://www.w3.org/TR/xquery/
http://www.w3.org/TR/query-datamodel/
I see potentially an alternative front end called xsql, providing
substantially the same functionality as psql, only using XQuery syntax and
optionally returning recordsets
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2003-03-04 at 15:26, Eric D Nielsen wrote:
> > The one place I haven't been able to use PostGreSQL to experiment is with
> > regards to updateable views. I've found a few threads in -general and -hackers
> > (including one linked from the ToDo lis
XSLT could be used to convert virtually any xml table format directly
into an insert statement. For me, this is better than using a
programming language plus a parser. XSLT is quite powerful and fast and
is build on top of xpath, and is a closer fit to the declarative
programming model of sql. V
On Tue, 2003-03-04 at 15:26, Eric D Nielsen wrote:
> The one place I haven't been able to use PostGreSQL to experiment is with
> regards to updateable views. I've found a few threads in -general and -hackers
> (including one linked from the ToDo list), but they all seem to die out without
> really
Eric D Nielsen <[EMAIL PROTECTED]> writes:
> The one place I haven't been able to use PostGreSQL to experiment is with
> regards to updateable views. I've found a few threads in -general and -hackers
> (including one linked from the ToDo list), but they all seem to die out without
> really reachin
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2003-03-04 14:21]:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> > The XML standard does not call for any table format. But a
> > number of table formats have been established within the XML
> > framework. Some of them are formatting-oriented (e.
We are developing a Win32 port of PostgreSQL 7.3(different from Jan's
implementaion, in that we are using a thread model. In the future I
hope we could contribute the source code). We have done a power
failure testing using the test tool made by Dave Page:
Subject: [HACKERS] Win32 Powerfail testin
Why not just run PostgreSQL like everyone else does (from a hard drive) and
simply give it heaps of buffers - let PostgreSQL manage its RAM itself?
Unless you have your xlog on physical storage, you are asking for trouble.
Actually, unless you have all your database in physical storage, you are
as
On Tue, 2003-03-04 at 19:14, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Might get somewhere by making a special domain thats marked as being
> > serial, and using that in the column.
>
> I recall some discussion last year about making serial et al. into
> domains over int4 and in
Rod Taylor <[EMAIL PROTECTED]> writes:
> Might get somewhere by making a special domain thats marked as being
> serial, and using that in the column.
I recall some discussion last year about making serial et al. into
domains over int4 and int8, rather than their current utter-hack
implementation.
71 matches
Mail list logo
