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.
>
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 we
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 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
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
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 wonderin
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). Th
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 ve
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
"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 th
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
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
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
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 th
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
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.
>
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
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 pro
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 co
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 alre
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'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 su
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-live
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
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
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
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
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 periodicall
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 o
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_SOU
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.
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
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
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 stor
> > 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
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 an
> 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 Datat
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;
> > EN
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 pa
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
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 every
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 ma
Tom Lane wrote:
> 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
> >
> 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 h
"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; ther
> 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 -
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
>
> 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-sock
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 a
> 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 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 PostgreSQ
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 @ l
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
e
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
---
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 rel
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
sugges
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 supporte
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'
> gmak
On Tue, Oct 22, 2002 at 10:21:08AM +0200, Michael Paesold wrote:
> Although I am not a hacker, I think you just need to upgrade
> bison to version 1.75 if you want to build from CVS. The ecpg
1.50 would do as well.
> interface is broken with version 1.35 of bison.
Let's say ecpg grammar broke b
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
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?
--
{124,66
%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 `/spool/home/teodor/pgsql/
At 09:52 PM 21/10/2002 -0400, Bruce Momjian wrote:
4) pg_restore -Fc
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 backup.
64 matches
Mail list logo
