Michael Fuhr wrote:
Can anybody else reproduce the problem?
I couldn't repro it, on x86 / Debian unstable / gcc 3.4.4, with current
CVS sources.
-Neil
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Wed, Jul 27, 2005 at 12:56:15AM -0400, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > Could this be platform-specific?
>
> Seems that way. I tried it on HPUX 10.20/HPPA/gcc 2.95.3.
No luck on FreeBSD 4.11-STABLE/i386/gcc 2.95.4. The box that does
have a problem is Solaris 9/s
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 sho
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 10.2
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 d
<[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 (indee
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 dat
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
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
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 us
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> ... what I was wondering about is creating a
> 'type' that is a rollup for:
> - create parent table with int id field and text and indexes
> - add RI to base table
> - add triggers/views/rules/other glue to make the id field hidden and
> transparent t
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?
Fi
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
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 in
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 wi
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 st
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 $0.02
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 resu
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 th
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 or
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 on
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 u
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 McA
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
>
Josh Berkus 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 seem to impr
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 definit
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 INSERT INTO oidtest DEFAULT
VALUES; GET DIAGNOSTICS insert_oid_var =
RE
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.
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
> -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
>
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;'';
retur
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 got
On 2005-07-26, Larry Rosenman 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
cause things t
"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.
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 un
> >>> 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
> >> preve
"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
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 differe
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
> > 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 fi
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 tha
Larry Rosenman 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 those known t
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:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=octopus&dt=2005-07
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=octopus&dt=2005-07-26%2015:29:33
So the question now is: h
* 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 R
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 rema
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 ", and that naturally
>> clea
* 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 ", and that naturally
> clears the ROLE setting.
In this case '' is really
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
> Cc: ohp@pyrenet.fr, 'pgsql-hackers list'
> Subject: Re: [HACKERS] regression failure on latest CVS
>
> "Larry Rosenman" writes:
> > For those following along
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 so
51 matches
Mail list logo
