Hackers,
I just figured that if we let LockRelation use GetCurrentTransactionId()
then the wrong thing happens if we let large objects survive
subtransaction commit/abort. The problem is that when closing a large
object at main transaction commit, which was opened inside a
subtransaction, the
Christopher Kings-Lynne wrote:
I never really considered oracle's implementation of tablespaces when I
worked on tablespaces. The database default tablespace seems similar to
Oracle's SYSTEM tablespace. I'm not sure if they use a global tablespace
like we do.
My point was that Oracle has added a
We are already in a features freeze period, or not ?
This isn't a feature, it's a bug...
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
I hall
I have a query in this form:
empdb=# explain analyze select * from v_past_connections where id_user = 26195 and
login_time '2004-07-21';
QUERY PLAN
Also, since I checked and it seems that our syntax for putting tables an
d indexes in tablespaces at creation time is identical to oracle's,
perhaps we should copy them on constraints as well.
Since we're getting close to beta, can we have consensus on what I'm to
do about this?
The
On Fri, 23 Jul 2004, Gaetano Mendola wrote:
empdb=# explain analyze select * from v_past_connections where login_time
'2004-07-21';
QUERY PLAN
Alvaro Herrera [EMAIL PROTECTED] writes:
I just figured that if we let LockRelation use GetCurrentTransactionId()
then the wrong thing happens if we let large objects survive
subtransaction commit/abort.
So I have changed it to use GetTopTransactionId() instead. Is that OK
with everybody?
Dennis Bjorklund [EMAIL PROTECTED] writes:
In this plan it estimates to get 481 but it got 22477. So the estimation
was very wrong. You can increase the statistics tarhet on the login_time
and it will probably be better (after the next analyze).
Given the nature of the data (login times),
On Tuesday 20 July 2004 05:54, Bruce Momjian wrote:
Looks like someone else also just submitted the same patch, except with
a -T option to exclude tables. I will consider that version instead.
I can certainly see how that -T option is valuable, but I think multiple -t
options also make sense
Double postings are a PITB
- Forwarded message from elein [EMAIL PROTECTED] -
Date: Thu, 22 Jul 2004 21:31:37 -0700
From: elein [EMAIL PROTECTED]
To: Robert Treat [EMAIL PROTECTED]
Cc: Joe Conway [EMAIL PROTECTED],
elein [EMAIL PROTECTED],
David Fetter [EMAIL PROTECTED],
[EMAIL
His patch has multiple -t options and -T.
---
Andreas Joseph Krogh wrote:
-- Start of PGP signed section.
On Tuesday 20 July 2004 05:54, Bruce Momjian wrote:
Looks like someone else also just submitted the same patch,
I have some libraries that serve as libpq wrappers. One function has
the PGresult structure pointer passed to it. I'd like to be able to
determine the host name from within the function, but I don't have the
PGconn pointer to use PQhost().
Is there any workaround to this? Can I somehow pass
Ian Burrell [EMAIL PROTECTED] writes:
I posted a message a couple weeks ago abou having a problem with a
user-defined C language aggregate and the ffunc being called multiple
times with the same state. I came up with a test case which shows the
problem with plpgsql functions. It occurs
Tom Lane wrote:
So I'm rather inclined to define this behavior as not a bug. The fact
that you're complaining seems to indicate that your ffunc scribbles on
its input, which is bad programming practice in any case. Ordinarily
I would not think that an ffunc should have any problem with being
Tom Lane wrote:
So I'm rather inclined to define this behavior as not a bug. The fact
that you're complaining seems to indicate that your ffunc scribbles on
its input, which is bad programming practice in any case. Ordinarily
I would not think that an ffunc should have any problem with being
In examining the output of psql -E to get some templates for some
queries I'm developing, I noticed in describe.c that there is logic to
inform the final IN clause that gets printed for relkind but no similar
logic for the CASE clause.
Here's what I get from a \d in 7.4.1:
SELECT n.nspname as
Ian Burrell [EMAIL PROTECTED] writes:
We are doing things in the aggregates that make them troublesome when
called the ffunc is called multiple times. The state structure uses a
lot of memory for intermediate work. The memory needs to be freed as
soon as possible otherwise there is a
Thomas F.O'Connell [EMAIL PROTECTED] writes:
I realize this is a trivial issue, but it seems like logic could be
added to the CASE statement to prevent irrelevant SELECT material from
being output.
Hardly seems worth the trouble ...
regards, tom lane
I know, but I don't get too many opportunities to contribute... :)
Just figured I'd mention it.
-tfo
On Jul 23, 2004, at 4:06 PM, Tom Lane wrote:
Thomas F.O'Connell [EMAIL PROTECTED] writes:
I realize this is a trivial issue, but it seems like logic could be
added to the CASE statement to prevent
Christopher Kings-Lynne wrote:
Also, since I checked and it seems that our syntax for putting
tables an d indexes in tablespaces at creation time is identical to
oracle's, perhaps we should copy them on constraints as well.
Since we're getting close to beta, can we have consensus on what
20 matches
Mail list logo
