Tom Lane [EMAIL PROTECTED] writes:
Orion Henry [EMAIL PROTECTED] writes:
It appears to be faulting on a kerberos call which is odd because I
don't use kerberos for anything.
I was a bit surprised to realize that if you compile Kerberos support at
all, libpq will try to get a user name
The attached tiny patch (not intended for application yet) provides a
space for plperl functions to create and share session persistent data,
which I should think would increase the utility of plperl. Essentially
it creates a hash called %session_globals which it then injects into the
safe
I wrote:
The attached tiny patch (not intended for application yet) provides a
space for plperl functions to create and share session persistent
data, which I should think would increase the utility of plperl.
Essentially it creates a hash called %session_globals which it then
injects into
What about transactions? Let's say the first call was in a transaction
that's been rolled back. Semantically, that means the call never happened.
If you maintain the session data in a table, everything is fine of course.
But if it's in memory the solution has some rather nasty implications to it.
Nigel J. Andrews [EMAIL PROTECTED] writes:
On Sat, 7 Feb 2004, Alex J. Avriette wrote:
... or somebody may be passing in the
de rigeur '; select * from sensitive_table; ...' attempts (this is very
common, as you know, in CGI applications).
Actually I can and it involves changing the backend
Greg Stark [EMAIL PROTECTED] writes:
In fact I think there's something a little backwards about deciding on a
default username in advance and then trying various authentication methods.
Perhaps, but we're stuck with that without a massive (and non backwards
compatible) redesign of the
Thomas Hallgren [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] wrote:
The attached tiny patch (not intended for application yet) provides a
space for plperl functions to create and share session persistent data,
What about transactions?
AFAICS, Andrew is just emulating a feature
Alex J. Avriette wrote:
I feel that it would be a very good thing if some thinking on this
subject was done. In the future, people will hopefully begin using
postgres for more intense applications. We are looking at perhaps many
tens of billions of transactions per day within the next year or
As Tom Lane noted, pltcl already allows this. In fact, it appears that
plperl already allows functions to create their own session-persistent
data, but doesn't share data between functions.
I guess there's a philosophical question: should we apply transactional
safety to (transient) data not
I'm not insisting anything. I merely suggest something that all pllang
implementations would have a potential benefit from.
But perhaps I should insist. Both with respect to plperl, pltcl, or any
other pllang where session data is possible. IMHO, session data spanning
more than one transcation
On Sun, Feb 08, 2004 at 08:07:14PM +0100, Andreas Pflug wrote:
I feel that it would be a very good thing if some thinking on this
subject was done. In the future, people will hopefully begin using
postgres for more intense applications. We are looking at perhaps many
tens of billions of
While reviewing Andrew Dunstan's patch that implements the
log_disconnections GUC var, I noticed that tab-complete.c in psql
claims that only USERSET and possibly SUSET GUC variables should be
included in the list of variables that can be auto-completed.
That policy is clearly not followed:
Tom Lane
Manfred's numbers definitely say that we need to find a way to break
down the BufMgrLock into multiple finer-grain locks. We already have
all those per-buffer LWLocks, but I don't see how to apply those to
the problem of managing the global lookup and replacement
datastructures.
On Sun, Feb 08, 2004 at 01:33:31PM -0500, Tom Lane wrote:
Actually I can and it involves changing the backend to not permit multiple
statements in one request. I can't imagine how that could sensibly be
implemented, if at all, though.
Actually, the extended-query message in the new FE/BE
The fact is, there are situations in which such extreme traffic is
warranted. My concern is that I am not able to use postgres in such
situations because it cannot scale to that level. I feel that it would
be possible to reach that level with support in the postmaster for
replication.
On Sun, Feb 08, 2004 at 08:01:38PM -0500, Rod Taylor wrote:
Replication won't help if those are all mostly write transactions. If a
small percentage, even 1% would be challenging, is INSERTS, UPDATES or
DELETES, master / slave replication might get you somewhere.
There is no way on earth we
On Sun, 2004-02-08 at 21:01, Alex J. Avriette wrote:
On Sun, Feb 08, 2004 at 08:01:38PM -0500, Rod Taylor wrote:
Replication won't help if those are all mostly write transactions. If a
small percentage, even 1% would be challenging, is INSERTS, UPDATES or
DELETES, master / slave
replication. Am I hearing that nobody believes scalability is a
concern? I think many of us would like to see features that would
allow large scale installations to be more practical. I also think most
of us would agree that the current graft-on replication methods are
sub-ideal.
You really
Alex J. Avriette [EMAIL PROTECTED] writes:
On Sun, Feb 08, 2004 at 01:33:31PM -0500, Tom Lane wrote:
Actually, the extended-query message in the new FE/BE protocol works
exactly that way.
(Tom is referring to this:
http://archives.postgresql.org/pgsql-interfaces/2003-03/msg00017.php)
Neil Conway [EMAIL PROTECTED] writes:
While reviewing Andrew Dunstan's patch that implements the
log_disconnections GUC var, I noticed that tab-complete.c in psql
claims that only USERSET and possibly SUSET GUC variables should be
included in the list of variables that can be auto-completed.
Bruce Momjian [EMAIL PROTECTED] writes:
Edwin S. Ramirez wrote:
Hello,
Is is possible to change the transaction behaviour not to abort when a
syntax error occurs.
I've done some searches on the list, and have not found anything.
No, we need nested transactions for that. We are
On Mon, 8 Feb 2004, Greg Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Edwin S. Ramirez wrote:
Hello,
Is is possible to change the transaction behaviour not to abort when a
syntax error occurs.
I've done some searches on the list, and have not found anything.
No,
Greg Stark [EMAIL PROTECTED] writes:
But why does the database enforce that every syntax error *requires* a
transaction roll back?
PG enforces that every error requires a transaction abort. Period, full
stop. Picking and choosing which errors might not really require a
rollback involves a
Recently, I was surprised to learn that psql variables are case
sensitive. Furthermore, there is no error when one attempts to '\set'
a non-existent variable (arguably for good reason: I suppose it's too
late now to get rid of user-defined psql variables). That leads to
confusing situations like
Neil Conway [EMAIL PROTECTED] writes:
Recently, I was surprised to learn that psql variables are case
sensitive. Furthermore, there is no error when one attempts to '\set'
a non-existent variable (arguably for good reason: I suppose it's too
late now to get rid of user-defined psql variables).
On Sun, Feb 08, 2004 at 09:20:07PM -0500, Rod Taylor wrote:
On Sun, 2004-02-08 at 21:01, Alex J. Avriette wrote:
On Sun, Feb 08, 2004 at 08:01:38PM -0500, Rod Taylor wrote:
Replication won't help if those are all mostly write transactions. If a
small percentage, even 1% would be
Andrew Dunstan [EMAIL PROTECTED] writes:
Comments welcome. Reviewers: I am not sure I got multi-byte stuff right
in psql/mainloop.c - please pay close attention to that.
The i-1 stuff should generally be i-prevlen. Not sure if there are any
other pitfalls.
A bigger problem here:
+
Hello all!
I've been eyeing providing links between the previously separated
documentation books, e.g., linking this sentence Please familiarize
yourself with the pg_dump reference page. in the backup and restore
section http://www.postgresql.org/docs/current/static/backup.html to
the
Michael Glaesemann [EMAIL PROTECTED] writes:
I've been eyeing providing links between the previously separated
documentation books, ...
Is anyone else working on something like this? Is it worthwhile?
There's been talk of this earlier, but I don't recall anyone specifically
saying they'd
On Feb 9, 2004, at 2:16 PM, Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
I've been eyeing providing links between the previously separated
documentation books, ...
Is anyone else working on something like this? Is it worthwhile?
There's been talk of this earlier, but I don't
30 matches
Mail list logo
