On Tue, 2002-08-27 at 23:10, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > This should cause no problem, because we have no
> > cross-database communication; it should be impossible for "george@dummy"
> > to have any connection with database "test".
>
> Not so; you need look n
On Wed, Aug 28, 2002 at 02:53:46PM +0800, Christopher Kings-Lynne wrote:
>
> Now that we have prepared statements, should the foreign key code be changed
> to use them? I think it's highly likely that they will be reused in a
> connection. Might be an idea.
No FK, but more common is integrate
Hi,
Now that we have prepared statements, should the foreign key code be changed
to use them? I think it's highly likely that they will be reused in a
connection. Might be an idea.
Also, what if the person wants to prepare a view? Should they have to
PREPARE or should we automatically prepar
On Wed, 28 Aug 2002, Gavin Sherry wrote:
> On Tue, 27 Aug 2002, Tom Lane wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > But we should have some default to print some of the query,
> >
> > Why? So far you've been told by two different people (make that three
> > now) that such a b
That's an quite a bite to chew given my level of experience with
PostgreSQL internals! However, I will keep it in mind and whatever I do
will be fully abstracted (already is actually) so that it should just a
matter of snapping it into place when 7.4 forks. Realistically, I can't
comment from
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, patch attached. It was actually easier than I thought. We have to
> decide if we are going to remove the old syntax in 7.4.
I'd say "no". There's no compelling reason to break backward
compatibility here --- certainly a couple more productions in
Neil Conway wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > More generally, though, I was thinking that the appropriate answer
> > at this point is to rip out support for version-0 authentication
> > altogether. I can't believe anyone will be trying to connect to a
> > 7.3 or beyond server with
OK, patch attached. It was actually easier than I thought. We have to
decide if we are going to remove the old syntax in 7.4.
Regression tests pass. No doc updates yet.
---
Christopher Kings-Lynne wrote:
> > OK, no one
On Tue, 27 Aug 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > But we should have some default to print some of the query,
>
> Why? So far you've been told by two different people (make that three
> now) that such a behavior is useless, and no one's weighed in in its
> fav
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > global usernames are stored just like before, e.g. postgres
> > local users are stored as user@dbname
> > when connecting, global users add '@' to their names
> > when connecting, local users use just their user name, no @dbnam
Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > Could we then have a TODO item:
> > * Make local and global user representation consistent throughout.
>
> That's hardly an appropriately expansive TODO item. I prefer
>
> * Provide a real solution for database-local users
[EMAIL PROTECTED] (Tom Lane) wrote
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
>> I agree that a 'trimmed' query is likely to be useless, but the idea of
>> printing the query on ERROR is a big win for me:
>
> Certainly. I think though that an on-or-off GUC option is sufficient.
> We don'
OK, just go with a boolean and admins can decide if they want it.
---
Tom Lane wrote:
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> > I agree that a 'trimmed' query is likely to be useless, but the idea of
> > printin
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> More generally, though, I was thinking that the appropriate answer
>> at this point is to rip out support for version-0 authentication
>> altogether.
> Further, has this code actually been tested within recent memor
On Tue, 2002-08-27 at 17:17, Larry Rosenman wrote:
> On Tue, 2002-08-27 at 16:14, Bruce Momjian wrote:
> > Larry Rosenman wrote:
> > > > But we should have some default to print some of the query, because
> > > > right now we print none of it. I am not saying it is perfect, but it is
> > > > bette
Tom Lane <[EMAIL PROTECTED]> writes:
> More generally, though, I was thinking that the appropriate answer
> at this point is to rip out support for version-0 authentication
> altogether. I can't believe anyone will be trying to connect to a
> 7.3 or beyond server with 6.2 client libraries (v0 wen
Marc Lavergne <[EMAIL PROTECTED]> writes:
> PostgreSQL parse/bind/execute Layer:
>
> This would be mimicked since PostgreSQL doesn't support it
> natively.
What's stopping you from implementing native support for this? There
will hopefully be an FE/BE protocol
> > A settable trim length would probably be a good idea, I suppose, for
> > those slinging 'bytea' and toasted texts around.
> Yes, but the default should be NO TRIM or in 1K-4K range. IMHO
Ditto.
---(end of broadcast)---
TIP 1: subscribe and un
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> I agree that a 'trimmed' query is likely to be useless, but the idea of
> printing the query on ERROR is a big win for me:
Certainly. I think though that an on-or-off GUC option is sufficient.
We don't need a length, and we definitely don't need
Neil Conway <[EMAIL PROTECTED]> writes:
> This patch fixes the so-called DoS possibility when processing the
> password packet in recv_and_check_passwordv0().
If len is signed, then something like "len < 1" needs to be in there
as well.
More generally, though, I was thinking that the appropriate
On Tue, 2002-08-27 at 17:30, Ross J. Reedstrom wrote:
> On Tue, Aug 27, 2002 at 06:08:40PM -0400, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > But we should have some default to print some of the query,
> >
> > Why? So far you've been told by two different people (make tha
On Tue, Aug 27, 2002 at 06:08:40PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > But we should have some default to print some of the query,
>
> Why? So far you've been told by two different people (make that three
> now) that such a behavior is useless, and no one's wei
This covers a few different sub-projects so I'm breaking it down in
order of how I'm going to attack it. The TTC estimates are going to vary
based on my bandwidth which, unfortunately, is pretty tight right now.
However, there is relief on the horizon and I do have a vested interest
in getti
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> How about that --enable-multibyte?
--enable-multibyte is default (indeed only) option on CVS tip,
so that's not it. Ditto locale.
Could you try CVS tip on one of the boxes where you see the failure?
That'd help to narrow down the issue.
Oliver Elphick <[EMAIL PROTECTED]> writes:
> Could we then have a TODO item:
> * Make local and global user representation consistent throughout.
That's hardly an appropriately expansive TODO item. I prefer
* Provide a real solution for database-local users
;-)
r
Oliver Elphick <[EMAIL PROTECTED]> writes:
> This should cause no problem, because we have no
> cross-database communication; it should be impossible for "george@dummy"
> to have any connection with database "test".
Not so; you need look no further than the owner column of pg_database
to find a c
Bruce Momjian <[EMAIL PROTECTED]> writes:
> But we should have some default to print some of the query,
Why? So far you've been told by two different people (make that three
now) that such a behavior is useless, and no one's weighed in in its
favor ...
regards, tom lane
On August 27, 2002 03:39 pm, Tom Lane wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > NetBSD issue? It does it on all the NetBSD systems I tried it on.
>
> Hm. The first thing I thought was "portability problem" --- I had been
> testing on HPUX. But I just tried it on a Linux Intel
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Your patch has been added to the PostgreSQL unapplied patches list at:
Please wait for this to be reviewed.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubsc
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> pg_resetxlog uses a non-standard options parsing method: The -l option
> requires two arguments (-l fileid seg). I propose to change this to -l
> fileid,seg which is the standard way to separate suboptions.
No objection. I think pg_upgrade uses tha
On Tue, 2002-08-27 at 22:44, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > So it seems to me that you have achieved a small footprint within the
> > code, but potentially at the cost of a larger impact on users.
>
> I don't think anyone will deny that this is a kluge. However,
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Perhaps I might have been less confused if meaning (b) used a different
> character, say "username!".
Well, maybe ... but do we want to create two special characters in
usernames, instead of one? @ still has to be considered special in
incoming user
Oliver Elphick <[EMAIL PROTECTED]> writes:
> So it seems to me that you have achieved a small footprint within the
> code, but potentially at the cost of a larger impact on users.
I don't think anyone will deny that this is a kluge. However, we are
not going to resurrect the separate-password-fi
On Tue, 2002-08-27 at 22:11, Bruce Momjian wrote:
> Oliver Elphick wrote:
> > Has this behaviour been carried through into GRANT and REVOKE? If the
> > object is transparency for local users, it should be possible in
> > database "test" to say "GRANT ... TO fred" and have "fred" understood as
> >
Bruce Momjian writes:
> global usernames are stored just like before, e.g. postgres
> local users are stored as user@dbname
> when connecting, global users add '@' to their names
> when connecting, local users use just their user name, no @dbname
I'm OK with this in princ
Hello,
I tried the chkpass thing on both CVS tip and 7.2 (REL_7_2 or something
like that), and didn't see any error.
This is Linux on Intel.
(sorry, I deleted the thread by accident).
--
Alvaro Herrera ()
"El miedo atento y previsor es la madre de la seguridad" (E. Burke)
-
Scott Shattuck <[EMAIL PROTECTED]> writes:
> On Tue, 2002-08-13 at 22:42, Tom Lane wrote:
>> Scott Shattuck <[EMAIL PROTECTED]> writes:
> I'm seeing the following error about once a week or so:
> 2002-08-13 12:37:28 [24313] FATAL 1: LWLockAcquire: can't wait without
> a PROC structure
>>
>> Oh?
Bruce Momjian dijo:
> OK, no one has commented on this, so I guess I am going to have to guess
> the group's preference.
>
> My guess, seeing as very few probably use LIMIT and FOR UPDATE together,
> is to swap them and document it in the release notes. Was I correct in
> my guess?
Is it poss
Alvaro Herrera wrote:
> Bruce Momjian dijo:
>
> > OK, no one has commented on this, so I guess I am going to have to guess
> > the group's preference.
> >
> > My guess, seeing as very few probably use LIMIT and FOR UPDATE together,
> > is to swap them and document it in the release notes. Was
On Tue, 2002-08-27 at 16:14, Bruce Momjian wrote:
> Larry Rosenman wrote:
> > > But we should have some default to print some of the query, because
> > > right now we print none of it. I am not saying it is perfect, but it is
> > > better than what we have, and is a reasonable default.
> > On an e
Added:
> o Add SET SCHEMA
---
Oliver Elphick wrote:
> On Tue, 2002-08-27 at 20:25, Bruce Momjian wrote:
> >
> > Can someone explain where we are on this? Is it a TODO item?
> >
>
> > > > Would it be useful to imp
Larry Rosenman wrote:
> > But we should have some default to print some of the query, because
> > right now we print none of it. I am not saying it is perfect, but it is
> > better than what we have, and is a reasonable default.
> On an error, you may not be able to reproduce it. Why not print th
Alvaro Herrera wrote:
> Bruce Momjian dijo:
>
> > Folks, I discussed with Harald a month ago how to improve the psql \?
> > display. I have implemented his idea of mentioning '+' for the options
> > that can use it, and that is in CVS.
> >
> > His other idea is to group the backslash commands
Oliver Elphick wrote:
> > I agree with what Tom said, and understand why he said it. And I thought you
> > did, too -- I have apparently misunderstood (again!) the issue.
> >
> > In the local-enabled scheme, ISTM the majority of users will be local users.
> > The goal is transparent virtual d
On Tue, 2002-08-13 at 22:42, Tom Lane wrote:
> Scott Shattuck <[EMAIL PROTECTED]> writes:
> > I'm seeing the following error about once a week or so:
> > 2002-08-13 12:37:28 [24313] FATAL 1: LWLockAcquire: can't wait without
> > a PROC structure
>
> Oh? I'd love to see what makes this happen.
Bruce Momjian dijo:
> Folks, I discussed with Harald a month ago how to improve the psql \?
> display. I have implemented his idea of mentioning '+' for the options
> that can use it, and that is in CVS.
>
> His other idea is to group the backslash commands into sections, so they
> are not all
On Tue, 2002-08-27 at 16:05, Bruce Momjian wrote:
> Larry Rosenman wrote:
> > On Tue, 2002-08-27 at 15:54, Bruce Momjian wrote:
> > >
> > > I had an idea on this. It seems pretty pointless to show a query error
> > > without a query, but some queries are very large.
> > >
> > > How about if we
Rod Taylor wrote:
> On Tue, 2002-08-27 at 16:54, Bruce Momjian wrote:
> >
> > I had an idea on this. It seems pretty pointless to show a query error
> > without a query, but some queries are very large.
> >
> > How about if we print only the first 80 characters of the query, with
> > newlines,
On Tue, 2002-08-27 at 21:05, Lamar Owen wrote:
> On Tuesday 27 August 2002 03:43 pm, Bruce Momjian wrote:
> > Lamar Owen wrote:
> > > On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote:
> > > I thought it WAS resolved, to do:
>
> > > > Tom likes this because it is the fewer global users who
Larry Rosenman wrote:
> On Tue, 2002-08-27 at 15:54, Bruce Momjian wrote:
> >
> > I had an idea on this. It seems pretty pointless to show a query error
> > without a query, but some queries are very large.
> >
> > How about if we print only the first 80 characters of the query, with
> > newlin
On Tue, 2002-08-27 at 16:54, Bruce Momjian wrote:
>
> I had an idea on this. It seems pretty pointless to show a query error
> without a query, but some queries are very large.
>
> How about if we print only the first 80 characters of the query, with
> newlines, tabs, and spaces reduced to a si
OK, no one has commented on this, so I guess I am going to have to guess
the group's preference.
My guess, seeing as very few probably use LIMIT and FOR UPDATE together,
is to swap them and document it in the release notes. Was I correct in
my guess?
---
On Tue, 2002-08-27 at 15:54, Bruce Momjian wrote:
>
> I had an idea on this. It seems pretty pointless to show a query error
> without a query, but some queries are very large.
>
> How about if we print only the first 80 characters of the query, with
> newlines, tabs, and spaces reduced to a si
I had an idea on this. It seems pretty pointless to show a query error
without a query, but some queries are very large.
How about if we print only the first 80 characters of the query, with
newlines, tabs, and spaces reduced to a single space, and send that as
LOG to the server logs. That wou
On Tue, 2002-08-27 at 20:25, Bruce Momjian wrote:
>
> Can someone explain where we are on this? Is it a TODO item?
>
> > > Would it be useful to implement the SET SCHEMA command from SQL92? (I
> > > assume it's also in 99.)
I think it should be.
--
Oliver Elphick
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
David Van Wie wrote:
> On Thu, 22 Aug 2002, To
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, the NULL-pointer test might equally well be coded as an Assert:
> You really think it should be Assert?
I don't feel a need to change it, no. I was just pointing out that
there shouldn't be any way for a user to cause that con
Patch applied.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The exclamation point seems inappropriate. Perhaps "zero-length input"
> >> would be better than "string" also.
>
> >
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The exclamation point seems inappropriate. Perhaps "zero-length input"
> >> would be better than "string" also.
>
> > I copied the other test case:
>
> > if (s == (char *) NULL)
> > elog(ERROR, "pg_
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The exclamation point seems inappropriate. Perhaps "zero-length input"
>> would be better than "string" also.
> I copied the other test case:
> if (s == (char *) NULL)
> elog(ERROR, "pg_atoi: NULL pointer!");
Well, the
OK, we have enough votes to keep the existing behavior, unless Marc
appears and says he doesn't like it. ;-)
Thanks.
---
Rod Taylor wrote:
> It should also be noted that it's easy to get the DBAs to change their
> usernam
Lamar Owen wrote:
> On Tuesday 27 August 2002 03:43 pm, Bruce Momjian wrote:
> > Lamar Owen wrote:
> > > On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote:
> > > I thought it WAS resolved, to do:
>
> > > > Tom likes this because it is the fewer global users who have to append
> > > > the '@
Yes, this is the counter case, where the '@' disappears; so it appears
magically for local users, and disappears for global users.
---
Robert Treat wrote:
> Is the converse to this:
>
> $ psql -U postgres@ test
>
> Welco
Peter Eisentraut wrote:
> pg_resetxlog uses a non-standard options parsing method: The -l option
> requires two arguments (-l fileid seg). I propose to change this to -l
> fileid,seg which is the standard way to separate suboptions.
Agreed.
> Secondly, the -n option appears to be redundant with
Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > Sorry, that should have been:
> > Isn't it true that reindex's behavior ON A FAILURE is to simply, quietly
> > delete the index? that was reported ^
>
> No.
>
> If you are doing a standalone system index rebuild (wi
pg_resetxlog uses a non-standard options parsing method: The -l option
requires two arguments (-l fileid seg). I propose to change this to -l
fileid,seg which is the standard way to separate suboptions.
Secondly, the -n option appears to be redundant with pg_controldata. Do
we need it?
Thirdly
It should also be noted that it's easy to get the DBAs to change their
username in the future when / if the @ hack goes away BUT it will be
difficult to change the usernames of the hundreds to thousands of
customer accounts.
For an upgrade, we'd end up making a script in the upgrade to keep them
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> Sorry, that should have been:
> Isn't it true that reindex's behavior ON A FAILURE is to simply, quietly
> delete the index? that was reported ^
No.
If you are doing a standalone system index rebuild (with backend -P
switch) then REIND
On Tuesday 27 August 2002 03:43 pm, Bruce Momjian wrote:
> Lamar Owen wrote:
> > On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote:
> > I thought it WAS resolved, to do:
> > > Tom likes this because it is the fewer global users who have to append
> > > the '@'.
> > At least that was my per
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > else if (*s == 0)
> > ! elog(ERROR, "pg_atoi: zero-length string!");
>
> The exclamation point seems inappropriate. Perhaps "zero-length input"
> would be better than "string" also.
I copied the other test case:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> else if (*s == 0)
> ! elog(ERROR, "pg_atoi: zero-length string!");
The exclamation point seems inappropriate. Perhaps "zero-length input"
would be better than "string" also.
Otherwise this seems like a reasonable thing to do.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I can go either way. I am just saying we need to hear from more people
> to make sure we are doing this properly.
Likewise. In particular I'd like to hear from Marc, who after all
is the one who caused us to consider this hack in the first place.
Does
I would guess that if someone mentioned it, then it HAS happened at least
once, maybe more. Would doing it in a transaction be a good idea or not?
I'm not that familiar with the implications of doing a reindex by hand in
a transaction.
Since reindex was designed to fix broken indexes, it's
Lamar Owen wrote:
> On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote:
> > I think we need to resolve this discussion from a week ago. The current
> > code is this:
>
> I thought it WAS resolved, to do:
>
> > global usernames are stored just like before, e.g. postgres
> > local us
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On August 27, 2002 09:13 am, Tom Lane wrote:
>> Zero failures in a dozen iterations here. Anyone else see it?
> NetBSD issue? It does it on all the NetBSD systems I tried it on.
Hm. The first thing I thought was "portability problem" --- I had
On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote:
> I think we need to resolve this discussion from a week ago. The current
> code is this:
I thought it WAS resolved, to do:
> global usernames are stored just like before, e.g. postgres
> local users are stored as user@dbname
Can someone explain where we are on this? Is it a TODO item?
---
Christopher Kings-Lynne wrote:
> > Would it be useful to implement the SET SCHEMA command from SQL92? (I
> > assume it's also in 99.)
> >
> > I guess that SE
I think we need to resolve this discussion from a week ago. The current
code is this:
global usernames are stored just like before, e.g. postgres
local users are stored as user@dbname
when connecting, global users add '@' to their names
when connecting, local use
Tom Lane wrote:
> A subsidiary point here is that pg_atoi() explicitly takes a zero-length
> string as valid input of value 0. I think this is quite bogus myself,
> but I don't know why that behavior was put in or whether we'd be breaking
> anything if we tightened it up.
I have attached a patch
Folks, I discussed with Harald a month ago how to improve the psql \?
display. I have implemented his idea of mentioning '+' for the options
that can use it, and that is in CVS.
His other idea is to group the backslash commands into sections, so they
are not all one big alphabetical list.
How
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > My point is that it seems fsetpos is the approved way of accessing large
> > files, rather than fseeko. In fact, I don't have fseeko here but I do
> > have fsetpos, and it does handle large files because my includes have
> > this:
> >
> >
Bruce Momjian writes:
> My point is that it seems fsetpos is the approved way of accessing large
> files, rather than fseeko. In fact, I don't have fseeko here but I do
> have fsetpos, and it does handle large files because my includes have
> this:
>
> typedef off_t fpos_t
> typedef
I am not sure, but it certainly makes sense that it would drop the index
on failure. I would never expect it to fail, however.
---
scott.marlowe wrote:
> Sorry, that should have been:
>
> Isn't it true that reindex's beha
Sorry, that should have been:
Isn't it true that reindex's behavior ON A FAILURE is to simply, quietly
delete the index? that was reported ^
On Tue, 27 Aug 2002, Bruce Momjian wrote:
>
> REINDEX just rebuilds the index, not just drop it. In fact, 7.3 will
> have a reindexdb sc
Marc, wher did we leave this? Also, 7.3 will have prepared statements
in the backend code, so that should make the porting job easier.
---
Marc Lavergne wrote:
> The code comes from a project in which I needed to import fr
Alvaro Herrera wrote:
> On Tue, 27 Aug 2002, Bruce Momjian wrote:
>
> > Christopher Kings-Lynne wrote:
> > > Would it be worth adding REINDEX ALL and CLUSTER ALL as actual SQL commands?
> > > This would be neat. Plus, it means we don't have to worry about having
> > > unix-only script in the dis
On Tue, 27 Aug 2002, Bruce Momjian wrote:
> Christopher Kings-Lynne wrote:
> > Would it be worth adding REINDEX ALL and CLUSTER ALL as actual SQL commands?
> > This would be neat. Plus, it means we don't have to worry about having
> > unix-only script in the distro once we have Win32 support.
>
REINDEX just rebuilds the index, not just drop it. In fact, 7.3 will
have a reindexdb script.
---
scott.marlowe wrote:
> On Tue, 27 Aug 2002, Bruce Momjian wrote:
>
> > Christopher Kings-Lynne wrote:
> > > Would it be wor
On Tue, 27 Aug 2002, Bruce Momjian wrote:
> Christopher Kings-Lynne wrote:
> > Would it be worth adding REINDEX ALL and CLUSTER ALL as actual SQL commands?
> > This would be neat. Plus, it means we don't have to worry about having
> > unix-only script in the distro once we have Win32 support.
>
As you can see, there is a lot of cruft left in my mailbox, but there
are some items that we left behind that may be fixable before 7.3.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Has this been fixe
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Has this been fixed? I think we did.
Yes.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Has this been fixed? I think we did.
---
Tom Lane wrote:
> I have been looking at an example of the "no one parent tuple found"
> VACUUM error provided by Mario Weilguni. It appears to me that VACUUM
> is getting confused
On Tue, 27 Aug 2002, Bruce Momjian wrote:
>
> I had a good chuckle with this. It is the type of "shoot for the moon"
> idea I would have. Maybe I am rubbing off on you. :-)
>
> The only problem I see with this solution is it makes admins think their
> template1 is safe, when it really isn't.
Christopher Kings-Lynne wrote:
> Would it be worth adding REINDEX ALL and CLUSTER ALL as actual SQL commands?
> This would be neat. Plus, it means we don't have to worry about having
> unix-only script in the distro once we have Win32 support.
>
> Actually, we should just leave the 'ALL' off. T
On August 27, 2002 09:13 am, Tom Lane wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > On August 27, 2002 02:01 am, Tom Lane wrote:
> >> FWIW, I couldn't see any problem in CVS tip. Could you provide an exact
> >> sequence-to-reproduce?
> >
> > Surely. Create a database (chkpass_test)
Sorry to bother, but it seems my last to messages (one to the news and
one yesterday to the pghackers list) did'nt go through..
The problem related to difficulties with plperl and 7.3 on UW 711
Regards
--
Olivier PRENANT Tel:+33-5-61-50-97-00 (Work)
Quartier d'Harraud Turr
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On August 27, 2002 02:01 am, Tom Lane wrote:
>> FWIW, I couldn't see any problem in CVS tip. Could you provide an exact
>> sequence-to-reproduce?
> Surely. Create a database (chkpass_test) and, after loading the chkpass
> type, follow this bounc
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> ... What exactly was it, why we don't want that ?
> Backwards compatibility ? Imho doing one (additional) grant after creating a db
> cannot be such a problem, no ?
Breaking every existing pg_dumpall script doesn't strike you as a
problem
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>>> Could the index scan be made to
>>> handle cases where the index tuple it was stopped on is gone?
> Won't it still point to the same heap page and slot ?
Not if it's gone ...
regards, tom lane
-
On August 27, 2002 02:01 am, Tom Lane wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > I have been getting the subject message ever since upgrading to 7.2.1. I
> > tried 7.2.2 with the same thing. It seems to be related to my chkpass
> > type (see contrib) as it only happens on tables
1 - 100 of 102 matches
Mail list logo
