Gavin Sherry <[EMAIL PROTECTED]> writes:
> The attached patch changes the existing behaviour of length(char(n)).
Applied, with some simplifications (there wasn't any particular need to
make a temporary copy of the string).
I also added some documentation stating that trailing spaces are
semantica
"Nicolai Tufar" <[EMAIL PROTECTED]> writes:
>> We might think that the Turkish-locale problem Devrim Gunduz pointed out
>> is a must-fix, too. But I'm not convinced yet what to do about it.
> Here is a first try to fix what Devrim Gunduz talked about.
I still don't much like having a locale-spe
Tatsuo Ishii wrote:
Thanks. Please apply it.
Applied to REL7_3_STABLE.
Thanks,
Joe
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
> We might think that the Turkish-locale problem Devrim Gunduz pointed out> is a must-fix, too. But I'm not convinced yet what to do about it.
Here is a first try
to fix what
Devrim Gunduz talked about.
Please be patient with me for
it is the first major patch
I submit and I realize tha
-Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
> Sent: Tuesday, January 27, 2004 1:35 PM
>
> "Ezra Epstein" <[EMAIL PROTECTED]> writes:
> >> I do not think SET SESSION AUTH is a suitable replacement for logging
> >> in. For one thing, it doesn'
> Tatsuo Ishii wrote:
> > It's surprising that nobody noticed the bug until now. It seems it has
> > been there since 7.3 days. I would like to make a back patch for
> > 7.3-stable if nobody objects.
>
> It's my bug :( -- sorry about that. Here's a 7.3 patch per Tom's nearby
> advice. I'll apply
I don't want to kludge up a 2-phase commit support. Any attempt to provide
that must be extremely well thought through :-)
But I would like to know more about PostgreSQL capabilities in the area.
What kind of XA-support is there? Can I read about this somewhere? (I'm
working on an Open Source hig
On Sat, 31 Jan 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Sat, 31 Jan 2004, Tom Lane wrote:
> >> So, what I'd like to do is make btree index creation pay attention to
> >> vacuum_mem instead of sort_mem, and rename the vacuum_mem parameter to
> >> some more-gener
Tom Lane wrote:
Now, what should we call it instead? I haven't come up with any
compelling thoughts --- the best I can do is "big_sort_mem" or
"single_sort_mem". Surely someone out there has a better idea.
BTW, does anyone want to lobby for renaming sort_mem at the same time?
Since it's used for
What I want accomplish has been very well defined already. I'm thinking of
javax.transaction.Transaction and javax.transaction.Synchronized, two
interfaces readily available in any J2EE application server. The actions
that can be performed by implementers of the latter interface (the one that
gets
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Sat, 31 Jan 2004, Tom Lane wrote:
>> So, what I'd like to do is make btree index creation pay attention to
>> vacuum_mem instead of sort_mem, and rename the vacuum_mem parameter to
>> some more-generic name indicating that it's used for more than
On Sat, 31 Jan 2004, Tom Lane wrote:
> So, what I'd like to do is make btree index creation pay attention to
> vacuum_mem instead of sort_mem, and rename the vacuum_mem parameter to
> some more-generic name indicating that it's used for more than just
> VACUUM. Any objections so far?
Why not cre
We frequently recommend to people that they increase sort_mem while
creating btree indexes. It is reasonable to have a larger setting
for that purpose, since (1) a single backend isn't going to be doing
multiple index creations in parallel (whereas complex queries could
easily be doing multiple so
Michael Brusser <[EMAIL PROTECTED]> writes:
> We tracked problem to this line in pgtcl.c:
>putenv ("PGCLIENTENCODING=UNICODE");
> Changing this to
>Tcl_PutEnv ("PGCLIENTENCODING=UNICODE");
> seems to be a good fix, so far we are not seeing any problems.
Looks good to me. Unless anyone els
Edwin S. Ramirez wrote:
> Hello,
>
> Is is possible to change the transaction behaviour not to abort when a
> syntax error occurs.
>
> I've done some searches on the list, and have not found anything.
No, we need nested transactions for that. We are working on it or at
least have a plan.
--
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >Andreas Pflug <[EMAIL PROTECTED]> writes:
> >
> >
> >>This would be the first time a SCSI disk lies about its write caching.
> >>There are plenty of low-cost (i.e. IDE) disks out there having a hidden
> >>write cache, but AFAIK a generic SCSI
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 27, 2004 10:46 AM
> To: [EMAIL PROTECTED]
> Cc: Bruce Momjian; PostgreSQL-development
> Subject: Re: [HACKERS] Extending SET SESSION AUTHORIZATION
>
>
> "Ezra Epstein" <[EMAIL PROTECTED]> writes:
> >>>
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
This would be the first time a SCSI disk lies about its write caching.
There are plenty of low-cost (i.e. IDE) disks out there having a hidden
write cache, but AFAIK a generic SCSI tool is usable to enable/disable
the write cache.
On Jan 30, 2004, at 4:53 PM, Bruce Momjian wrote:
Actually, thinking about this a bit more, that might not even be
necessary. Is SIGPIPE-via-(read|write) synchronous or asynchronous?
(I.e., is the SIGPIPE guaranteed to arrive during the offending system
call?) I was thinking not, but maybe yes. I c
On Tue, 27 Jan 2004, Larry Rosenman wrote:
> >> >>
> >> >> ISTM that the driver should force it out to the disk, unless the disk
> >> >> is lying to the driver, or the driver is buggy.
> >> > That's exactly what I think: the DISK has a write cache so it's lying
> >> > to the controler saying data i
--On Tuesday, January 27, 2004 23:15:09 +0100 [EMAIL PROTECTED] wrote:
On Tue, 27 Jan 2004, Larry Rosenman wrote:
>> >>
>> >> ISTM that the driver should force it out to the disk, unless the
>> >> disk is lying to the driver, or the driver is buggy.
>> > That's exactly what I think: the DISK has
OK, thanks.
---
Scott Lamb wrote:
> On Jan 30, 2004, at 4:53 PM, Bruce Momjian wrote:
> >> Actually, thinking about this a bit more, that might not even be
> >> necessary. Is SIGPIPE-via-(read|write) synchronous or asynchron
Hello,
I need Postgres support for the following update syntax :
update table1 set (col1, col2, col3) = (select f1, f2, f3 from table2
where id=5) where rownum=3;
update table1 set (col1, col2, col3) = (select f1, f2, f3 from table2
where id=table1.parentid) where rownum=3;
These type of update
On Fri, Jan 30, 2004 at 07:43:06AM -0800, Edwin S. Ramirez wrote:
> Is is possible to change the transaction behaviour not to abort when a
> syntax error occurs.
Not currently.
--
Alvaro Herrera ()
"And as an added bonus, now my computer goes to the toilet for me, leaving me
free to spend time
Hello,
Is is possible to change the transaction behaviour not to abort when a
syntax error occurs.
I've done some searches on the list, and have not found anything.
-ESR-
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Ezra Epstein wrote:
I'd like to extend SET SESSION AUTHORIZATION to support a form which takes a
password.
Uh, a password? What purpose would that serve?
Indeed. SET SESSION AUTH is already allowed only to superusers --- a
superuser
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 26, 2004 7:56 PM
> To: Bruce Momjian
> Cc: [EMAIL PROTECTED]; PostgreSQL-development
> Subject: Re: [HACKERS] Extending SET SESSION AUTHORIZATION
>
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Ezra
Tom Lane wrote:
> I got the impression that Thomas wanted this in order to kluge up
> some kind of two-phase-commit support, in which case he really needs
> to get control at the point where we're just about to really truly
> commit (ie, write the commit WAL record). That's certainly not a
> locat
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Why can't we call the callback before we commit so it can modify the
> database?
He wanted that too...
A user callback before we start the commit sequence seems doable,
although there's some question in my mind of exactly when it should
happen. The las
On 31. jan 2004, at 18:53, Tom Lane wrote:
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
Ideally, I'd like a "beforeCompletion" that is executed prior to the
start
of the commit process and a "afterCompletion" that is called when the
transaction is commited. The latter would have a status flag
in
Tom Lane wrote:
> "Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> > Ideally, I'd like a "beforeCompletion" that is executed prior to the start
> > of the commit process and a "afterCompletion" that is called when the
> > transaction is commited. The latter would have a status flag indicating if
> >
Orion Henry <[EMAIL PROTECTED]> writes:
> It appears to be faulting on a kerberos call which is odd because I
> don't use kerberos for anything.
I was a bit surprised to realize that if you compile Kerberos support at
all, libpq will try to get a user name from Kerberos in preference to
using getp
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> Ideally, I'd like a "beforeCompletion" that is executed prior to the start
> of the commit process and a "afterCompletion" that is called when the
> transaction is commited. The latter would have a status flag indicating if
> status is "prepared" (to
"Dan Langille" <[EMAIL PROTECTED]> writes:
> On 31 Jan 2004 at 11:56, Tom Lane wrote:
>> 7.4's pg_dump will use AUTHORIZATION so that situations like this
>> restore correctly, but 7.3's pg_dump is stupid and tries to create the
>> schema as its owner.
> Does it matter that I used pg_dumpall?
No.
On 31 Jan 2004 at 11:56, Tom Lane wrote:
> "Dan Langille" <[EMAIL PROTECTED]> writes:
> >>> I upgraded two servers today from 7.3.* to 7.4.1. In both cases, the
> >>> schemas which existed in the original databases were not created in
> >>> the new database.
>
> > I found three of these messag
I would like to register a "transaction callback" in the backend. Don't
think it's possible today and my question is, how hard would it be to
implement something that would enable this registration?
Ideally, I'd like a "beforeCompletion" that is executed prior to the start
of the commit process an
"Dan Langille" <[EMAIL PROTECTED]> writes:
>>> I upgraded two servers today from 7.3.* to 7.4.1. In both cases, the
>>> schemas which existed in the original databases were not created in
>>> the new database.
> I found three of these messages in /var/log/messages on the box which
> had the pr
Tatsuo Ishii wrote:
It's surprising that nobody noticed the bug until now. It seems it has
been there since 7.3 days. I would like to make a back patch for
7.3-stable if nobody objects.
It's my bug :( -- sorry about that. Here's a 7.3 patch per Tom's nearby
advice. I'll apply if you'd like.
Joe
I
On 30 Jan 2004 at 23:34, Tom Lane wrote:
> "Dan Langille" <[EMAIL PROTECTED]> writes:
> > I upgraded two servers today from 7.3.* to 7.4.1. In both cases, the
> > schemas which existed in the original databases were not created in
> > the new database.
> > New issue? Known bug?
>
> New one on
My search was wrong. This is a known issue.
Sorry for the post.
--
Dan Langille : http://www.langille.org/
BSDCan - http://www.bsdcan.org/
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscri
Hi folks,
I upgraded two servers from 7.3.* to 7.4.1. In both cases, the
pgcrypto functions failed to migrate.. I used pg_dumpall. This is
the cause of the problem:
freshports=# CREATE FUNCTION digest (text, text) RETURNS bytea
freshports-# AS '$libdir/pgcrypto', 'pg_digest'
freshports
I agree with Tom on this. Good operator combinations
are hard to find when you are creating new operators.
=> is a particularly good one.
Barring any override from the SQL200x standard,
I would strongly suggest AS, too.
elein
[EMAIL PROTECTED]
On Sun, Jan 25, 2004 at 02:54:12PM -0500, Tom Lane
Hi,
We’re running postgres7.3 on RedHat7.3. The Postgres
at boot time starts up from a java (1.2) class that runs the following commands
in order:
/usr/local/pgsql/bin/pg_ctl -w start -D /var/lib/pgsql -l /var/log/pgsqld.log
-o –i
/usr/local/pgsql/bin/createdb management
.
.
.
Manfred Spraul <[EMAIL PROTECTED]> writes:
> The checkpoint code uses sync() right now. Actually sync();sleep(2);sync().
> Win32 has no sync() call, therefore it will use fsyncs. Perhaps platforms with
> deferred errors on close must use fsync, too. Hopefully parallel fsyncs -
> sequential fsyncs
Randolf Richardson <[EMAIL PROTECTED]> writes:
> "[EMAIL PROTECTED] (Greg Stark)" stated in
> comp.databases.postgresql.hackers:
>> The traditional Unix filesystems certainly don't return errors at close.
> Why shouldn't the close() function return an error? If an invalid
> file handle wa
45 matches
Mail list logo
