Perhaps one could just create a PostgreSQL Powertools section on
techdocs, naming the packages and where to get them. This would
eliminate the need to maintain a package that just duplicates other
packages...
Let ye-old package managers make a shell package which simply points to
the
Dear hackers,
I have recently been playing with DB2 8.1 Beta. It has introduced a
feature to enable index clustering on more than one key. This reminded
me of a previous thread on HACKERS about index access anding/bitmaps in
Firebird. So anyway, here is a little snip from the 8.1 manual as a
%gmake
bison -y -d preproc.y
preproc.y:5560: fatal error: maximum table size (32767) exceeded
gmake[4]: *** [preproc.h] Error 1
gmake[4]: Leaving directory `/spool/home/teodor/pgsql/src/interfaces/ecpg/preproc'
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory
Teodor Sigaev [EMAIL PROTECTED] wrote:
%gmake
bison -y -d preproc.y
preproc.y:5560: fatal error: maximum table size (32767) exceeded
gmake[4]: *** [preproc.h] Error 1
gmake[4]: Leaving directory
`/spool/home/teodor/pgsql/src/interfaces/ecpg/preproc'
gmake[3]: *** [all] Error 2
Sean Chittenden [EMAIL PROTECTED] writes:
WARNING: COMMIT: no transaction in progress
I've got tons of these warnings in my logs... is there a programmatic
way of determining if the current session is in a transaction?
Not at present: you have to track it for yourself. One of the
Philip Warner [EMAIL PROTECTED] writes:
None, but it will be compatible with itself (the most we can hope for), and
will work even if shifting is not supported for off_t (how likely is
that?). I agree shift is definitely the way to go if it works on arbitrary
data - ie. it does not rely on
Oleg Bartunov [EMAIL PROTECTED] writes:
install bison 1.75
I've fixed the INSTALL and installation.sgml docs to say you need bison
1.50 or later (it used to say 1.28 or later). Is there anyplace else we
should point this out?
regards, tom lane
On Wed, Oct 09, 2002 at 09:42:56AM -0400, Sandeep Chadha wrote:
I'd say yes replication can solve lot of issues, but is there a way
to do replication in postgres(active-active or active-passive)
Yes. Check out the rserv code in contrib/, the (?) dbmirror code in
contrib/, or contact
What I just committed uses your idea of auto-committing TRUNCATE et al,
but now that I review the thread I think that everyone else thought that
that was a dangerous idea. How do you feel about simply throwing an error
in autocommit-off mode, instead? (At least it's a localized
change
On Mon, Oct 14, 2002 at 12:04:14AM -0400, Tom Lane wrote:
implication is that its effects would be global to all backends. But
the uses that I've seen for suspending trigger invocations would be
happier with a local, temporary setting that only affects the current
backend. Any thoughts
Schema handling - ready? interfaces? client apps?
What is the state of the Perl interface?
Will it work when 7.3 is released
Will it work, but no schema support
Will it pop up later on CPAN
--
Kaare Rasmussen--Linux, spil,--Tlf:3816 2582
Kaki Data
Marc G. Fournier writes:
Okay, this is the only message(s) I have on this ... since merging
earthdistance back into the tree will most likely cause more headaches,
breakage and outcries, and since I see no reason why anyone would want to
'checkout' a module that has already been checked out
Bruce Momjian writes:
OK, we are down to one open item, related to pg_dumping on 64-bit off_t.
We had discussion today on this so it should be completed shortly.
I hate to spoil the fun, but we have at least the Linux + Perl
5.8.1 + _GNU_SOURCE and the AIX + Large File + Flex problems to fix.
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
OK, we are down to one open item, related to pg_dumping on 64-bit off_t.
We had discussion today on this so it should be completed shortly.
I hate to spoil the fun, but we have at least the Linux + Perl
5.8.1 + _GNU_SOURCE and
I got tired of wondering what timing dependencies might still be lurking
in the parallel regression tests, and wrote a little Perl script to find
out by making variant versions of the parallel_schedule file.
Essentially, the script forces each test in a parallel group to run
before all the other
I've started playing a little with Postgres to determine if there were
memory leaks running around. After some very brief checking, I'm
starting[1] to think that the answer is yes. Has anyone already gone
through a significant effort to locate and eradicate memory leaks? Is
this done
On Tue, Oct 22, 2002 at 04:16:16PM -0500, Greg Copeland wrote:
I've started playing a little with Postgres to determine if there were
memory leaks running around. After some very brief checking, I'm
starting[1] to think that the answer is yes. Has anyone already gone
through a significant
Greg Copeland [EMAIL PROTECTED] writes:
I've started playing a little with Postgres to determine if there were
memory leaks running around. After some very brief checking, I'm
starting[1] to think that the answer is yes. Has anyone already gone
through a significant effort to locate and
I've been thinking about how to convert x IN (subselect) and EXISTS
constructs into join-like processing, and I've run into a small problem
in getting the planner to do it nicely. The issue is that I need to
take the subselect and push it into the jointree --- essentially, make
it look like a
Petru Paler [EMAIL PROTECTED] writes:
valgrind is a great tool I used -- didn't get the time to try it out on
Postgres yet, though. Besides leaks, it also catches uninitialized
variable access and stuff like that.
I've used Valgrind with PostgreSQL a little bit, and it's been fairly
useful (I
On Tue, 2002-10-22 at 17:09, Tom Lane wrote:
Greg Copeland [EMAIL PROTECTED] writes:
I've started playing a little with Postgres to determine if there were
memory leaks running around. After some very brief checking, I'm
starting[1] to think that the answer is yes. Has anyone already gone
On 22 Oct 2002, Greg Copeland wrote:
On Tue, 2002-10-22 at 17:09, Tom Lane wrote:
plpgsql has some issues too, I suspect, but not as bad as pltcl etc.
Possibly the best answer is to integrate the memory-context notion into
those modules; if they did most of their work in a temp context
On Tue, Oct 22, 2002 at 19:01:20 +0200,
Kaare Rasmussen [EMAIL PROTECTED] wrote:
Schema handling - ready? interfaces? client apps?
What is the state of the Perl interface?
Will it work when 7.3 is released
Will it work, but no schema support
Will it pop up later on CPAN
I am using Pg
Nigel J. Andrews [EMAIL PROTECTED] writes:
I saw use of a couple of malloc (or Python specific malloc) calls the
other day but I also seem to recall that, after consideration, I
decided the memory needed to survive for the duration of the
backend. Should I have created a new child of the top
Greg Copeland [EMAIL PROTECTED] writes:
On Tue, 2002-10-22 at 17:09, Tom Lane wrote:
Yes, this has been dealt with before.
What tools, aside from noggin v1.0, did they use? Do we know?
s/they/me/ ... none. But I don't know of any that I think would be
useful.
I then moved on to psql,
Bruce Momjian [EMAIL PROTECTED] writes:
I wonder if any other platforms have this limitation. I think we need
to add some type of test for no-fseeko()/ftello() and sizeof(off_t)
sizeof(long). This fseeko/ftello/off_t is just too fluid, and the
failure modes too serious.
I am wondering why
At 12:32 AM 23/10/2002 -0400, Tom Lane wrote:
I am wondering why pg_dump has to depend on either fseek or ftell.
It doesn't - it just works better and has more features if they are
available, much like zlib etc.
Philip Warner
At 12:29 AM 23/10/2002 -0400, Bruce Momjian wrote:
This fseeko/ftello/off_t is just too fluid, and the
failure modes too serious.
I agree. Can you think of a better solution than the one I suggested???
Philip Warner
OK, you are saying if we don't have fseeko(), there is no reason to use
off_t, and we may as well use long. What limitations does that impose,
and are the limitations clear to the user.
What has me confused is that I only see two places that use a non-zero
fseeko, and in those cases, there is a
At 01:02 AM 23/10/2002 -0400, Bruce Momjian wrote:
OK, you are saying if we don't have fseeko(), there is no reason to use
off_t, and we may as well use long. What limitations does that impose,
and are the limitations clear to the user.
What I'm saying is that if we have not got fseeko then
On Tue, Oct 22, 2002 at 11:28:23PM -0400, Tom Lane wrote:
I then moved on to psql, again, just for fun. Here, I'm thinking that I
started to find some other leaks...but again, I've not spent any real
time on it. So again, I'm not really sure it they are meaningful at
this point.
psql
WARNING: COMMIT: no transaction in progress
COMMIT
The WARNING happens with SHOW and RESET too. I wonder if we should
suppress the WARNING of a COMMIT with no statements when autocommit is
off.
I don't think so; that will make it quite hard to check whether a
transaction
At 09:52 PM 21/10/2002 -0400, Bruce Momjian wrote:
4) pg_restore -Fc /tmp/x
pg_restore /tmp/x
is enough; it will determine the file type, and by avoiding the pipe, you
allow it to do seeks which are not much use here, but are usefull when you
only restore one table in a very large
regression=# select '{124,567,66}'::int[] + 345;
?column?
--
{124,567,66,345}
(1 row)
regression=# select '{124,567,66}'::int[] + '{345,1}'::int[];
?column?
{124,567,66,345,1}
(1 row)
select '{124,567,66}'::int[] - 567;
?column?
--
install bison 1.75
On Tue, 22 Oct 2002, Teodor Sigaev wrote:
%gmake
bison -y -d preproc.y
preproc.y:5560: fatal error: maximum table size (32767) exceeded
gmake[4]: *** [preproc.h] Error 1
gmake[4]: Leaving directory `/spool/home/teodor/pgsql/src/interfaces/ecpg/preproc'
gmake[3]:
At 10:16 AM 21/10/2002 -0400, Tom Lane wrote:
What are
the odds that dumping the bytes in it, in either order, will produce
something that's compatible with any other platform?
None, but it will be compatible with itself (the most we can hope for), and
will work even if shifting is not
At 12:00 PM 22/10/2002 -0400, Bruce Momjian wrote:
It does have the advantage of being more portable on systems
that do have integral off_t
I suspect it is no more portable than determining storage order by using
'int i = 256', then writing in storage order, and has the disadvantage that
it
Bruce Momjian [EMAIL PROTECTED] writes:
However, since we don't know if we support any non-integral off_t
platforms, and because a configure test would require us to have two
code paths for with/without integral off_t, I suggest we apply my
version of Philip's patch and let's see if everyone
Philip Warner wrote:
At 12:00 PM 22/10/2002 -0400, Bruce Momjian wrote:
It does have the advantage of being more portable on systems
that do have integral off_t
I suspect it is no more portable than determining storage order by using
'int i = 256', then writing in storage order, and has
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
However, since we don't know if we support any non-integral off_t
platforms, and because a configure test would require us to have two
code paths for with/without integral off_t, I suggest we apply my
version of Philip's patch and
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I just noticed that this afternoon's changes cause dblink's regression
test to fail due to:
CREATE OR REPLACE FUNCTION conditional_drop()
[...]
IF FOUND THEN
DROP DATABASE regression_slave;
END IF;
[...]
'
Kaare Rasmussen wrote:
Schema handling - ready? interfaces? client apps?
What is the state of the Perl interface?
Will it work when 7.3 is released
Will it work, but no schema support
Will it pop up later on CPAN
We have a separate gborg project for the old perl5 in interface and
WARNING: COMMIT: no transaction in progress
I've got tons of these warnings in my logs... is there a programmatic
way of determining if the current session is in a transaction?
Not at present: you have to track it for yourself. One of the
suggestions on the list for the next
Bruce Momjian [EMAIL PROTECTED] writes:
Your version will break more often because we are assuming we can
determine the endian-ness of the OS, _and_ for quad off_t types,
assuming we know that is stored the same too. While we have ending for
int's, I have no idea if quads are always stored
Patch applied with shift / changes by me. Thanks.
---
Philip Warner wrote:
I have put the latest patch at:
http://downloads.rhyme.com.au/postgresql/pg_dump/
along with two dump files of the regression DB,
Bruce Momjian wrote:
So I think we're wasting our time to debate whether we need to support
non-integral off_t ... let's just apply Bruce's version and wait to
see if anyone has a problem before doing more work.
I am concerned about one more thing. On BSD/OS, we have off_t of quad
(8
Bruce Momjian writes:
I am concerned about one more thing. On BSD/OS, we have off_t of quad
(8 byte), but we don't have fseeko, so this call looks questionable:
if (fseeko(AH-FH, tctx-dataPos, SEEK_SET) != 0)
Maybe you want to ask your OS provider how the heck this is supposed to
On Wed, 2002-10-23 at 03:09, Tom Lane wrote:
It's fairly difficult to get anywhere with standard leak-tracking tools,
since they don't know anything about palloc. What's worse, it is *not*
a bug for a routine to palloc space it never pfrees, if it knows that
it's palloc'ing in a short-lived
Peter Eisentraut wrote:
Bruce Momjian writes:
I am concerned about one more thing. On BSD/OS, we have off_t of quad
(8 byte), but we don't have fseeko, so this call looks questionable:
if (fseeko(AH-FH, tctx-dataPos, SEEK_SET) != 0)
Maybe you want to ask your OS provider how the
On Tue, 22 Oct 2002, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
OK, we are down to one open item, related to pg_dumping on 64-bit off_t.
We had discussion today on this so it should be completed shortly.
I hate to spoil the fun, but we have at least
Marc G. Fournier wrote:
On Tue, 22 Oct 2002, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
OK, we are down to one open item, related to pg_dumping on 64-bit off_t.
We had discussion today on this so it should be completed shortly.
I hate to
At 05:37 PM 22/10/2002 -0400, Bruce Momjian wrote:
! if (ctx-hasSeek
! #if !defined(HAVE_FSEEKO)
!sizeof(off_t) = sizeof(long)
! #endif
! )
Just to clarify my understanding:
- HAVE_FSEEKO is tested defined in configure
- If it is not
This sounds like one of those classic optimizer problems we have had to
deal with in the past. I suggest you go through the optimizer pass and
set a boolean in Query whenever you do something that may require
another loop through, then at the end, you check the boolean and loop if
required.
I
Philip Warner wrote:
At 05:37 PM 22/10/2002 -0400, Bruce Momjian wrote:
! if (ctx-hasSeek
! #if !defined(HAVE_FSEEKO)
!sizeof(off_t) = sizeof(long)
! #endif
! )
Just to clarify my understanding:
- HAVE_FSEEKO is tested
At 10:46 PM 22/10/2002 -0400, Bruce Momjian wrote:
Uh, not exactly. I have off_t as a quad, and I don't have fseeko, so
the above conditional doesn't work. I want to use off_t, but can't use
fseek().
Then when you create dumps, they will be invalid since I assume that ftello
is also broken in
Sounds messy. Let me see if I can code up an fseeko/ftello for BSD/OS
and add that to /port. No reason to hold up beta for that, though.
I wonder if any other platforms have this limitation. I think we need
to add some type of test for no-fseeko()/ftello() and sizeof(off_t)
sizeof(long).
Hi everyone,
Thanks to Diogo Biazus [EMAIL PROTECTED], the Brazilian Portuguese
translation of the PostgreSQL Advocacy and Marketing site is now
completed and ready for public use:
http://advocacy.postgresql.org/?lang=br
:-)
Wow, that's 6 languages already, and more are coming along.
Am very,
Is there any way to prevent superuser to acces the
database ?
I mean something like "GRANT /
REVOKE CONNECT" MECHANISM
I have no idea how to prevent root from access data
in one of this ways :
root @ linux:~#su
- postgres
postgres @
linux:/usr/local/pgsql/bin$pg_dump
or
edit
On Tue, Oct 22, 2002 at 17:05:38 +0200,
Igor Georgiev [EMAIL PROTECTED] wrote:
Is there any way to prevent superuser to acces the database ?
I mean something like GRANT / REVOKE CONNECT MECHANISM
I have no idea how to prevent root from access data in one of this ways :
root @
edit *pg_hba.conf *
# Allow any user on the
local system to connect to any
# database under any
username, but only via an IP connection:
host
all
127.0.0.1 255.255.255.255
trust
# The same, over
Unix-socket connections:
local
all
trust
what about reading pg_hba.conf
On Tue, 22 Oct 2002, Igor Georgiev wrote:
edit *pg_hba.conf *
# Allow any user on the local system to connect to any
# database under any username, but only via an IP connection:
host all 127.0.0.1 255.255.255.255trust
On Tue, 22 Oct 2002, Igor Georgiev wrote:
edit *pg_hba.conf *
# Allow any user on the local system to connect to any
# database under any username, but only via an IP connection:
host all 127.0.0.1 255.255.255.255trust
#
They can just read the raw database files as
well.
wow I'm not sure
how about this
edit pg_hba.conf
# Allow any user on the local system to connect to
any # database under any
username
local
all
trust
su - posgres
psql test -U dba
or
pg_dump test
You have to be able to
Igor Georgiev [EMAIL PROTECTED] writes:
Ok, but my question actually isn't about pg_hba.conf comments, i read enough
but what will stop root from adding this lines or doing su - postgres ??
As somebody already pointed out, you *must* trust the people with root
access to your machine; there is
Next your going to ask what will stop root
from stopping your PostgreSQL, compiling a second copy with
authentication disabled and using your data directory as it's source
:)
He he i'm enough paranoic :))
If you want to prevent root from
accomplishing these things, you're going to have
65 matches
Mail list logo