Bear Giles writes:
I came across another bug in the SSL code. backend/libpq/pqcomm.c:pq_eof()
calls recv() to read a single byte of data to check for EOF. The
character is then stuffed into the read buffer.
The quick fix is to add another USE_SSL block,
So it seems. Do you volunteer to
Mark kirkwood [EMAIL PROTECTED] writes:
However I could not get any size stabilization in the toasted case.
Hmm. Which file(s) were growing, exactly? How many row updates is this
run covering?
I'd rather expect the toast indexes to grow given the lack-of-btree-
collapse-logic issue.
I've been looking at the uses of scanCommandId with some suspicion.
We recently fixed a problem wherein cursors were seeing the effects
of commands started after the cursor was opened (in the same
transaction), and I think there may be more such problems. I don't
like the way that SQL functions
On Thu, May 16, 2002 at 04:51:28PM -0700, Joe Conway wrote:
make -C preproc all
make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/preproc'
bison -y -d preproc.y
conflicts: 2 reduce/reduce
Didn't notice this before. Fix was quite easy, but I also did sync
ecpg's parser with
On Fri, May 17, 2002 at 10:47:54AM -0400, Alvaro Herrera wrote:
It's not just the grammar. Last time I tried to compile OSDB to get some
benchmarking done, ecpg segfaulted on it (before having any reduce
conflict). I tried to do some investigation, but my knowledge was too
limited and
Michael Meskes [EMAIL PROTECTED] writes:
Haven't found time to dig into this. So be careful, current CVS WILL NOT
COMPILE!
If you're not going to fix it right away, would you mind reverting the
commit?
regards, tom lane
---(end of
Tom Lane wrote:
I am still concerned about whether ExecFunctionReScan works correctly;
if not, the problems would show up in join and subquery situations.
I think the parser and planner stages are in pretty good shape now,
though. (At least as far as the basic functionality goes. Having
a
I'm writing a function that accepts a table name and digs some information
out about it. I'm developing on 7.3cvs w/schemas, and wanted my function to
use schemas.
If the user gives a full schema name (s.table), I find the table in pg_class
by comparing the ns oid and relname.
However, if the
Joe Conway [EMAIL PROTECTED] writes:
Any ideas on getting (node-scan.plan.chgParam != NULL) to be true?
You need something that passes a parameter into the scan node.
I think the only thing that would do it is a subquery that references
an outer-level variable, for example
select * from foo
Joel Burton wrote:
Is there a function already in the backend to return a class oid, given a
name, by looking up the table in the current_schemas path? Would it make
sense for us to expose this, or write one, so that this small wheel doesn't
have to be re-invented everytime someone wants to
-Original Message-
From: Joe Conway [mailto:[EMAIL PROTECTED]]
Sent: Sunday, May 19, 2002 5:25 PM
To: Joel Burton
Cc: Pgsql-Hackers@Postgresql. Org
Subject: Re: [HACKERS] Exposed function to find table in schema search
list?
Joel Burton wrote:
Is there a function already in
a better fix is to explicitly create a new abstraction layer.
Well, this is supposed to be an abstraction already. ;-)
The new abstraction layer would localize SSL vs. plain sockets, and
possibly SASL as well.
The SSL issues I've identified to date are:
critical
- no check for
As I mentioned in passing awhile ago, I'm thinking of simplifying the
indexscan API and arranging for heapscans and indexscans to have
essentially identical APIs. Here's the plan:
heap_beginscan and index_beginscan will have near-identical signatures:
HeapScanDesc heap_beginscan(Relation
Hi all,
I started getting these errors today on my test database (pg
7.2.1). I have been vacuum/reindex/analyze(ing) the table
all day (after updating 10+ rows) and wondering what
could have caused this.
Thanks
Jim
2002-05-19 18:16:18 [1673] NOTICE:
Joel Burton [EMAIL PROTECTED] writes:
Is the use of regclass going to prove to be very
implementation-specific?
Sure, but so would any other API for it.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9'
Tom Lane wrote:
where kill the index entry involves informing the index AM that it can
somehow mark the index entry uninteresting and not to be returned at all
during future indexscans. (For performance reasons this'll probably get
merged into the next get next index tuple operation, but
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
where kill the index entry involves informing the index AM that it can
somehow mark the index entry uninteresting and not to be returned at all
during future indexscans.
Is this a step toward being able to VACUUM indexes?
You mean
17 matches
Mail list logo
