On Jul 26 2005, ohp@pyrenet.fr wrote:
On Mon, 25 Jul 2005, Tom Lane wrote:
FWIW, I just checked that CVS tip works OK for me without these options,
with either integer or float timestamps. I don't see any new warnings,
either.
It could well be that the recent changes have introduced some
On Mon, 25 Jul 2005, Tom Lane wrote:
Date: Mon, 25 Jul 2005 23:26:20 -0400
From: Tom Lane [EMAIL PROTECTED]
To: Larry Rosenman ler@lerctr.org
Cc: ohp@pyrenet.fr, 'pgsql-hackers list' pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] regression failure on latest CVS
Larry Rosenman
* Tom Lane ([EMAIL PROTECTED]) wrote:
Ideally the ROLLBACK should have restored the ROLE setting that obtained
prior to BEGIN. The reason it doesn't is that the ROLLBACK effectively
does a SET SESSION AUTHORIZATION prior-auth-value, and that naturally
clears the ROLE setting.
In this case
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Ideally the ROLLBACK should have restored the ROLE setting that obtained
prior to BEGIN. The reason it doesn't is that the ROLLBACK effectively
does a SET SESSION AUTHORIZATION prior-auth-value, and that naturally
I've committed changes to add a rolinherit flag to pg_authid as per
discussion. The pg_has_role function now distinguishes USAGE rights
on a role (do you currently have the privileges of that role) from
MEMBER rights (do you have the ability to SET ROLE to that role).
A couple of loose ends
* Tom Lane ([EMAIL PROTECTED]) wrote:
I've committed changes to add a rolinherit flag to pg_authid as per
discussion. The pg_has_role function now distinguishes USAGE rights
on a role (do you currently have the privileges of that role) from
MEMBER rights (do you have the ability to SET ROLE
On Mon, Jul 25, 2005 at 05:02:02PM -0500, Jim C. Nasby wrote:
Can you try rebuilding python and it's dependencies WITHOUT_THREADS?
I think that would get us where we need?
Worked:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=octopusdt=2005-07-26%2015:29:33
So the question now is: how do
On Jul 26 2005, Jim C. Nasby wrote:
On Mon, Jul 25, 2005 at 05:02:02PM -0500, Jim C. Nasby wrote:
Can you try rebuilding python and it's dependencies WITHOUT_THREADS?
I think that would get us where we need?
Worked:
Larry Rosenman ler@lerctr.org writes:
On Jul 26 2005, Jim C. Nasby wrote:
So the question now is: how do we fix the issue with threaded python?
how do we get libc_r into the mix on FreeBSD 4.11?
A possible compromise is to add -lc_r to LIBS if (a) --enable-python
and (b) platform is one of
On Jul 15, 2005, at 5:13 PM, David Wheeler wrote:
No. I'm using the readline that comes with Tiger, FWIW. If you tell
me how to create a stack trace, I'll post it somewhere for you to
see. I don't know C, myself.
Didn't see a reply to this, but if it makes a difference, I just
learned
If you want to secure your system against a superuser()-level
intrusion then you need to secure the unix account, or disable
creation of C-language and other untrusted languages (at least).
Very likely --- which is why Magnus' idea of an explicit
switch to prevent superuser filesystem
On Tue, Jul 26, 2005 at 01:09:11PM -0700, Jeff Davis wrote:
Chris Travers wrote:
How hard would it be to automatically create enum_ tables in the back
ground to emulate MySQL's enum type? Sort of like we do with SERIAL
datatypes... Part of the problem is that MySQL's enum type is so
I'd like to suggest altering the syntax of VACUUM so that it is possible
to issue the command VACUUM DATABASE. The keyword DATABASE would be
optional, to allow backward compatibility.
The reasons for this are better understanding and comprehension. S
many people are confused about the
Magnus Hagander [EMAIL PROTECTED] writes:
If you want to secure your system against a superuser()-level
intrusion then you need to secure the unix account, or disable
creation of C-language and other untrusted languages (at least).
Very likely --- which is why Magnus' idea of an explicit
If you want to secure your system against a superuser()-level
intrusion then you need to secure the unix account, or disable
creation of C-language and other untrusted languages (at least).
Very likely --- which is why Magnus' idea of an explicit switch to
prevent superuser
On Tue, Jul 26, 2005 at 09:30:20PM +0100, Simon Riggs wrote:
I'd like to suggest altering the syntax of VACUUM so that it is possible
to issue the command VACUUM DATABASE. The keyword DATABASE would be
optional, to allow backward compatibility.
Huh, so why not have an optional LAZY?
I
Magnus Hagander [EMAIL PROTECTED] writes:
I'm OK with them even without the directory limitation as
long as there's a way to disable them. However, I fear the
whole thing has to wait for 8.2 at this point.
That would be very bad - considering it just missed 8.0 as well.
[ shrug... ] The
On 2005-07-26, Larry Rosenman ler@lerctr.org wrote:
So the question now is: how do we fix the issue with threaded python?
how do we get libc_r into the mix on FreeBSD 4.11?
You'd have to build the backend with -pthread.
Including -lc_r explicitly when linking stuff on freebsd will usually
On Fri, 2005-07-22 at 19:11 -0400, Tom Lane wrote:
Hmm. Eyeballing the NOTPM trace for cases 302912 and 302909, it sure
looks like the post-checkpoint performance recovery is *slower* in
the latter. And why is 302902 visibly slower overall than 302905?
I thought for a bit that you had gotten
Just ran into a fascinating edge case. One of our folks was building
a stored function, and ran into an odd error when trying to COPY to
stdout.
Here's a characteristic example:
create or replace function build_table (integer) returns integer as '
begin
execute ''copy foo to stdout;'';
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 26 July 2005 22:01
To: Magnus Hagander
Cc: Stephen Frost; Andrew Dunstan; Andreas Pflug; Bruce
Momjian; Dave Page; PostgreSQL-development
Subject: Re: [HACKERS] For review: Server instrumentation patch
Magnus
On 7/26/05, Jim C. Nasby wrote:
On Tue, Jul 26, 2005 at 01:09:11PM -0700, Jeff Davis wrote:
Ultimately to do it in a general way I think we'd need functions that
return a type that can be used in a table definition. Aside from the
many problems I don't know about, there are two other
Simon,
We should run tests with much higher wal_buffers numbers to nullify the
effect described above and reduce contention. That way we will move
towards the log disk speed being the limiting factor, patch or no patch.
I've run such tests, at a glance they do seem to improve performance. I
Recent cvs versions are failing the following
script;
create table oidtest(a time default now()) with
oids;
CREATE OR REPLACE FUNCTION oidtest() RETURNS integer
AS $oidtest$DECLAREinsert_oid_var
INTEGER;BEGININSERT INTO oidtest DEFAULT
VALUES;GET DIAGNOSTICS insert_oid_var =
On Wed, Jul 27, 2005 at 12:11:47AM +0200, Jochem van Dieten wrote:
On 7/26/05, Jim C. Nasby wrote:
On Tue, Jul 26, 2005 at 01:09:11PM -0700, Jeff Davis wrote:
Ultimately to do it in a general way I think we'd need functions that
return a type that can be used in a table definition. Aside
Josh Berkus josh@agliodbs.com writes:
We should run tests with much higher wal_buffers numbers to nullify the
effect described above and reduce contention. That way we will move
towards the log disk speed being the limiting factor, patch or no patch.
I've run such tests, at a glance they do
On Tue, Jul 26, 2005 at 03:36:26PM -0700, Kevin McArthur wrote:
Recent cvs versions are failing the following script;
create table oidtest(a time default now()) with oids;
CREATE OR REPLACE FUNCTION oidtest() RETURNS integer AS $oidtest$
DECLARE
insert_oid_var INTEGER;
BEGIN
I cannot repoduce your experience with this bug. No matter what I do,
reconnect session or otherwise, it never returns a proper oid on the newer
cvs vers (I suspect it may be related to the roles update)
Kevin
- Original Message -
From: Michael Fuhr [EMAIL PROTECTED]
To: Kevin
Jim C. Nasby wrote:
On Wed, Jul 27, 2005 at 12:11:47AM +0200, Jochem van Dieten wrote:
On 7/26/05, Jim C. Nasby wrote:
On Tue, Jul 26, 2005 at 01:09:11PM -0700, Jeff Davis wrote:
Ultimately to do it in a general way I think we'd need functions that
return a type that can be
On Tue, Jul 26, 2005 at 04:31:21PM -0700, Kevin McArthur wrote:
I cannot repoduce your experience with this bug. No matter what I do,
reconnect session or otherwise, it never returns a proper oid on the newer
cvs vers (I suspect it may be related to the roles update)
Hmmm...my system is only
bash-2.05b$ ./createdb test3
CREATE DATABASE
bash-2.05b$ ./createlang plpgsql test3
bash-2.05b$ ./psql test3
Welcome to psql 8.1devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g
Tom,
I have no idea whether the DBT benchmarks would benefit at all, but
given that they are affected positively by increasing wal_buffers,
they must have a fair percentage of not-small transactions.
Even if they don't, we'll have series tests for DW here at GreenPlum soon,
and I'll bet
Andrew Dunstan wrote:
At one stage I thought of stealing some vertical space for 8 or 10
columns of 10 pixels or so to show the state of the most importand
build flag. I still might do that, if I can standardise the OS and
Compiler info so that they get shorter (e.g. is just knowing that we
On Tue, Jul 26, 2005 at 04:31:21PM -0700, Kevin McArthur wrote:
I cannot repoduce your experience with this bug. No matter what I do,
reconnect session or otherwise, it never returns a proper oid on the
newer cvs vers (I suspect it may be related to the roles update)
I'm seeing varying
Given the current issue with the SCO Optimizer and --enable-debug, I'd like
to keep it on the list.
I'd also like to see a way to run both --enable-debug and not --enable-debug
runs either alternately or
With a command line arg.
Same with the --enable-integer-datetimes switch.
Just my
On Jul 27, 2005, at 11:27 AM, Andrew Dunstan wrote:
I have reduced some of the clutter from OS names/versions and
compiler names/versions,
Out of curiosity, how did you do this? Did you update the original
registration data or make some kind of mapping?
and can reduce some more in the
On Jul 27, 2005, at 11:42 AM, Larry Rosenman wrote:
Given the current issue with the SCO Optimizer and --enable-debug,
I'd like
to keep it on the list.
I'd also like to see a way to run both --enable-debug and not --
enable-debug
runs either alternately or
With a command line arg.
Same
Simon Riggs [EMAIL PROTECTED] writes:
I'd like to suggest altering the syntax of VACUUM so that it is possible
to issue the command VACUUM DATABASE. The keyword DATABASE would be
optional, to allow backward compatibility.
This would require converting DATABASE from an unreserved keyword into
a
Larry Rosenman wrote:
I'd also like to see a way to run both --enable-debug and not --enable-debug
runs either alternately or
With a command line arg.
Same with the --enable-integer-datetimes switch.
In general we don't want you changing the settings much. That goes to
the issue of
Michael Glaesemann wrote:
On Jul 27, 2005, at 11:27 AM, Andrew Dunstan wrote:
I have reduced some of the clutter from OS names/versions and
compiler names/versions,
Out of curiosity, how did you do this? Did you update the original
registration data or make some kind of mapping?
Hi all,
I ran across this yesterday on HEAD:
template1=# grant select on foo, foo to swm;
ERROR: tuple already updated by self
We could do away with the error by producing a unique list of object names
-- but that would impose an extra cost on the common case. It seems to me
that producing a
I would like to use pgsl as an interpreter (in the sense of
execve(2)). In short, if a file begins with the line
#! /path/to/psql -f
it should be interpretable by psql. The normal semantics of execve(2)
ensure that this will work perfectly (indeed a file containing
#!/path/to/psql
Michael Fuhr [EMAIL PROTECTED] writes:
Is anybody with a deeper understanding of the code looking at this?
I tried to reproduce the problem ... no joy ...
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze
On Wed, Jul 27, 2005 at 12:08:18AM -0400, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Is anybody with a deeper understanding of the code looking at this?
I tried to reproduce the problem ... no joy ...
Hmmm...not even with the example that starts from initdb? I'm up
to date with
[EMAIL PROTECTED] writes:
I would like to use pgsl as an interpreter (in the sense of
execve(2)). In short, if a file begins with the line
#! /path/to/psql -f
it should be interpretable by psql. The normal semantics of execve(2)
ensure that this will work perfectly (indeed a
Gavin Sherry [EMAIL PROTECTED] writes:
I ran across this yesterday on HEAD:
template1=# grant select on foo, foo to swm;
ERROR: tuple already updated by self
Seems to fail similarly in every version back to 7.2; probably further,
but that's all I have running at the moment.
We could do
Michael Fuhr [EMAIL PROTECTED] writes:
On Wed, Jul 27, 2005 at 12:08:18AM -0400, Tom Lane wrote:
I tried to reproduce the problem ... no joy ...
Hmmm...not even with the example that starts from initdb?
Nope...
Could this be platform-specific?
Seems that way. I tried it on HPUX
Tom Lane writes:
Given that # is not a comment introducer in SQL, I would consider
it a bug if it did.
I understand that # is not a comment introducer in SQL. I am
wondering if it would be sensible to introduce an exception for the
first line of a file. To prevent problems the behavior
48 matches
Mail list logo
