John DeSoi wrote:
In some simple tests it seems to work OK with pgAdmin (1.8b3) on OS X.
There appears to be a pgAdmin bug when you start a debug session on a
function that has no parameters:
ERROR: syntax error at or near )
LINE 1: SELECT * FROM myschema.myfunction)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Sep 05, 2007 at 02:13:57PM +1000, Brendan Jurd wrote:
On 9/5/07, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
Am I on the right page?
Got it in one, I believe.
In that case, +1 for your proposed
Hi Dave,
On Sep 5, 2007, at 3:54 AM, Dave Page wrote:
That's odd - I cannot reproduce that on OS X using beta 4 (which
has no
important changes in the debugger over beta 3).
Can you provide a simple test case?
I'll try to come up with a simple test case and send it sometime this
On Wednesday 05 September 2007 00:06, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I get the following error during make (configure runs fine)
/usr/include/netdb.h:560: error: syntax error before =E2=80=98[=E2=80=99
to= ken
Which line of netdb.h is that exactly? I'm thinking
Is there any documentation that describes how to use the SQL
functions? Some are obvious enough, but a simple example showing a
debugging session would be helpful.
I'll add that to the README file and let you know when it's ready.
-- Korry
---(end of
I was thinking about pl/pgsql and comparing it with pl/sql function
result cache, featured in Oracle 11g - see
http://www.oracle.com/technology/oramag/oracle/07-sep/o57plsql.html
Is it possible to get pl/pgsql function result cache functionality into
PostgreSQL real soon?
Best,
Peter
Peter Manchev wrote:
I was thinking about pl/pgsql and comparing it with pl/sql function
result cache, featured in Oracle 11g - see
http://www.oracle.com/technology/oramag/oracle/07-sep/o57plsql.html
Is it possible to get pl/pgsql function result cache functionality
into PostgreSQL real soon?
Richard,
Surely memcached+pgmemcache does basically this anyway, except:
- it's not restricted to function outputs
- you can cache application objects
- you can spread your cache across multiple machines
Sure, but using memcached is far from automatic ... you'd have to roll your
own scheme
Robert Treat [EMAIL PROTECTED] writes:
On Wednesday 05 September 2007 00:06, Tom Lane wrote:
BTW, on re-reading that, it seems a tad surprising to get an error right
there --- if postgres_fe.h or anything it includes were broken, then the
build should have failed earlier. Is the failure
I have a database where I'd created a copy of pg_class in public.
pgAdmin shows that the table exists, but \d doesn't. This is because of
how pg_table_is_visible works, specifically this comment:
/*
* If it is in the path, it might still not be visible; it could be
* hidden by another relation
On Tue, 4 Sep 2007, Josh Berkus wrote:
In about 200 benchmark test runs, I don't feel like we ever came up with a
set of bgwriter settings we'd happily recommend to others. SO it's hard
for me to tell whether this is true or not.
Are you talking about 200 runs with 8.2.4 or 8.3? If you've
Greg,
Are you talking about 200 runs with 8.2.4 or 8.3?
8.2.4.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
I've committed Florian's patch, but there remain a couple of things
that need work:
* Should CSV-mode logging include the virtual transaction ID (VXID) in
addition to, or instead of, XID? There will be many situations where
there is no XID.
* As things stand, when a two-phase transaction is
There are a bunch of places where we do things like
PGPROC *proc = arrayP-procs[index];
/* Fetch xid just once - see GetNewTransactionId */
TransactionId pxid = proc-xid;
... use pxid several times ...
In the case where use
Tom Lane wrote:
* Should CSV-mode logging include the virtual transaction ID (VXID) in
addition to, or instead of, XID? There will be many situations where
there is no XID.
But will there be any where we care? Isn't the point of this to restrict
allocation of a real XID to situations
On Wed, 5 Sep 2007, Josh Berkus wrote:
Are you talking about 200 runs with 8.2.4 or 8.3?
8.2.4.
Right, then we're in agreement here. I did something like 4000 small test
runs with dozens of settings under various 8.2.X releases and my
conclusion was that in the general case, it just
Tom Lane wrote:
I've committed Florian's patch, but there remain a couple of things
that need work:
* Should CSV-mode logging include the virtual transaction ID (VXID) in
addition to, or instead of, XID? There will be many situations where
there is no XID.
Maybe make %x show both, or only the
Tom Lane wrote:
Comments? Does anyone think the C standard forbids what I'm worried
about?
My understanding of the C spec is that it explicitly *allows* for
exactly what you're afraid of. It's even possible if the uses include
function calls, as the compiler might inline the function
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
* Should CSV-mode logging include the virtual transaction ID (VXID) in
addition to, or instead of, XID? There will be many situations where
there is no XID.
But will there be any where we care? Isn't the point of this to restrict
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
This seems fairly undesirable :-( not least because you can't tell one
prepared xact from another and thus can't see which locks belong to
each. But I'm unsure what to do about it.
We could make the VXID in the gxact struct be
Brian Hurt [EMAIL PROTECTED] writes:
Note that all sorts of weirdnesses are possible when you have shared
mutable state between multiple different threads.
Yeah. In the majority of places this isn't a big problem because
access to shared memory looks like
LWLockAcquire(some_lock);
Decibel! [EMAIL PROTECTED] writes:
While this is correct on a per-relation level, I'm thinking that it's
not what we'd really like to have happen in psql. What I'd like \d to do
is show me everything in any schema that's in my search_path, even if
there's something higher in the search_path
On Mon, 2007-07-30 at 20:20 +0100, Simon Riggs wrote:
Jignesh Shah's scalability testing on Solaris has revealed further
tuning opportunities surrounding the start and end of a transaction.
Tuning that should be especially important since async commit is likely
to allow much higher
The SQL:2003 standard definition of SET TRANSACTION differs in major
ways from PostgreSQL's, which produces some interesting behaviour.
We currently claim conformance, though this is not accurate.
...
SQL2003
If a set transaction statement that does not specify LOCAL is
executed, then
Case:
i)
On Sun, Sep 02, 2007 at 01:04:04PM -0500, Kenneth Marshall wrote:
Dear PostgreSQL Hackers:
After following the hackers mailing list for quite a while,
I am going to start investigating what will need to be done
to improve hash index performance. Below are the pieces of
this project that I
On Wed, Sep 5, 2007 at 1:54 PM, in message
[EMAIL PROTECTED], Greg Smith
[EMAIL PROTECTED] wrote:
On Wed, 5 Sep 2007, Josh Berkus wrote:
While there certainly are some cases where we've heard about people whose
workloads were such that the background writer worked successfully for
them,
moving to -hackers since the patch is already in...
On Wednesday 05 September 2007 18:12, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Florian G. Pflug wrote:
So, in essence, you get the old pg_locks format back by doing
select l1.*, l2.transactionid as transaction from
Robert Treat [EMAIL PROTECTED] writes:
I'm trying to decide how reasonable the use case is. We have transactions
that
run several hours long, often touching a number of tables, and I've used the
transaction to get a list of all of the relations a given transaction is
touching. This makes
On Wednesday 05 September 2007 18:40, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'm trying to decide how reasonable the use case is. We have transactions
that run several hours long, often touching a number of tables, and I've
used the transaction to get a list of all of the
Hi Dave,
On Sep 5, 2007, at 3:54 AM, Dave Page wrote:
That's odd - I cannot reproduce that on OS X using beta 4 (which
has no
important changes in the debugger over beta 3).
Can you provide a simple test case?
I get the same error with this:
create or replace function debug_test(out t
Tom gets credit for naming the attached patch, which is my latest attempt to
finalize what has been called the Automatic adjustment of
bgwriter_lru_maxpages patch for 8.3; that's not what it does anymore but
that's where it started.
Background on testing
-
I decided to
Robert Treat [EMAIL PROTECTED] writes:
On Wednesday 05 September 2007 18:40, Tom Lane wrote:
I don't see why you wouldn't start using the VXID for this purpose?
I'm not sure either :-) Though, it would be nice to have an easy way to see
which transactions actually modified tables.
Moving
32 matches
Mail list logo
