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 F
> > 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
>
> > 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 point
Tom Lane wrote:
In the meantime, to tell you the truth, the cleanest way to handle the
dblink regression test would be to make it circularly connect to
database "regression". I know this seems cheesy, but as long as the
software under test doesn't know that it's a connection-to-self, seems
like t
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;
> [...]
> ' LANGUAGE 'plpgsq
Tom Lane wrote:
> We can go with the auto-COMMIT idea for statements that are invoked at
> the outer interactive level, but that doesn't work for stuff invoked
> inside a function. I think we need to forbid these statements inside
> functions, too. We already have that for VACUUM, because of its
Hello hackers,
I've been toying around with freelist in btrees, getting lots of
deadlocks and bootstrap problems. I think I've learned something about
the code, though. Just for the record: I already read Lehman and Yao's
paper and I think I grok it.
There's few ideas I'd like to present and ge
On Mon, 2002-10-21 at 20:52, Bruce Momjian wrote:
> Larry Rosenman wrote:
> > On Mon, 2002-10-21 at 20:47, Bruce Momjian wrote:
> > >
> > > Here is a modified version of Philip's patch that has the changes Tom
> > > suggested; treating off_t as an integral type. I did light testing on
> > > my B
Larry Rosenman wrote:
> On Mon, 2002-10-21 at 20:47, Bruce Momjian wrote:
> >
> > Here is a modified version of Philip's patch that has the changes Tom
> > suggested; treating off_t as an integral type. I did light testing on
> > my BSD/OS machine that has 8-byte off_t but I don't have 4 gigs of
On Mon, 2002-10-21 at 20:47, Bruce Momjian wrote:
>
> Here is a modified version of Philip's patch that has the changes Tom
> suggested; treating off_t as an integral type. I did light testing on
> my BSD/OS machine that has 8-byte off_t but I don't have 4 gigs of free
> space to test larger fil
Here is a modified version of Philip's patch that has the changes Tom
suggested; treating off_t as an integral type. I did light testing on
my BSD/OS machine that has 8-byte off_t but I don't have 4 gigs of free
space to test larger files.
ftp://candle.pha.pa.us/pub/postgresql/mypatch
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Perhaps RESET AUTOCOMMIT is a good enough answer?
>
> > I was unclear on that. RESET sets it back to the postgresql.conf value,
> > right? Do we know that the session didn't change it earlier in the
> > script?
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Perhaps RESET AUTOCOMMIT is a good enough answer?
> I was unclear on that. RESET sets it back to the postgresql.conf value,
> right? Do we know that the session didn't change it earlier in the
> script? That's where it gets tricky.
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.
---
P O S T G R E S Q L
7
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > One particularly nasty problem is issuing a VACUUM or TRUNCATE in cases
> > where you don't know the autocommit mode. You could set autocommit to
> > 'on', and issue the command, but how do you know if you need to turn
> > autocommit
Bruce Momjian <[EMAIL PROTECTED]> writes:
> One particularly nasty problem is issuing a VACUUM or TRUNCATE in cases
> where you don't know the autocommit mode. You could set autocommit to
> 'on', and issue the command, but how do you know if you need to turn
> autocommit back off again?
Perhaps R
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> Maybe we can throw a WARNING when autocommit is on. Would that make
> >>> everyone happy?
> >>
> >> I doubt it, because by the time you read the WARNING it's too la
Hi everyone,
Thanks to Cornelia Boenigk <[EMAIL PROTECTED]> and Michael
Paesold <[EMAIL PROTECTED]>, the German translation of the PostgreSQL
"Advocacy and Marketing" site, is now completed and ready for public
use:
http://advocacy.postgresql.org/?lang=de
This makes 5 languages done, with Brazil
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> Maybe we can throw a WARNING when autocommit is on. Would that make
>>> everyone happy?
>>
>> I doubt it, because by the time you read the WARNING it's too late:
>> the statement's already
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Maybe we can throw a WARNING when autocommit is on. Would that make
> > everyone happy?
>
> I doubt it, because by the time you read the WARNING it's too late:
> the statement's already committed.
I assume the same limitation would
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Maybe we can throw a WARNING when autocommit is on. Would that make
> everyone happy?
I doubt it, because by the time you read the WARNING it's too late:
the statement's already committed.
regards, tom lane
Tom Lane wrote:
> >>> ... I think we
> >>> should just do an automatic COMMIT if it is the first statement of a
> >>> transaction, and if not, throw the same error we used to throw. We are
> >>> performing autocommit for SET at the start of a transaction now anyway,
> >>> so it isn't totally stran
>>> ... I think we
>>> should just do an automatic COMMIT if it is the first statement of a
>>> transaction, and if not, throw the same error we used to throw. We are
>>> performing autocommit for SET at the start of a transaction now anyway,
>>> so it isn't totally strange to do it for TRUNCATE,
On Mon, 30 Sep 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I get on postgresql.org on a previously checked out CVS:
>
> > $ cvs -q -d :pserver:[EMAIL PROTECTED]:/cvsroot checkout -P pgsql
> > cvs checkout: move away pgsql/contrib/earthdistance/Makefile; it is in the way
>
Hi Tom,
I can assure you that there are no problem anymore now that I have put the
password.
However the modification pg_hba.conf has been done a few days ago and
never noticed the error until today where I had a *LOT* of visits to my
site.
So I still think it's a matter of bad connection delay.
Thanks for your reply.
Actually, I just found xhat happened 2 mn ago!
Last week I changed my pg_hba.conf to require an md5 password for one
specific database and updated all my script but ONE.
It seems that connection from php pg_connect not supplying a password
lives the process for a "certain
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There are a number of statements, such as TRUNCATE TABLE, that refuse to
>> run in a transaction block because they perform actions that can't be
>> rolled back later.
>>
>> These statements currently do not look at autocommit, which m
On Mon, 2002-10-21 at 12:39, Olivier PRENANT wrote:
> Hi larry,
>
> Glad to see you around...
> On 21 Oct 2002, Larry Rosenman wrote:
>
> > Date: 21 Oct 2002 12:34:48 -0500
> > From: Larry Rosenman <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: Tom Lane <[EMAIL PROTECTED]>,
> > pgsql-
Doug McNaught wrote:
Solved the halting problem lately? ;)
nah -- I'll leave that as an exercise for the reader ;-)
Someone determined to DoS could probably get around any practical
implementation of your idea, using dummy argument, mutual recursion or
whatever.
I see your point. I guess a
"Steve Wolfe" <[EMAIL PROTECTED]> writes:
> On the recurring debate of threading vs. forking, I was giving it a fwe
> thoughts a few days ago, particularly with concern to Linux's memory model.
>
> On IA32 platforms with over 4 gigs of memory, any one process can only
> "see" up to 3 or 4 gig
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> > A depth limit for PL-function recursion is perhaps feasible, but I can't
> > say that I care for it a whole lot ... anyone have better ideas?
> >
>
> Is there any way to recognize infinite recursion by analyzing the
> saved execution tr
On Monday 21 October 2002 15:42, Olivier PRENANT wrote:
> Hi all,
>
> Without modifying anything, postgresql (since today) has a strange
> behavior:
>
> All connections are rejected with No space left on device.
>
> There's plenty of space in shm, disk...
I have no idea whether it's relevant, but
Michael Meskes wrote:
> On Fri, Oct 18, 2002 at 04:16:29PM -0400, Bruce Momjian wrote:
> > > Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
> > > by).
> >
> > I can confirm that:
>
> I just tried Marc's installation of 1.75 and compared the result with my
> 1.50 compiled v
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> There are a number of statements, such as TRUNCATE TABLE, that refuse to
> >> run in a transaction block because they perform actions that can't be
> >> rolled back later.
> >>
> >> These statements currently do n
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > let me know if there are any problems with it
>
>
> Other than the fact that it's about a factor of 16 slower than bison
> 1.28, while not offering any substantial gain in functionality? If I
> were a Bison maintainer, I'd
[ Thread moved to hackers.]
Crash reproduced here.
My guess is that you are recursing and crashing the backend, which then
forces the other backends to reset. I think we need to fix this by
either setting a limit in the amount of function recursion, or allowing
only the offending backend to cras
Olivier PRENANT <[EMAIL PROTECTED]> writes:
> pyrenet=# VACUUM ANALYZE ;
> FATAL 2: could not open transaction-commit log directory
>(/usr/local/pgsql/data/pg_clog): Too many open files
Hmm. Do you have any idea what sysconf(_SC_OPEN_MAX) returns on your
platform? You could try reducing the ma
On Mon, 2002-10-21 at 12:57, Larry Rosenman wrote:
> On Mon, 2002-10-21 at 12:39, Olivier PRENANT wrote:
> > Hi larry,
> >
> > Glad to see you around...
> > On 21 Oct 2002, Larry Rosenman wrote:
> >
> > > Date: 21 Oct 2002 12:34:48 -0500
> > > From: Larry Rosenman <[EMAIL PROTECTED]>
> > > To: [E
I've seen the idea of "user resource limits" bandied about before as a
way to address these problems; depending on implementation that might be
the way to go.
Robert Treat
On Mon, 2002-10-21 at 12:44, Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Is there any way to recognize infin
Hi Oleg (and pgsql hackers!),
Recently I encountered a problem attempting to use the integer array
function for pushing an integer onto an integer array field.
Can you write an example of a sql statement for pushing a single value onto
an integer array and for popping a specific value off of an i
On Mon, 21 Oct 2002, Tom Lane wrote:
> Date: Mon, 21 Oct 2002 12:52:10 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] Please help
>
> Olivier PRENANT <[EMAIL PROTECTED]> writes:
> > pyrenet=# VACUUM ANALYZE
Joe Conway <[EMAIL PROTECTED]> writes:
> Is there any way to recognize infinite recursion by analyzing the saved
> execution tree -- i.e. can we assume that a function that calls itself, with
> the same arguments with which it was called, constitutes infinite recursion?
A bulletproof solution wo
Hi,
I just merged the big_bison branch back into HEAD. Hopefully I did this
in the correct way. Keep in mind that I'm not really fit in using cvs.
Please test it.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
---
Tom Lane wrote:
A depth limit for PL-function recursion is perhaps feasible, but I can't
say that I care for it a whole lot ... anyone have better ideas?
Is there any way to recognize infinite recursion by analyzing the saved
execution tree -- i.e. can we assume that a function that calls itse
"D. Hageman" <[EMAIL PROTECTED]> writes:
> This in many ways is a bogus argument in that 1) postgresql runs on more
> then just Linux and 2) amount of memmory that can be addressed by a
> process is tunable up to the point that it reaches a hardware limitation.
1) The OP specifically asked abou
Olivier PRENANT <[EMAIL PROTECTED]> writes:
> It seems that connection from php pg_connect not supplying a password
> lives the process for a "certain ammount of time" running, then postmaster
> just hangs.
That's hard to believe. In 7.2 or later, the backend should give up and
close the connecti
46 matches
Mail list logo
