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.
Mo
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 u
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 tex
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 o
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
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"
>>> 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 f
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 tha
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.
...
If a that does not specify LOCAL is
executed, then
Case:
i) If an SQL-transaction is curr
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 transac
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_pa
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);
"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 stru
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 rest
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 ca
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
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 didn't
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 w
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 p
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 prep
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
http://www.postgresql.org
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 co
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 o
Hi!
I found two queries which do the same thing but they is very different in time.
For test suite it's about 10^3 times, but on real data it can be 10^5 times.
It's observed on 8.1-current, 8.2-current and CVS HEAD versions. Interesting
that even without LIMIT clause they take approximately t
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 failu
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 sche
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?
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
_
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 broa
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
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
evening.
-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
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)
>
33 matches
Mail list logo