Sounds like good reason to get it in early... :)
It would be nice if there were some tests for this/that used this...
wasn't there a patch for that floating around somewhere?
On Sat, Jan 20, 2007 at 05:11:25PM -0500, Bruce Momjian wrote:
What are people's opinions on this patch? (It is at
Tom Lane wrote:
AFAICT, every buildfarm machine that runs ecpg tests has been failing
since Peter's patch here:
http://archives.postgresql.org/pgsql-committers/2007-01/msg00241.php
Now it looks to me like Peter was simply wrong: we do need to include
libpq because libecpg depends on it.
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
... However, I tried reverting the
change and things still did not work. The reason is that the test
programs are built with relative paths to libpq that look like
../../../../../src/interfaces/libpq/libpq.sl.5
This is a symptom
Tom Lane [EMAIL PROTECTED] writes:
So I'm thinking that the pg_am columns amorderstrategy and amdescorder are
redundant and should be replaced with a simple boolean, amcansort perhaps.
Any objections?
Any chance of getting rid of the remaining inter-operator relationship columns
in
On Sun, Jan 21, 2007 at 09:39:32AM +, Gregory Stark wrote:
I guess it's tricky since there may be operators which have valid negators and
commutators but which don't get used by any btree operator class. Does
Postgres actually make use of the oprcom and oprnegate in that case? Could
they
Russell Smith wrote:
Strange idea that I haven't researched, Given Vacuum can't be run in a
transaction, it is possible at a certain point to quit the current
transaction and start another one. There has been much chat and now a
TODO item about allowing multiple vacuums to not starve small
On Sat, 2007-01-20 at 09:41 +1100, Russell Smith wrote:
Darcy Buskermolen wrote:
[snip]
Another thought, is it at all possible to do a partial vacuum? ie spend
the
next 30 minutes vacuuming foo table, and update the fsm with what hew have
learned over the 30 mins, even if we
On Sun, Jan 21, 2007 at 12:24:38PM +, Simon Riggs wrote:
Partial vacuum would still be possible if you remembered where you got
to in the VACUUM and then started from that same point next time. It
could then go to the end of the table and wrap back around.
ISTM the Dead Space Map would
On Fri, 2007-01-19 at 15:12 -0500, Merlin Moncure wrote:
The missing piece of the puzzle is the ability to recover a failed
transaction without issuing a full commit/rollback.
Agreed.
AFAIK all other RDBMS interpret the SQL Standard to mean that a
statement can fail with an ERROR, then
On Sun, 2007-01-21 at 08:36 +0100, Peter Eisentraut wrote:
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Neil Conway wrote:
The regression.diffs are attached. Note that this reproduces
consistently, but only occurs if I use the runtest Makefile
target (i.e. run the
On 1/21/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2007-01-19 at 15:12 -0500, Merlin Moncure wrote:
The missing piece of the puzzle is the ability to recover a failed
transaction without issuing a full commit/rollback.
Agreed.
I'd like to see a TODO item to allow an *option* to be set
Martijn van Oosterhout kleptog@svana.org writes:
You have operators like contains and is contained by which would be
opposites of eachother, but could never be used in a b-tree class.
A quick count shows that 46% of the entries in pg_operator that have an
oprcom link are not in any btree
Jaime Casanova [EMAIL PROTECTED] writes:
On 1/21/07, Simon Riggs [EMAIL PROTECTED] wrote:
- continue on error i.e. COMMIT can/might succeed - though there are
still cases where it cannot, such as a serializable exception.
and what should be the behaviour of that? the same as rollback?
The
I'd like to see a TODO item to allow an *option* to be set to choose
between these two transactional behaviours.
- abort on error
- continue on error i.e. COMMIT can/might succeed - though there are
still cases where it cannot, such as a serializable exception.
That's a major change I
Joshua D. Drake [EMAIL PROTECTED] writes:
At a minimum we need to stop forcing a rollback just because we have a
syntax error. It makes development a complete pain in the butt and is
one of the most, WTF looks I get when I am training.
postgres=# begin;
BEGIN
postgres=# create table foo
On Sun, Jan 21, 2007 at 11:39:45AM +, Heikki Linnakangas wrote:
Russell Smith wrote:
Strange idea that I haven't researched, Given Vacuum can't be run in a
transaction, it is possible at a certain point to quit the current
transaction and start another one. There has been much chat and
I complained about how:
The query is
SELECT p1.opcname, p1.opcfamily
FROM pg_opclass AS p1
WHERE NOT EXISTS(SELECT 1 FROM pg_amop AS p2
WHERE p2.amopfamily = p1.opcfamily
AND binary_coercible(p1.opcintype, p2.amoplefttype));
and investigation showed
I've found a situation that causes DROP FUNCTION to fail (tested
in 8.1.6, 8.2.1, and 8.3devel):
CREATE TABLE foo (id integer);
CREATE FUNCTION foofunc() RETURNS trigger AS $$
BEGIN
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
Then in concurrent sessions:
A: BEGIN;
A: CREATE TRIGGER footrig
Michael Fuhr [EMAIL PROTECTED] writes:
I've found a situation that causes DROP FUNCTION to fail (tested
in 8.1.6, 8.2.1, and 8.3devel):
Ugh ... I haven't traced this through in detail, but I'm pretty sure
the problem arises from the fact that dependency.c traces through
auto/internal
19 matches
Mail list logo
