It sure would be nice to be able to have a way to query the start time
of the eldest transaction on the system. If that could be done at a
not-too-high cost, it would be eminently helpful for various sorts of
maintenance processes so that you could assortedly:
You can get that from
I have done initial implementation of SQL99 WITH clause (attached).
It's now only for v7.3.4 and haven't a lot of checks and restrictions.
What kind of restrictions are on it?
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once
I have done initial implementation of SQL99 WITH clause (attached).
It's now only for v7.3.4 and haven't a lot of checks and restrictions.
What kind of restrictions are on it?
Main restriction is that the query inside WITH alias can refer only to
back and to itself.
For example
WITH a as
Magnus prepared a trivial patch which added the O_SYNC flag for
windows and mapped it to FILE_FLAG_WRITE_THROUGH in win32_open.c.
Attached is this trivial patch. As Merlin says, it needs some
more reliability testing. But the numbers are at least reasonable - it
*seems* like it's doing
In the final test, the BIOS decided the disk was giving up and
reassigned it as 0Mb.. Required two extra cold boots, then it was back
up to 20Gb. Still no data loss.
I think it would be fun to re-run these tests with MySQL...
Chris
---(end of
My results are:
Fisrt, baseline:
* Linux, with fsync (default), write-cache disabled: no data corruption
* Linux, with fsync (default), write-cache enabled: usually no data
corruption, but two runs which had
* Win32, with fsync, write-cache disabled: no data corruption
* Win32, with fsync,
Magnus Hagander [EMAIL PROTECTED] writes:
My results are:
Fisrt, baseline:
* Linux, with fsync (default), write-cache disabled: no data corruption
* Linux, with fsync (default), write-cache enabled: usually no data
corruption, but two runs which had
That makes sense.
* Win32, with fsync,
* Win32, with fsync, write-cache disabled: no data corruption
* Win32, with fsync, write-cache enabled: no data corruption
* Win32, with osync, write cache disabled: no data corruption
* Win32, with osync, write cache enabled: no data corruption. Once I
got:
2005-02-24 12:19:54 LOG:
Magnus Hagander [EMAIL PROTECTED] writes:
My results are:
Fisrt, baseline:
* Linux, with fsync (default), write-cache disabled: no data corruption
* Linux, with fsync (default), write-cache enabled: usually no data
corruption, but two runs which had
That makes sense.
* Win32, with fsync,
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
It sure would be nice to be able to have a way to query the start time
of the eldest transaction on the system. If that could be done at a
not-too-high cost, it would be eminently helpful for various sorts of
maintenance processes so that you
(crossposting this to hackers, I'm sure there are interested people
there as well)
Since Dave set the site up for tracking clickthroughs, I hit the db with
a couple of queries to count our downloads. This is what I came up with:
I did some simple pivoting in Excel and split it into categories
On Thu, 24 Feb 2005, Magnus Hagander wrote:
3) There doesnt' seem to be much point to the distribution splits. A
total of less than 5% the *number* of downloads. And most people
probably get more than one file, so in reality that number shuold
proably be divided by 4 or 5.
I know several people
Magnus Hagander [EMAIL PROTECTED] writes:
* Linux, with fsync (default), write-cache enabled: usually no data
corruption, but two runs which had
Are you verifying that all the data that was committed was actually stored? Or
just verifying that the database works properly after rebooting?
I'm
Bjoern Metzdorf [EMAIL PROTECTED] writes:
I assume I could just remove
#define USE_WIDE_UPPER_LOWER
from oracle_compat.c to emulate the old behaviour. But a cleaner fix
would be to check if we are using UNICODE and locale is C or POSIX and
only then skip USE_WIDE_UPPER_LOWER.
Perhaps it
Greg Stark [EMAIL PROTECTED] writes:
I'm a bit surprised that the write-cache lead to a corrupt database, and not
merely lost transactions. I had the impression that drives still handled the
writes in the order received.
There'd be little point in having a cache if they did, I should think.
I
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
I'm a bit surprised that the write-cache lead to a corrupt database, and not
merely lost transactions. I had the impression that drives still handled the
writes in the order received.
There'd be little point in
On Thu, Feb 24, 2005 at 11:14:07AM -0500, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
It sure would be nice to be able to have a way to query the start time
of the eldest transaction on the system. If that could be done at a
not-too-high cost, it would be eminently
Hi Magnus,
On Feb 24, 2005, at 11:35 AM, Magnus Hagander wrote:
I did some simple pivoting in Excel and split it into categories win32,
source, sig (MD5 or PGP signatures), RPMs, split (the split tarballs),
pgadmin and ODBC. Other stuff was so little that I cut it.
Assuming this is from a HTTP
Gavin and Neil made some noise in late September about implementing
stored procedures for PG 8.1, but I haven't heard anything more about
it since that thread died off. I've been getting some pressure inside
Red Hat to see us support more of the JDBC CallableProcedure spec, so
I'd like to reopen
On Thu, 24 Feb 2005 17:35:57 +0100, Magnus Hagander wrote:
I know several people who downloaded source *plus* the split ones,
because hey, I need postgresql. And I certainly need base too. And I
need docs.. They don't realise it's included in the main tarball.
Frankly, I'd suggest dropping
Troels Arvin [EMAIL PROTECTED] writes:
On Thu, 24 Feb 2005 17:35:57 +0100, Magnus Hagander wrote:
Frankly, I'd suggest dropping the splits. Thoughts?
I also found the split sources + a non-split sources version to be
confusing. As you, I think that splitting should be dropped.
Perhaps the
On Thu, 24 Feb 2005, Tom Lane wrote:
Troels Arvin [EMAIL PROTECTED] writes:
On Thu, 24 Feb 2005 17:35:57 +0100, Magnus Hagander wrote:
Frankly, I'd suggest dropping the splits. Thoughts?
I also found the split sources + a non-split sources version to be
confusing. As you, I think that splitting
One interesting artifact of using \e to edit a multi-line command is
that the same command is then treated as a single-line command in
subsequent up-arrow or Ctrl-P attempts.
I use this frequently to achieve a similar effect to what you're after.
The one downside is that if you leave the psql
On Thursday 24 February 2005 21:43, Marc G. Fournier wrote:
[...]
pub/source/v.8.0.1/
postgresql-8.0.1.tar.bz2
postgresql-8.0.1.tar.bz2.md5
postgresql-8.0.1.tar.gz
postgresql-8.0.1.tar.gz.md5
split-tarballs/
Frankly, I'd suggest dropping the splits. Thoughts?
I also found the split sources + a non-split sources version to be
confusing. As you, I think that splitting should be dropped.
Perhaps the confusion issue could be addressed by keeping the split
sources in a separate subdirectory:
You may find that if you check this case again that the
usually no data
corruption is actually usually lost transactions but no
corruption.
That's a good point, but it seems difficult to be sure of the last
reportedly-committed transaction in a powerfail situation. Maybe if
you drive the
* Linux, with fsync (default), write-cache enabled: usually no data
corruption, but two runs which had
Are you verifying that all the data that was committed was
actually stored? Or
just verifying that the database works properly after rebooting?
I verified the data.
I'm a bit surprised
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John DeSoi
Sent: 24 February 2005 19:20
To: Magnus Hagander
Cc: pgsql-hackers@postgresql.org; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Some download statistics
Hi Magnus,
On Feb 24, 2005, at
--- Tom Lane [EMAIL PROTECTED] escreveu:
Gavin and Neil made some noise in late September about implementing
stored procedures for PG 8.1, but I haven't heard anything more about
it since that thread died off. I've been getting some pressure inside
Red Hat to see us support more of the JDBC
Thomas Hallgren wrote:
It looks to me like the asymmetry between CREATE TRIGGER and DROP
TRIGGER is actually required by SQL99, though, so changing it would
be a hard sell (unless SQL2003 fixes it?).
Comments anyone?
Why not say that TRUNCATE requires the same privilige as a DELETE
Bruce Momjian pgman@candle.pha.pa.us writes:
Uh, that seems like it adds extra complexity just for this single case.
Yeah. I've dropped the idea personally -- the suggestion that the table
owner can provide a SECURITY DEFINER procedure to do the TRUNCATE if he
wants to allow others to do it
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 24 Feb 2005, Tom Lane wrote:
Also: I notice that the README file that's supposed to tell people about
the split-tarball scheme is not present in any of the recent-version
subdirectories, so it's no wonder that they are confused.
Actually,
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Uh, that seems like it adds extra complexity just for this single case.
Yeah. I've dropped the idea personally -- the suggestion that the table
owner can provide a SECURITY DEFINER procedure to do the TRUNCATE if he
wants to
Oh, thanks. That is a great fix. Applied. Glad you could test it on a
machine that supports positional parameters.
---
Kurt Roeckx wrote:
On Mon, Feb 21, 2005 at 10:53:08PM -0500, Bruce Momjian wrote:
Applied.
Tom Lane wrote:
Kurt Roeckx [EMAIL PROTECTED] writes:
The configure test is a little broken. It needs to quote the
$'s.
I've rewritten the test a little.
Applied, thanks.
Oops, Tom got to it first. (Darn!) :-)
--
Bruce Momjian| http://candle.pha.pa.us
On Thu, 24 Feb 2005, Magnus Hagander wrote:
Frankly, I'd suggest dropping the splits. Thoughts?
I also found the split sources + a non-split sources version to be
confusing. As you, I think that splitting should be dropped.
Perhaps the confusion issue could be addressed by keeping the split
Francisco Figueiredo Jr. [EMAIL PROTECTED] writes:
Could I add another item?
Could we have the row count of statements executed inside a
procedure/function returned to client?
IMHO that request is completely bogus; if the procedure wants to tell
the client that, it's the procedure's
On Thu, 24 Feb 2005, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 24 Feb 2005, Tom Lane wrote:
Also: I notice that the README file that's supposed to tell people about
the split-tarball scheme is not present in any of the recent-version
subdirectories, so it's no wonder that
Keith Worthington [EMAIL PROTECTED] writes:
On Thu, 24 Feb 2005 17:15:42 -0500, Tom Lane wrote
Yeah. I've dropped the idea personally -- the suggestion that the table
owner can provide a SECURITY DEFINER procedure to do the TRUNCATE if
he wants to allow others to do it seems to me to cover
Bruce Momjian wrote:
Is there a TODO here?
Probably -- I think there is definitely room for improving psql's
handling of multi-line queries. However, \e works well enough for me,
and I don't think I'll get around to looking at this for 8.1. So feel
free to add a TODO item.
-Neil
Hi Tom,
On Thu, 24 Feb 2005, Tom Lane wrote:
Gavin and Neil made some noise in late September about implementing
stored procedures for PG 8.1, but I haven't heard anything more about
it since that thread died off. I've been getting some pressure inside
Red Hat to see us support more of the
Magnus Hagander wrote:
The installer does not permit it, but initdb lets you do anything yuo
want - I think that's where we are. If you know what you're doing, you
can use it by manually initdbing.
There is no such thing as unicode locale. Unicode (UTF8) is an
encoding, that has to be
Neil Conway wrote:
Bruce Momjian wrote:
Is there a TODO here?
Probably -- I think there is definitely room for improving psql's
handling of multi-line queries. However, \e works well enough for me,
and I don't think I'll get around to looking at this for 8.1. So feel
free to add a TODO
To fix UTF8, the data needs to be converted to
UTF16 and then
the Win32 wcscoll() can be used, and perhaps other functions
like towupper(). However, UTF8 already works with normal
locales but provides no ordering.
Right,. So if that's fixed, then
Bruce Momjian wrote:
And what would the TODO item be? Improve psql's handling of multi-line
queries is too vague.
If you can include a link to the archives or the text of the relevant
mails, it seems fine to me. I'm not sure specifically _how_ we want to
improve the handling of multi-line
Neil Conway wrote:
Bruce Momjian wrote:
And what would the TODO item be? Improve psql's handling of multi-line
queries is too vague.
If you can include a link to the archives or the text of the relevant
mails, it seems fine to me. I'm not sure specifically _how_ we want to
improve the
K, let me rephrase:
currently, upper/lower does not work with 2+ byte unicode characters, on any OS
under the C locale.
... John
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining
John Hansen [EMAIL PROTECTED] writes:
Right,. So if that's fixed, then UTF8 will work only on windows?
No.
(currently, upper/lower does not work with 2+ byte unicode characters, on any
OS)
This information is obsolete.
regards, tom lane
currently, upper/lower does not work with 2+ byte unicode
characters, on any OS under the C locale.
Btw,...
There are only 15 cases in the utf8 repertoire that depends on locale, these
are the only cases where pg should report:
ERROR: invalid multibyte character for locale
HINT: The
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
It sure would be nice to be able to have a way to query the start time
of the eldest transaction on the system. If that could be done at a
not-too-high cost, it would be eminently helpful for various sorts of
maintenance
Gavin Sherry [EMAIL PROTECTED] writes:
On Thu, 24 Feb 2005, Tom Lane wrote:
For instance, a procedure foo(x IN int, y OUT text, z OUT float)
could perhaps be called via
SELECT y, z FROM foo(42);
where foo(x) is seen as returning the rowtype (y text, z float).
The composite type stuff is
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Bruce Momjian pgman@candle.pha.pa.us writes:
Your patch has been added to the PostgreSQL unapplied patches list at:
Didn't we do that already?
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Your patch has been added to the PostgreSQL unapplied patches list at:
Didn't we do that already?
This patch is for thread safety:
Thanks a lot. The patch attached solves the tread
safety problem. Please review it before
I read the following report from the NetBSD group:
http://kerneltrap.org/node/4680
It has some interesting points. First, they analyze how the fit with
other open source database offerings. Their position is somewhat
similar to ours.
Their development style is also similar to ours.
Tatsuo Ishii wrote:
I do not object the changing UNICODE-UTF-8, but all these discussions
sound a little bit funny to me.
If you want to blame UNICODE, you should blame LATIN1 etc. as
well. LATIN1(ISO-8859-1) is actually a character set name, not an
encoding name. ISO-8859-1 can be encoded
Tom Lane wrote:
As of CVS tip, there is no code in the system that uses SnapshotSelf.
I am wondering if we can get rid of it and thereby save one test in
the heavily used HeapTupleSatisfiesVisibility() macro.
There is one place in the foreign-key triggers that uses the underlying
Magnus Hagander [EMAIL PROTECTED] writes:
I'm a bit surprised that the write-cache lead to a corrupt database, and
not merely lost transactions. I had the impression that drives still
handled the writes in the order received.
In this case, it was lost transactions, not data corruption.
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.
Might we set a rough date for Beta freeze for 8.1 then?
Bruce Momjian wrote:
You can get that from pg_stat_activity, if you have the relevant stats
turned on.
pg_stat_activity will tell you about the oldest active query, but not
about oldest open transaction.
And pg_stat_activity can lose information when the network is under
heavy load too.
[EMAIL PROTECTED] writes:
Tom, I believe you said at the time that I should check pg_stat_activity.
My current code polls it for the old backend pid. But if that is neither
100% reliable nor unconditionally available, wouldn't it be better if I
just queried pg_locks for the transaction's ID?
Tom Lane wrote:
Essentially I'm thinking about the JDBC solution, but automated a bit
better.
So would your proposal invent a new stored procedure construct, or
just add some sugar to the existing function stuff? i.e. will you be
able to issue a CREATE FUNCTION that specifies OUT parameters?
On Fri, 25 Feb 2005, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.
Might we set a rough date for
Bruce Momjian wrote:
Oh, sorry. So there is no ordering in Unicode?
That statement is meaningless. Unicode is a character set, not a
collation order.
No wonder some
languages can't use Unicode effectively.
That has nothing to do with it.
o Disallow encodings like UTF8 which
Bruce Momjian wrote:
We are not consistent in favoring the
official names vs. the common names.
The problem is rather that there are too many standards and conventions
to choose from.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
John Hansen wrote:
currently, upper/lower does not work with 2+ byte unicode characters,
on any OS under the C locale.
Sure it does. It's just that the defined behavior of the C locale is
often useless in practice.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
[EMAIL PROTECTED] writes:
pg_locks certainly seems like a better solution. Perhaps it didn't
exist when you went with pg_stat_activity? Can't recall offhand.
Neither do I... But I do need something that will work with at least any
recent backend version--say, 7.2 or since. The more the
67 matches
Mail list logo
