> [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
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/
-
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 broadcast)
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
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 B
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?
T
[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
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
> h
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
"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 c
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
> HeapT
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 en
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.
Th
Tom Lane wrote:
> Bruce Momjian 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 applying,
> I am not s
Bruce Momjian 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 friend
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.
---
Ni
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 s
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
> >>
> 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 serv
"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
--
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 colu
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
> i
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 quer
> 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
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
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 b
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 t
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
---
"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
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 th
"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 res
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
source
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.
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:
> Bruce Momjian 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
"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.
> A
Bruce Momjian 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 seems to me to cover the
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
--- 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
> -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,
>> * 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 surpr
>> 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
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 subd
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-tarba
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 s
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
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
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 droppi
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 t
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 log
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 e
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
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
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
"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?
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 who
(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 win
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
> "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, 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
"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
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, write-ca
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 broadcast)--
> > 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
> > 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
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 wit
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 pg_stat_activit
67 matches
Mail list logo