> What are the benefits of SASL+Postgresql compared to Postgresql over plain SSL?
SASL is orthogonal to SSL. SASL is an application-layer library
and can be run over either regular sockets or SSL. However there
are SASL hooks to tell it that it's running over a secure channel.
The anticipated
Another set of SSL patches have been sent to the patches list.
(No idea when they'll get through the system.) This is a new
baseline set of patches that fix many of the problems identified
earlier and also add a number of security patches.
N.B., some of these changes are visible to the user, but
What are the benefits of SASL+Postgresql compared to Postgresql over plain SSL?
Coz Postgresql already supports SSL right?
Cheerio,
Link.
At 03:11 PM 5/18/02 -0600, Bear Giles wrote:
>If it's being used in Sendmail, Cyrus IMAP and OpenLDAP, with preliminary
>work (sponsored by Carnegie Mellon U
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
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,
"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
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:
bt_getroot[billed_features_btn_idx
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 relati
> > 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 SSL_g
> -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 al
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 t
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
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 us
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
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 broadcast)
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 coul
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
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 a
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. Howev
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
20 matches
Mail list logo
