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 was passed
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
Hi,
Were 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
.
.
.
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 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'
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
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 me. Look at
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 problem.
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 and a
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 messages in
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.
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
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
status is
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
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 last
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
location
-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 Epstein
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
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?
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 (alvherre[a]dcc.uchile.cl)
And as an added bonus, now my computer goes to the toilet for me, leaving
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
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 asynchronous?
--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 a write cache
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 is written when it's
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
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.
-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:
I'd like to
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 tool is usable to
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.
--
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 else objects,
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
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 create
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 just
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
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
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-generic name
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
-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't apply
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 that I
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
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
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-specific
42 matches
Mail list logo
