I wrote:
> ... but I suddenly fear that we've missed a fundamental point about
> pg_clog truncation. And WAL wraparound for that matter. To wit, a
> sufficiently long-lived temp table could contain old XIDs, and there's
> no way for anyone except the owning backend to clean them out, or even
> gu
On 13-Jan-07, at 7:24 PM, Tom Lane wrote:
Jignesh Shah <[EMAIL PROTECTED]> writes:
The appserver is basically using bunch of prepared statements that
the
server should be executing directly without doing the parsing again.
Better have another look at that theory, because you're clearly
s
Jignesh Shah wrote:
> The appserver is basically using bunch of prepared statements that the
> server should be executing directly without doing the parsing again.
>
The first thing you need to do is turn on statement logging, if you
haven't already, to verify this statement.
cheers
andrew
---
Jignesh Shah <[EMAIL PROTECTED]> writes:
> The appserver is basically using bunch of prepared statements that the
> server should be executing directly without doing the parsing again.
Better have another look at that theory, because you're clearly spending
a lot of time in parsing (operator res
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> But this fails because CopyErrorData() complains by way of assertion
> that we're still in ErrorContext. A nearby comment suggests to switch
> away to another context to preserve the data across FlushErrorState(),
> but that doesn't seem necessary
On Fri, Jan 12, 2007 at 07:33:05PM -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > Some feedback from initial testing is that 2 queues probably isn't
> > enough. If you have tables with 100s of blocks and tables with millions
> > of blocks, the tables in the mid-range still lose out. So I'
Hello All,
I am using the latest 8.2 source that I compiled with Sun Studio 11 and
tested it on Solaris 10 11/06 against an app server. I find that the CPU
utilization was higher than I expected and started digging through it.
Aparently the top CPU usage comes from the following stack trace w
I'm trying to use the PG_TRY/PG_CATCH exception handling:
bool
xml_is_document(xmltype *arg)
{
boolresult;
xmlDocPtr doc;
PG_TRY();
{
doc = xml_parse((text *) arg, true, true);
result = true;
}
PG_CA
Tom Lane <[EMAIL PROTECTED]> wrote:
Really? Wow, *that's* an interesting thought. Is it likely that that
temp table could contain many-hour-old data?
Certainly...our connection pool used by jboss can have connections to postgres
persisting for multiple days. (We're still looking for a way to
Jeff Amiel <[EMAIL PROTECTED]> writes:
> Jan 13 08:27:26 prod-app-1 postgres[92257]: [30259-1] jboss 92257 ERROR:
> could not access status of transaction 2107200825
> Jan 13 08:27:26 prod-app-1 postgres[92257]: [30259-2] jboss 92257 DETAIL:
> could not open file "pg_clog/07D9": No such file or
On Fri, 2007-01-12 at 22:24 +, Simon Riggs wrote:
> This item was rejected by Tom, since a workaround exists
>
> Add estimated_count(*) to return an estimate of COUNT(*)
> This would use the planner ANALYZE statistics to return an estimated
> count. http://archives.postgresql.org/pgsql-hacker
Thanks, removed.
---
Simon Riggs wrote:
> These two items are complete in 8.2, IIRC
>
> Allow constraint_exclusion to work for UNIONs like it does for
> inheritance, allow it to work for UPDATE and DELETE statements, and
>
Ok-- again subscribed to hackers till your questions answered.
I think you missed some of the documentation. On the first page, click on
documentation, on that (intro) page, click on 'how it works'... it will tell
you about primary keys.
Use this script to make a test table
CREATE TABLE te
13 matches
Mail list logo
