Michael Fuhr <[EMAIL PROTECTED]> writes:
> I brought this up a few months ago. Tom, weren't your objections
> based more on implementation concerns than on whether the idea
> itself had merit?
No, my point was that making implicit sequences work transparently
requires more thought than this. I'd
On Sat, Mar 26, 2005 at 01:35:20AM -0500, Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Should we perhaps also propagate grant insert on a table to grant
> > select, update on dependent serial sequences?
>
> Doesn't really follow. That code is maintaining an invariant
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I assume that this behaviour makes change owner on a table change owner
> of serial sequences?
Yeah.
> Should we perhaps also propagate grant insert on a table to grant
> select, update on dependent serial sequences?
Doesn't really follow.
Fix two bugs in change_owner_recurse_to_sequences: it was grabbing an
overly strong lock on pg_depend, and it wasn't closing the rel when done.
The latter bug was masked by the ResourceOwner code, which is something
that should be changed.
I assume that this behaviour makes change owner on a table
Let me know of any problems ... will announce her tomorrow if none ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of broadcast)
On Fri, Mar 25, 2005 at 06:46:58PM -0500, Tom Lane wrote:
> Also, you just introduced a race condition, since the transaction might
> have committed after the earlier tests and before you did
> TransactionIdIsInProgress. You really have to do
> TransactionIdIsInProgress *first*, which makes the p
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Windows has ordering failures on the join and rules tests - Cygwin has a
failures on the stats test. See buildfarm for details.
The ordering failures seem to be because the recent planner hacking has
taken us back to preferring me
Still doesn't work for me :(
UNICODE DB
C locale
set client_encoding = iso88591;
select upper('æ');
upper
---
(1 row)
Trying to initdb with en_IN.utf8
/usr/lib/postgresql/bin/initdb -D /var/lib/postgres/data/ -E UNICODE
--locale=en_IN.utf8
The files belonging to this database system will
On Fri, Mar 25, 2005 at 12:53:53 -0800,
Steve Crawford <[EMAIL PROTECTED]> wrote:
>
> 2) If so, what is the replacement?
You should be able to use EXTRACT, some math to do your own formatting.
For common operations you can define SQL functions to do what you want.
Having to_char(interval) may b
> -Original Message-
> From: Palle Girgensohn [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 26, 2005 1:10 PM
> To: pgsql-hackers@postgresql.org
> Cc: John Hansen; Andrew Dunstan
> Subject: Re: [HACKERS] Patch for collation using ICU
>
> --On fredag, mars 25, 2005 00.40.04 +0100 Pal
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Windows has ordering failures on the join and rules tests - Cygwin has a
> failures on the stats test. See buildfarm for details.
The ordering failures seem to be because the recent planner hacking has
taken us back to preferring merge joins for these
--On lördag, mars 26, 2005 10.42.19 +1100 John Hansen <[EMAIL PROTECTED]>
wrote:
FYI, I also found that initdb crashes with error 139 on any locale other
than C/POSIX.
Odd, not for me, but I did make a bad assumption about character encoding.
Perhaps the new patch will help? (see previous mail)
--On fredag, mars 25, 2005 00.40.04 +0100 Palle Girgensohn
<[EMAIL PROTECTED]> wrote:
Hi!
I've put together a patch for using IBM's ICU package for collation.
If your OS does not have full support for collation ur
uppercase/lowercase in multibyte locales, this might be useful. If you
are using a
On Sat, 2005-03-26 at 02:32 +0100, Karel Zak wrote:
> On Fri, 2005-03-25 at 20:03 -0500, Tom Lane wrote:
> > Steve Crawford <[EMAIL PROTECTED]> writes:
> > > In digging around I discovered that it appears a decision was made to
> > > remove to_char(interval) at the 8.1 release but I've been unable
On Fri, 2005-03-25 at 20:03 -0500, Tom Lane wrote:
> Steve Crawford <[EMAIL PROTECTED]> writes:
> > In digging around I discovered that it appears a decision was made to
> > remove to_char(interval) at the 8.1 release but I've been unable to
> > find the replacement for this functionality. This a
On Fri, 2005-03-25 at 15:33 -0500, Tom Lane wrote:
> Lyubomir Petrov <[EMAIL PROTECTED]> writes:
> > I have found what is causing the crash described in Bug 1500. Now I
> > would like to fix it, but need opinions about what is the correct behaviour.
>
> Yeah, I just came to the same conclusion a
Steve Crawford <[EMAIL PROTECTED]> writes:
> In digging around I discovered that it appears a decision was made to
> remove to_char(interval) at the 8.1 release but I've been unable to
> find the replacement for this functionality. This alarms me.
Yeah. Karel Zak, who wrote that code, is convin
Karel Zak <[EMAIL PROTECTED]> writes:
>> What do you think about just adding
>>
>> case DCH_MONTH:
>> + if (!tm->tm_mon)
>> + return 0;
>> and similarly in each of the other case arms that use tm_mon?
> Yes, I think you're right. It's because original code was for non-
>
After I do a vacuum full, I will run memtest and some disk diags.
Thanks
Jim
-- Original Message ---
From: Gavin Sherry <[EMAIL PROTECTED]>
To: Jim Buttafuoco <[EMAIL PROTECTED]>
Cc: pgsql-hackers
Sent: Sat, 26 Mar 2005 11:02:39 +1100 (EST)
Subject: Re: [HACKERS] Missing segmen
On Fri, 25 Mar 2005, Jim Buttafuoco wrote:
> All,
>
> I had to abort a vacuum full after 36 hours on a large table (16 million
> rows). I started the vacuum again and after
> 10 minutes in got to the place I aborted it (control-c) yesterday. I
> recieved the following error
>
> ERROR: could n
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I got very strange results in my shared-row-locking test today, so I
> took a look at HeapTupleSatisfiesUpdate and came to the conclusion
> that it's delivering the wrong answer in some cases; specifically, it
> returns HeapTupleBeingUpdated for tuples w
On Fri, 2005-03-25 at 14:08 -0500, Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> > On Fri, 2005-03-25 at 03:29 -0500, Tom Lane wrote:
> >> I intend to look at that tomorrow. Meanwhile, have you got a fix
> >> for bug#1500?
> >> http://archives.postgresql.org/pgsql-bugs/2005-02/msg00226
> --On fredag, mars 25, 2005 23.39.33 +1100 John Hansen
> <[EMAIL PROTECTED]>
> wrote:
>
> > Ok,.. tested on debian sarge with ICU 3.2 UNICODE Database,
> C locale.
> >
> > upper() and lower() returns an empty string for any input,
> including
> > 7bit ascii, regardless of client_encoding, so
All,
I had to abort a vacuum full after 36 hours on a large table (16 million rows).
I started the vacuum again and after
10 minutes in got to the place I aborted it (control-c) yesterday. I recieved
the following error
ERROR: could not open segment 3 of relation "emi_110101_idx1" (target b
I have seen some small regression failures on REL8_0_STABLE - I thought
as we're coming up to a release I'd better run the stable branch through
on my buildfarm clients.
Windows has ordering failures on the join and rules tests - Cygwin has a
failures on the stats test. See buildfarm for detail
Hackers,
I got very strange results in my shared-row-locking test today, so I
took a look at HeapTupleSatisfiesUpdate and came to the conclusion
that it's delivering the wrong answer in some cases; specifically, it
returns HeapTupleBeingUpdated for tuples whose Xmax were touched by a
crashed trans
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2005-03-25 at 15:22 -0500, Tom Lane wrote:
>> 2. Dead tuples don't have that much influence on scan costs either, at
>> least not once they are marked as known-dead. Certainly they shouldn't
>> be charged at full freight.
> Yes, minor additional C
On Fri, 2005-03-25 at 15:22 -0500, Tom Lane wrote:
> 2. Dead tuples don't have that much influence on scan costs either, at
> least not once they are marked as known-dead. Certainly they shouldn't
> be charged at full freight.
Yes, minor additional CPU time, but the main issue is when the dead
tu
Tom Lane wrote:
Lyubomir Petrov <[EMAIL PROTECTED]> writes:
I have found what is causing the crash described in Bug 1500. Now I
would like to fix it, but need opinions about what is the correct behaviour.
Yeah, I just came to the same conclusion a little while ago:
http://archives.postgres
Steve Crawford wrote:
So this bug actually brings the issue of interval to_char()
formatting. Opinions?
In digging around I discovered that it appears a decision was made to
remove to_char(interval) at the 8.1 release but I've been unable to
find the replacement for this functionality. This
Tom Lane wrote:
I wrote:
One thing that is possibly relevant here is that in 8.0 a plain VACUUM
doesn't set reltuples to the exactly correct number, but to an
interpolated value that reflects our estimate of the "steady state"
average between vacuums. I wonder if that code is wrong, or if it's
--On fredag, mars 25, 2005 09.53.38 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Palle Girgensohn <[EMAIL PROTECTED]> writes:
hmm... I think I might have made a false assumption that
the locale string would contain the character encoding.
You certainly cannot assume that. Would that it were so easy
> So this bug actually brings the issue of interval to_char()
> formatting. Opinions?
In digging around I discovered that it appears a decision was made to
remove to_char(interval) at the 8.1 release but I've been unable to
find the replacement for this functionality. This alarms me.
Given the
Lyubomir Petrov <[EMAIL PROTECTED]> writes:
> I have found what is causing the crash described in Bug 1500. Now I
> would like to fix it, but need opinions about what is the correct behaviour.
Yeah, I just came to the same conclusion a little while ago:
http://archives.postgresql.org/pgsql-hacker
I wrote:
> One thing that is possibly relevant here is that in 8.0 a plain VACUUM
> doesn't set reltuples to the exactly correct number, but to an
> interpolated value that reflects our estimate of the "steady state"
> average between vacuums. I wonder if that code is wrong, or if it's
> operating
Hi,
I have found what is causing the crash described in Bug 1500. Now I
would like to fix it, but need opinions about what is the correct behaviour.
The bug can be easily duplicated when formatting interval in to_char()
using 'Mon' or 'Month' in the format string.
select to_char(now() - '200110
Karel Zak <[EMAIL PROTECTED]> writes:
> On Fri, 2005-03-25 at 03:29 -0500, Tom Lane wrote:
>> I intend to look at that tomorrow. Meanwhile, have you got a fix
>> for bug#1500?
>> http://archives.postgresql.org/pgsql-bugs/2005-02/msg00226.php
> Sorry. Not yet. I haven't time today. Maybe next week
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> On Fri, 25 Mar 2005, Tom Lane wrote:
>> Does "\d pg_trigger" show that the tgargs column is of type bytea?
> Umm no:
> tgnargs| smallint | not null
tgargs, not tgnargs.
>> Also, get the OID for this pg_trigger row and see if it shows up in
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Fri, 25 Mar 2005, Tom Lane wrote:
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
prod=# select * from pg_trigger where tgname = 'RI_ConstraintTrigger_39053';
- -[ RECORD 1 ]--+---
tgrelid| 37564
tgname | RI_Cons
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> prod=# select * from pg_trigger where tgname = 'RI_ConstraintTrigger_39053';
> - -[ RECORD 1 ]--+---
> tgrelid| 37564
> tgname | RI_ConstraintTrigger_39053
> tgfoid | 1644
> tgtype | 21
> tgenabled
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tom,
On Fri, 25 Mar 2005, Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
Odd, why is this not showing up as a foreign key constraint? Has this
database been upgraded (no matter through how many different upgrades)
from an old version (7.1
Tom Lane wrote:
Palle Girgensohn <[EMAIL PROTECTED]> writes:
hmm... I think I might have made a false assumption that
the locale string would contain the character encoding.
You certainly cannot assume that. Would that it were so easy to find
out the character set for a locale :-(.
There
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Fri, 25 Mar 2005, Stephan Szabo wrote:
===
prod=# \d t_firma_moduller
Table
"public.t_firma_moduller"
Column |
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Odd, why is this not showing up as a foreign key constraint? Has this
> database been upgraded (no matter through how many different upgrades)
> from an old version (7.1 or earlier I think)?
And the other odd thing is that it fails to dump it as a trigg
Palle Girgensohn <[EMAIL PROTECTED]> writes:
> hmm... I think I might have made a false assumption that
> the locale string would contain the character encoding.
You certainly cannot assume that. Would that it were so easy to find
out the character set for a locale :-(.
There's some code in ini
On Fri, 25 Mar 2005, Devrim GUNDUZ wrote:
> -
> --
> PostgreSQL 8.0.1 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC)
> 3.2.3 20030502 (Red Hat Linux 3.2.3-42)
> =
--On fredag, mars 25, 2005 23.39.33 +1100 John Hansen <[EMAIL PROTECTED]>
wrote:
Ok,.. tested on debian sarge with ICU 3.2
UNICODE Database, C locale.
upper() and lower() returns an empty string for any input, including
7bit ascii, regardless of client_encoding, so something is obviously
broken.
Ok,.. tested on debian sarge with ICU 3.2
UNICODE Database, C locale.
upper() and lower() returns an empty string for any input, including
7bit ascii, regardless of client_encoding, so something is obviously
broken.
Have you tested this patch on a UNICODE DB with locale C/POSIX ?
... John
> --
> --On fredag, mars 25, 2005 16.34.41 +1100 John Hansen
> <[EMAIL PROTECTED]>
> wrote:
>
> > Useful if it's going to support earlier releases of ICU
> >
> > Not all os's come with ICU3.2, debian for example,
> currently has 2.1
> > in testing, and 2.6 in unstable.
>
> Oh, OK. FreeBSD has o
--On fredag, mars 25, 2005 16.34.41 +1100 John Hansen <[EMAIL PROTECTED]>
wrote:
Useful if it's going to support earlier releases of ICU
Not all os's come with ICU3.2, debian for example, currently has 2.1 in
testing, and 2.6 in unstable.
Oh, OK. FreeBSD has only the 3.2 as port. I can check
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I've Google'd for the situation below and could not find any solution.
We are using PostgreSQL 8.0.1, installed using PGDG RPMs on RHEL ES 3.0:
===
prod=# SELECT version();
On Thu, Mar 24, 2005 at 08:40:54AM -0800, Moran.Michael wrote:
> # select * from crypto;
> id | title |crypted_content
> +---+
> 1 | test1 | \307\266xI\235"\210a\363=\201\222\247\2660\215
> 2 | test2 | D\211\256E\372^Y\025
-Original Message-
From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
Sent: Fri 3/25/2005 1:14 AM
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] Upcoming 8.0.2 Release
> How quickly can you get a precompiled binary in place? Would delaying
> release until April 7
On Fri, 2005-03-25 at 03:29 -0500, Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> > http://archives.postgresql.org/pgsql-patches/2005-03/msg00176.php
>
> I intend to look at that tomorrow. Meanwhile, have you got a fix
> for bug#1500?
> http://archives.postgresql.org/pgsql-bugs/2005-0
Karel Zak <[EMAIL PROTECTED]> writes:
> http://archives.postgresql.org/pgsql-patches/2005-03/msg00176.php
I intend to look at that tomorrow. Meanwhile, have you got a fix
for bug#1500?
http://archives.postgresql.org/pgsql-bugs/2005-02/msg00226.php
regards, tom lane
http://archives.postgresql.org/pgsql-patches/2005-03/msg00176.php
Add it to 8.0.2 or 8.1?
Karel
--
Karel Zak <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
56 matches
Mail list logo
