Bruce Momjian writes:
> FYI, I am seeing the same stats regression failures in CVS, even after
> the recent commits to improve sleep().
As near as I can tell, this is fixed by pgstat.c rev 1.101. I'm not
clear why --- the patch certainly zeroes some table fields that were
going uninitialized bef
One pretty silly point: I notice that
http://www.pgbuildfarm.org/index.html
says "The build farm software does not currently run on Windows".
This is out of date no?
One not so trivial question: do we have a policy about system/compiler
updates on buildfarm members? Arguably, if I'm running say O
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
How about if we do something like this?:
. initdb creates a tmpdir inside the datadir
. a new GUC var called allowed_copy_locations which is a PATH type
string specifying what directories we can copy to/from. This would
Tom,
On 7/24/05 4:47 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>
> If we went down this path at all, I'd be inclined to just deprecate
> and eventually remove server-side COPY altogether. Not sure about
> the performance costs of that, though.
Interesting problem, in practice you've got to tran
On Sun, Jul 24, 2005 at 06:40:35PM -0400, Tom Lane wrote:
> I think someone mentioned this already, but it'd be a good idea to
> compare the python situation to plperl. On my Linux box, libperl.so
> shows several references to pthread_xxx symbols ... not the same ones
> libpython.so depends on, bu
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> How about if we do something like this?:
> . initdb creates a tmpdir inside the datadir
> . a new GUC var called allowed_copy_locations which is a PATH type
> string specifying what directories we can copy to/from. This would by
> default be "$tmpdir"
On Sun, Jul 24, 2005 at 07:32:22PM -0400, Andrew Dunstan wrote:
> Could we please add this TODO that I just found missing, much to my
> annoyance?
>
> . md5 function for bytea
Eh?
http://archives.postgresql.org/pgsql-committers/2005-05/msg00239.php
test=> \df md5
List of f
Andrew Dunstan wrote:
> Larry,
>
> please try building and testing (especially PL installcheck) on that
> box using as close as possible to the same config setup as octopus:
>
>
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=octopus&dt=2005-07-24%2008
:05:01
>
> thanks
>
> andrew
It appear
Andrew Dunstan wrote:
Could we please add this TODO that I just found missing, much to my
annoyance?
. md5 function for bytea
I see we have it - I forgot buildfarm is on 7.4 still.
sorry for the noise
andrew
---(end of broadcast)---
TI
Could we please add this TODO that I just found missing, much to my
annoyance?
. md5 function for bytea
cheers
andrew
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if y
Larry Rosenman wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
We don't seem to have made any progress on this. Is there someone
else who has a machine with these specs that they can test this for
us?
FreeBSD 4.11-RELEASE-p10
gcc 2.95.4
x86 SMP
I th
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> We don't seem to have made any progress on this. Is there someone
>> else who has a machine with these specs that they can test this for
>> us?
>
>> FreeBSD 4.11-RELEASE-p10
>> gcc 2.95.4
>> x86 SMP
>
> I think someone mentioned thi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We don't seem to have made any progress on this. Is there someone else
> who has a machine with these specs that they can test this for us?
> FreeBSD 4.11-RELEASE-p10
> gcc 2.95.4
> x86 SMP
I think someone mentioned this already, but it'd be a good id
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
It could be argued that there should be provision for a limitation on
the locations in which COPY can write (and maybe read) files.
If COPY is a security hole then we should close it, not use that as
precedent to open another hole
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Bottom line: If somebody hacks your superuser, you've lost your
> database. If your database service user has write access to sensitive
> areas, or if you later log in as root (or whatever) and execute any
> files that the database service user has wr
We don't seem to have made any progress on this. Is there someone else
who has a machine with these specs that they can test this for us?
FreeBSD 4.11-RELEASE-p10
gcc 2.95.4
x86 SMP
cheers
andrew
Jim C. Nasby wrote:
On Tue, Jul 19, 2005 at 03:53:26PM -0400, Andrew Dunstan wrote:
Do y
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> It could be argued that there should be provision for a limitation on
> the locations in which COPY can write (and maybe read) files.
> If COPY is a security hole then we should close it, not use that as
> precedent to open another hole.
Yeah. It's w
Magnus Hagander wrote:
How is this different from the fact that the superuser can
already use
COPY to accomplish the same thing?
COPY can accomplish a few of the same things, much less
conveniently (for instance, it's darn hard to write an
arbitrary binary file through C
> > How is this different from the fact that the superuser can
> already use
> > COPY to accomplish the same thing?
>
> COPY can accomplish a few of the same things, much less
> conveniently (for instance, it's darn hard to write an
> arbitrary binary file through COPY).
Right. But the *secur
* Tom Lane ([EMAIL PROTECTED]) wrote:
> I'm going to repeat my firm opposition to this patch. Under the
> innocuous-sounding banner of "server instrumentation", you are once
> again trying to put in generic file access capabilities that will allow
> remote Postgres superusers full access to the se
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> How is this different from the fact that the superuser can already use
> COPY to accomplish the same thing?
COPY can accomplish a few of the same things, much less conveniently
(for instance, it's darn hard to write an arbitrary binary file through
C
On Sun, 2005-07-24 at 15:00 -0400, Greg Stark wrote:
> Maybe I'm doing something more obvious wrong?
>
> db=> create table _test (a integer);
> CREATE TABLE
>
> db=> create table _test2 (like _test);
> CREATE TABLE
Yes, unfortunately. You need the phrase "INHERITS (_test)" after the
bra
> > Because I wanted the standard platform behaviour of both.
> For backend
> > storage subsystem purposes, it's certainly necessary to emulate *ix
> > behaviour of deleting a file in use, but for generic file
> access IMHO
> > the generic behaviour should be exposed.
>
> I'm going to repeat
Tom Lane <[EMAIL PROTECTED]> writes:
> Uh, maybe you have sql_inheritance turned off? Every version I can
> remember would show you a pretty explicit Append plan for inheritance
> scans...
staging=> show sql_inheritance;
sql_inheritance
-
on
(1 row)
Maybe I'm doing something
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
This patch looks good. The only question I have is why you
didn't want the pgport rename/unlink calls?
Because I wanted the standard platform behaviour of both. For backend
storage subsystem purposes, it's certainly ne
Andreas Pflug <[EMAIL PROTECTED]> writes:
>> This patch looks good. The only question I have is why you
>> didn't want the pgport rename/unlink calls?
> Because I wanted the standard platform behaviour of both. For backend
> storage subsystem purposes, it's certainly necessary to emulate *ix
>
Bruce Momjian wrote:
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 23 July 2005 20:01
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] For review: Server instrumentation patch
This patch looks good. The only question I ha
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Michael Fuhr wrote:
>> Thanks -- I overlooked that in src/test/regress/README.
> We should probably generalise that section of the README a bit. People
> might skip over it thinking "this isn't a locale difference".
I'm wondering why we still have a R
On Sun, 2005-07-24 at 06:44 -0700, Ron Mayer wrote:
> Simon Riggs wrote:
> > in those cases you are really just maintaining the indexes for partitioning
> > purposes. On older data it may be desirable not to have lots of indexes,
> > or at least use their resources on the indexes they really do wan
Michael Fuhr wrote:
On Sun, Jul 24, 2005 at 08:40:42AM -0500, Andrew Dunstan wrote:
This is completely unnecessary - pg_regress has an alternative result
mechanism that doesn't rely on a resultmap file. Just name your alternative
result file foo_n.out instead of foo.out, for some n in [0-9
On Sun, Jul 24, 2005 at 08:40:42AM -0500, Andrew Dunstan wrote:
> This is completely unnecessary - pg_regress has an alternative result
> mechanism that doesn't rely on a resultmap file. Just name your alternative
> result file foo_n.out instead of foo.out, for some n in [0-9]. In this case,
> call
Michael Fuhr <[EMAIL PROTECTED]> writes:
> A problem with this patch is that it assumes a version of Python
> based on the OS, which might clean up the current buildfarm but
> that isn't really correct. Is there a better way to handle this?
Yes --- just let pg_regress deal with it as if it were a
Michael Fuhr said:
> I just built Python 2.3 and it does indeed format the error differently
> than later versions (the format appears to have changed in 2.3.1):
>
[snip]
> I've attached two new files that should go in the plpython directory:
>
> resultmap
> expected/plpython_error_py23.out
>
> A
Michael Glaesemann wrote:
> Thanks, Bruce, for improving and applying the interval->day patch.
> I've been busy with work and slow in catching up on what you actually
> did (I still need to go back and look) and look forward to learning
> what remained to make the patch more complete.
>
> I'
Simon Riggs wrote:
in those cases you are really just maintaining the indexes for partitioning
purposes. On older data it may be desirable not to have lots of indexes,
or at least use their resources on the indexes they really do want.
Also, if you have a List partitioned table where all rows in
On Sat, Jul 23, 2005 at 10:38:59PM -0400, Tom Lane wrote:
> Well, if it is just a Python version issue then all we need do is add
> a variant expected-output file to match. I was just expressing a
> desire to know that for sure before we wallpaper over the symptom...
I just built Python 2.3 and i
On Sun, 2005-07-24 at 17:57 +0900, Tatsuo Ishii wrote:
> It seems current CE implementation ignores UPDATE, DELETE quries. Is
> this an intended limitation?
Yes, it does not currently optimise the execution of UPDATE/DELETE
against a parent table.
This is not an intended long-term limitation and
It seems current CE implementation ignores UPDATE, DELETE quries. Is
this an intended limitation?
--
Tatsuo Ishii
> So far, the CE patch covers only inherited child tables and is only
> effective when enable_constraint_exclusion is true.
>
> There have been various requests for this to work with
38 matches
Mail list logo
