On Thu, Jun 14, 2001 at 01:42:26PM -0400, Tom Lane wrote:
> Also note that we could easily fix things so that the max-number-of-
> backends limit is not checked until we have passed the authentication
> procedure. A PM child that's still busy authenticating doesn't have
> to count.
And impose a
On Fri, Jun 15, 2001 at 10:21:37AM -0400, Tom Lane wrote:
> "Dave Cramer" <[EMAIL PROTECTED]> writes:
> > I had no idea that xmin even existed, but having a quick look I think this
> > is what I am looking for. Can I assume that if xmin has changed, then
> > another process has changed the underly
Tom Lane <[EMAIL PROTECTED]> writes:
> Manuel Sugawara <[EMAIL PROTECTED]> writes:
> > [ vacuum analyze dies ]
> > It is running on Redhat Linux 7.1 i686 with 2.4.2-2 kernel.
> > Here is the back trace from gdb
>
> > (gdb) bt
> > #0 strcoll () at strcoll.c:229
>
> We've heard reports before of
Manuel Sugawara <[EMAIL PROTECTED]> writes:
> [ vacuum analyze dies ]
> It is running on Redhat Linux 7.1 i686 with 2.4.2-2 kernel.
> Here is the back trace from gdb
> (gdb) bt
> #0 strcoll () at strcoll.c:229
We've heard reports before of strcoll() crashing on apparently valid
input. It seems
"Dave Cramer" <[EMAIL PROTECTED]> writes:
> Can the version # of
> the row be made available to the client?
There is no "version # of the row" in postgres, unless you set up such a
thing for yourself (which could certainly be done, using triggers).
regards, tom lane
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Whatever you do, please wait till I've finished the "authenticate after
> fork" change. (this weekend?)
Oh, are you doing that? I thought you weren't convinced it was a good
idea ...
regards, tom lane
-
On Fri, 15 Jun 2001, Vince Vielhaber wrote:
> On Fri, 15 Jun 2001, Tom Lane wrote:
>
> > Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > >> More to the point, how does the postmaster know that it's now dealing
> > >> with encrypted passwords and must use the double-salt auth method?
> >
> > > The
On Fri, 15 Jun 2001, Tom Lane wrote:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> >> More to the point, how does the postmaster know that it's now dealing
> >> with encrypted passwords and must use the double-salt auth method?
>
> > The first three characters are md5 in the code I sent Bruce.
Vince Vielhaber <[EMAIL PROTECTED]> writes:
>> More to the point, how does the postmaster know that it's now dealing
>> with encrypted passwords and must use the double-salt auth method?
> The first three characters are md5 in the code I sent Bruce.
Uh ... so if I use a password that starts with
On Fri, 15 Jun 2001, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > People have complained that we store passwords unencrypted in pg_shadow.
> > Long ago we agreed to a solution and I am going to try to implement that
> > next.
>
> Whatever you do, please wait till I've finished the "aut
Can someone point me in the direction of any documentation related to
client/backend protocol. If it's use the source, that's ok too.
Dave
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unr
On Fri, Jun 15, 2001 at 10:22:53AM -0400, Tom Lane wrote:
> What PG version? Do you have any open transactions that might have
> created or deleted as-yet-uncommitted tables?
I'm not sure since this has not happened on my system. Sorry, I wasn't
precise enough. It happens on the system of a co-w
On Fri, 15 Jun 2001, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think the script idea may be best but it will have to be saved
> > somewhere so once you run it all future password changes are encrypted
> > in pg_shadow.
>
> More to the point, how does the postmaster know th
Tom,
I am considering coding this into postgres's jdbc driver, as there are alot
of requests for updateable rowsets. I really don't want to code this in;
only to have it break later. Is there a way to do this? Can the version # of
the row be made available to the client?
Dave
- Original Mes
On Fri, 15 Jun 2001, Bruce Momjian wrote:
> > > Migrating old sites to encrypted pg_shadow passwords should be easy if a
> > > trigger on pg_shadow will look for unencrypted INSERTs and encrypt them.
> >
> > If encrypting pg_shadow will break the old-style crypt method, then I
> > think forcing a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think the script idea may be best but it will have to be saved
> somewhere so once you run it all future password changes are encrypted
> in pg_shadow.
More to the point, how does the postmaster know that it's now dealing
with encrypted passwords and
Michael Meskes <[EMAIL PROTECTED]> writes:
> Could anyone please tell me what the following mean:
> NOTICE: Index pg_type_typname_index: NUMBER OF INDEX' TUPLES (124) IS NOT THE SAME
>AS HEAP' (114)
> NOTICE: Index pg_attribute_attrelid_index: NUMBER OF INDEX' TUPLES (883) IS NOT THE
>SAME AS
"Dave Cramer" <[EMAIL PROTECTED]> writes:
> I had no idea that xmin even existed, but having a quick look I think this
> is what I am looking for. Can I assume that if xmin has changed, then
> another process has changed the underlying data ?
xmin is a transaction ID, not a process ID, but lookin
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The problem is for older clients. Do I need to create a new encryption
> type for this double-encryption? Seems we do.
Hmm ... AFAIR that old discussion, backwards compatibility was not
thought about at all :-(
> The bigger problem is how usernames e
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
>> If the last parameter is set to SQL_NULL_DATA, then that means that the
>> last parameter is NULL. That means that the query must be rewritten by
>> the driver to "IS NULL" instead of "= NULL". Unfortunately, it *appears*
>> our ODBC driver doesn't do
already fixed ...
On Fri, 15 Jun 2001, Oleg Bartunov wrote:
> Marc,
>
> when I try to reach http://fts.postgresql.org/ I see
> http://www.hub.org/
>
> what's happens ?
>
> Regards,
> Oleg
> _
> Oleg Bartunov, sci.re
Could anyone please tell me what the following mean:
NOTICE: Index pg_type_typname_index: NUMBER OF INDEX' TUPLES (124) IS NOT THE SAME AS
HEAP' (114)
NOTICE: Index pg_attribute_attrelid_index: NUMBER OF INDEX' TUPLES (883) IS NOT THE
SAME AS HEAP' (422)
I've never seen them before.
Michae
Stuart,
I had no idea that xmin even existed, but having a quick look I think this
is what I am looking for. Can I assume that if xmin has changed, then
another process has changed the underlying data ?
Dave
- Original Message -
From: "Henshall, Stuart - WCP" <[EMAIL PROTECTED]>
To: "'Da
Don't know about JDBC, but couldn't you just use UPDATE SET
= WHERE xmin= AND primarykey= and
get the number of altered records? (if its zero then you know somethings
wrong and can investigate further)
- Stuart
> -Original Message-
> From: Dave Cramer [SMTP:[EMAIL PROTECTED]]
> Sent: Thu
24 matches
Mail list logo
