didn't dig in to. Upon learning the WAL
files were removed as a temporary solution to the space problem, I opted to
dump, re-initdb, and load the data, which worked without any errors or warnings
being reported.
I've saved the data if there are pointed questions about their conte
fantastic. Thanks. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 8: explain analyze is your friend
y pgmemcache presentation and subconsciously propagated the error w/o
even thinking about it. :-/ Thanks, I'll take that pumpkin pie on my
face. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
uot;t5_func" line 1 at execute statement
LINE 1: t
^
Doh! Can someone with plpgsql foo look into this? -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
treat pg_shadow and pg_database as secure sources.
Nevermind, you win. That's far more elegant/easier... is 8.0 looking
like a good time to make this break from tradition? -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 2: you can get off al
variable names.
*) Requires adding a new keyword in the ALTER USER syntax.
*) Feels a tad like a "miscellaneous" column that is on the verge of
being abused.
Then again, isn't it on the horizon to have GUC reworked? Maybe this
would be an acceptable addition. *shrug* Just an ide
RITY DEFINER
function, but I'd be nice to be able to remove that hack. Anyway,
something to consider next time the system catalogs are being tweaked.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
aking roughly 3 minutes (just the DDL). After
Tom's latest VACUUM commit, this bug does not appear to exist any more.
Thank you Tom! -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
7;t at the same address.
FYI, I can confirm that your commit fixes this issue. Thank you very
much! -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAd
ere
stored in stuffed into some kind of a refcount in shared memory segment
and that the time needed to decrease the refcount would be
insignificant or done as soon as the client signaled their intention to
disconnect, not controlled by wait*(2) and the listening postmaster.
-sc
--
Sean Chittenden
-
ode and VACUUM/ANALYZE don't get along, or it's
bgwriter somehow. *big shrug*
Regardless, I thought this would be of keen interest to many: hopefully
a fix can be found before 8.0 is released. -sc
PS I haven't tested to see if this bug exists in pre-8.X releases.
PPS Sorry for t
get backend 123, recreate the same temp table and you'll get an
error... though I can't reproduce the temp table error right now,
yay!).
Anyway, Tom/Jan, this code seems to be your areas of expertise, could
either of you take a look? -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 8: explain analyze is your friend
set nomail
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
o permissions granted on it (not even the information_schema schema).
My $0.02.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 8: explain analyze is your friend
postgresql/pgsql-create-temp-bug-
typescript.txt
Any help or assistance is greatly appreciated, I'm not sure where to go
from here. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appr
in, the sleep gives
the bgwriter enough time to commit the pages to disk so that the
queries for the page happen after the fd's been sync()'ed.
I have no other clue as to why this would be happening though, so
believe me when I say, I could very well be quite wrong...
ld muck with caching. -sc
PS Other comments temp schema permission patch?
--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
work sometimes. Very disturbing. As I said, I'm *very* suspicious of
the background writer goo that Jan added simply because I can't think
of anything else that'd have this problem.
I've run each of those commands 100 times now, with and without the
sleep 1. With the sleep 1,
LECT TRUE::BOOL LIMIT 0;
--
Sean Chittenden
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
here'd be some real
interesting things that one could script. Ex:
\dn | tee -p 'head -n 3 >> /dev/stdout' | tail -n +3 | egrep -v
'_(log|shadow)$'
Which'd show you the header, but everything after the header would be
sent to egrep(1). I can't unde
ty, so that \dn | egrep -v '(log|shadow)
would work and would be the easiest solution.
Maybe a better "bug report" would be, what's the suggested way of doing:
n.nspname !~ '_(log|shadow)$'?
from a list pattern?
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
.3.7.obj~1/RELEASE_PPC Power
Macintosh powerpc
regression.diffs
Description: Binary data
--
Sean Chittenden
---(end of broadcast)---
TIP 8: explain analyze is your friend
special, so I don't really care one way
or another, but it was certainly aggravating to track it down so I
figured I'd report it as the behavior seems a tad bogus in some cases,
though I do appreciate the value of being able to join a table on
itself it just seems as though users stumble across this more
often than they join a table with itself. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
ecuted)
-> Seq Scan on table_s2 (cost=0.00..0.00 rows=1 width=4) (never executed)
Total runtime: 0.20 msec
(9 rows)
If there's real data in the tables, this joins the tables on itself
and execution times explode, naturally. I don't know if the spec says
this is the correct behavi
n calling an md5 crypt routine, which is
where the bug submitter triggered this boundary condition.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
user though. I
wonder if the configure script isn't correctly detecting using the
builtin crypt() as opposed to the openssl version... or visa versa.
Try applying the attached patch and seeing if that lets you reproduce
the crash. random may still need to be silly on HPUX, I don't know
ars, however it shouldn't core
with more than that... I ran this test case through gdb a few times
and couldn't come up with anything worth while, though I'm pretty sure
that's because the object files were optimized > -O and garbled.
-sc
--
Sean Chittenden
---
h these OpenSSL packages:
>
> openssl095a-0.9.5a-16
> openssl-devel-0.9.6b-29
> openssl-perl-0.9.6b-29
> openssl-0.9.6b-29
> openssl096-0.9.6-11
>
> What OpenSSL release are you using?
0.9.7a, which lends weight to the theory of shifting internals...
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
This patch supports Blowfish, DES and CAST5 algorithms.
>
> Marko Kreen
>
> Perhaps the problem is that Marko didn't fix the crypt() code in the
> same way?
Ah, I think that's _very_ likely the case here... -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
have to suspend it,
then kill.
test=# SELECT crypt('lalal',gen_salt('md5'));
The connection to the server was lost. Attempting reset: Failed.
connection pointer is NULL
!>
!>
!>
!>
!>
!>
!>
[1] + 15252 Suspended psql test pgsql
1:08pm
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > PS What's the dilly with the server(s)? I haven't gotten a commit
> >message all day, but CVSup and anoncvs picked up the change.
>
> Well, the CVS master server has been pretty much 100% through this
t return garbage
any more. :) ... looks like everything is nominal in HEAD again.
*cheers* Thanks Tom!
-sc
PS What's the dilly with the server(s)? I haven't gotten a commit
message all day, but CVSup and anoncvs picked up the change.
--
Sean Chittenden
-
#x27;s the only change in this function since the last stable
snapshot. I can consitently reproduce this with one of my schemas if
someone needs more debugging information, point me in the right
direction for where you'd like me to attach gdb. I haven't been able
to get a use case
he sake of completeness, returning the value from CURRVAL()
takes ~0.3ms from pl/pgsql and only ~0.14ms outside of pl/pgsql.
The difference is the runtime cost of using pl/pgsql which is
pretty reasonable given pl/pgsql walks an AST.
--
Sean Chittenden
---(end of broa
quite interact with libc (from prior version of
gcc) correctly. ::shrug:: Not really sure, but, it's not really that
important since only random() is failing. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
rrors in over 12 months now (no longer sends SIGFPE
on FPU errors), and it used to pass less than a month ago, it looks
like this is a "perk" of a recent gcc upgrade to 3.2.2. I'm going to
update my -CURRENT box just to be sure though and see if this wasn'
lues and reinsert well-behaved ones
DELETE FROM FLOAT8_TBL;
======
--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
ce to start poking at the code to possibly submit a patch, so
I punted. :-/ I'll see if I can't get more info if I run across this
again. -sc
GNU gdb 5.2.1 (FreeBSD)
--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
ect.c:2725
#12 0x0804a485 in PQclientEncoding () at fe-connect.c:2725
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
x27;m
> clear about it.
Wouldn't an ON DELETE trigger on the system catalogs work? I'd think
it would be possible to select the tables and groups that a user had
privs to and iterate through each calling REVOKE. -sc
--
Sean Chittenden
msg05642/pgp0.pgp
Description: PGP signature
action
> initiating statement when there isn't a current transaction. And,
> most of the SQL92 commands that start with SET fall into the
> category of commands that do not initiate transactions.
Was there any resolution to this or are SET's still starting a new
transaction? I haven&#x
20.
But that's the correct/expected behavior, is it not? That's what I'd
expect at least. I'd think it's a gotcha for those that aren't good
about explicitly calling BEGIN, but most libraries should do that for
you, ruby-dbi does and used to be overly zealous about that
;
> I assume that BEGIN does start a transaction. With no BEGIN above, the
> big problem is that it will work most of the time, but when/if the query
> fails, they will find out they forgot the BEGIN.
Wouldn't it roll back to 0 though because the SET statement_timeout T
are atomic
changes that aren't subject to being rolled back
What about that doesn't make sense? Having SET begin a transaction
seems like a gross violation of POLS and likely to contradict the spec
and cause problems with many applications. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
ng about being outside of a transaction
BEGIN;
SET autocommit TO on;
SHOW autocommit;# shows on
ROLLBACK;
SHOW autocommit;# shows off
Only have the SET's in a transaction/rollback-able if they're made
inside of a transaction, otherwise leave them as atomic changes. -sc
--
Sean
I personally am not haphazardous with setting autocommit, but users
who use any kind of interface are likely to screw things up and
scratch their head wondering why. Why would this have to be in its
own transaction? -sc
--
Sean Chittenden
---(end of broadcast)-
27;t part of
> the transaction, though the later one is. Yuck.
>
> I think we diverted from the spec when we went with making SET
> rollbackable and now we are seeing the problems caused.
>
> Why exactly did you want the initial SET to not be part of the
> transaction?
Is h
e system.
If you're throwing an error in the middle of a transaction just
because of 'SET autocommit', aren't you already making an exception
and one that degrades the performance of the entire system as a
result?
I just saw Tom's post and it seems like something has to gi
= true
end
Because there wasn't a commit given, that shouldn't actually delete
the rows found, but by tossing that AutoCommit in there, it should and
will generate a nifty warning if AutoCommit sends the above
BEGIN/SET/COMMIT. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
to SET
that'd avoid this rollback/commit silliness... but that seems like a
step backwards and is why I'd think an exception would be good. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
rts of confusion.
>
> I assume the way to code your case is:
>
> > template1=# SET AUTOCOMMIT TO OFF;
> > template1=# COMMIT;
> > template1=# DROP DATABASE my_db_name;
>
> because in fact the SET doesn't become permanent until the COMMIT is
> performed.
I
turning on
compilation with -O3. -sc
stable$ gcc -v
Using builtin specs.
gcc version 2.95.4 20020320 [FreeBSD]
current$ gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.2.1 [FreeBSD] 20020901 (prerelease)
--
Sean Chittenden
#x27;)
which reads really awkwardly and warrents a comment explaining why I'm
rolling back immediately after I connect. Thoughts/comments? -sc
--
Sean Chittenden
msg04859/pgp0.pgp
Description: PGP signature
t-math _should_ be okay. If it's not, then -O2 -fno-fast-math is
likely the correct work around for GCC. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
ad (wrongly?) appended krb5-config's --cflags
output to the CFLAGS for the build... which, nine times out of ten,
was exactly the same as what was used with the --with-includes. If
they're different, the person's horked, but that should be a minority
of the time. Anyway, just an FYI
ackage installations
(getopt/readline)... I'll see if I can't figure out the correct fix
for this though. Thanks for the info though. -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
got an older ecpgerrno.h in /usr/local/include that doesn't seem
to have these defined. Two quick suggestions:
*) Prepend the CPPFLAGS to the CFLAGS (works, but is hackish)
*) Alter the #ifndef
This strikes me as an upgrade problem for folks that others are going
to run across. -sc
--
S
local/include' 'LDFLAGS= -L/usr/local/lib -lgnugetopt -L/usr/local/lib
-Wl,-rpath -Wl,/usr/local/lib -lkrb5 -lk5crypto -lcom_err'
'build_alias=i386-portbld-freebsd4.7' 'host_alias=i386-portbld-freebsd4.7'
'target_alias=i386-portbld-freebsd4.7',g"
k up the
table and column in the appropriate schema and would return the
appropriate type.
If I were lazy, I'd just unshift the schema off of the token and
return what comes back from parse_dblwordtype(), but that doesn't
strike me as correct for something that's performan
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > Call me crazy, but shouldn't the following work? :~|
>
> Sure should. Want to fix plpgsql's parser?
Why not: I've never been one to avoid strapping on 4tons in rocks and
jumping into the deep end. ::sigh::
EATE FUNCTION
SELECT t();
WARNING: plpgsql: ERROR during compile of t near line 2
ERROR: Invalid type name 'pg_catalog.pg_attribute.attname % TYPE'
-sc
--
Sean Chittenden
msg04760/pgp0.pgp
Description: PGP signature
27;s no biggie though... rules just are so elegant compared
to triggers. :~)
-sc
PS I converted everything to use schemas tonight and I can't applaud
the efforts enough: they really clean up the database and make things
much usable. The output of psql is also much easier on the eyes for
l
in my rules... still, this
behavior seems a tad broken. There a good reason for this or could
you give me a filename to look into so I can toss together a patch.
Seems like something is going out of its way to get a new value from
the pk sequence when it shouldn't... though
hink that a macro/rule would be
faster than a trigger, but I don't have any real basis for my
statement. In my examples I'm using CURRVAL() and not NEXTVAL() so I
wouldn't worry about that being a problem.
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
correct. Am I wrong or missing some
way of getting the desired behavior?
http://archives.postgresql.org/pgsql-bugs/2001-10/msg00145.php
-sc
--
Sean Chittenden
[EMAIL PROTECTED]
[EMAIL PROTECTED]
msg04658/pgp0.pgp
Description: PGP signature
x27;;
timestamptz
2036-06-02 22:57:08-07
(1 row)
# SELECT version();
version
PostgreSQL 7.2 on i386--freebsd4.5, compiled by GCC 2.95.3
(1 row)
This isn't happy
-standards/20020414.freebsd-standards.html
> I don't have any compliance docs at the moment, but this strikes me
> as somewhat out of spec personally.
::shrug:: I've gotten enough push back to have an indifferent opinion:
I just want to see PG work w/ some of
*
> + * If mktime() was successful with the adjusted time,
> + * adjust the real time object. */
> + if (t == -1)
> + return 0;
> + else
> + tm->tm_hour += 1;
> + }
>
> tm->tm_isdst = tmp->tm_isdst;
>
--
Sean Chittenden
msg03995/pgp0.pgp
Description: PGP signature
ash
course in this code and don't quite have the incite to say one way or
another.
FWIW, I've lobbed something off to the FreeBSD crowd asking if
mktime() should be updated in the system libraries but don't think
that'll fix things "soon enough." -sc
--
Sean Chittenden
msg03973/pgp0.pgp
Description: PGP signature
= f)
1: tt = "2002-04-07 01:00:00-08" (typeid = 1184, len = 8, typmod = -1,
byval = f)
1: tt = "2002-04-07 03:00:00-07" (typeid = 1184, len = 8, typmod = -1,
byval = f)
-sc
--
Sean Chittenden
Index: src/backen
t = mktime(tmp);
(gdb)
1491fprintf(stderr, "%p\n", t); /* GCC optimizes this
away if I don't do
something */
(gdb)
0x3c5e5ba0
(gdb) print t
$1 = 11
Doesn't make much sense to me where that'd come from... ? -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
thing for not kicking up an error (out
of bounds time)? Or should 2am PST be converted to 3am? -sc
--
Sean Chittenden
msg03965/pgp0.pgp
Description: PGP signature
06-02 22:19:48-07" (typeid = 1184, len = 8, typmod = -1,
byval = f)
1: tt = "2036-06-02 22:49:48-07" (typeid = 1184, len = 8, typmod = -1,
byval = f)
1: tt = "2002-04-07 03:00:00-07" (typeid = 1184, len = 8, typmod = -1,
byval = f)
Ideas where to look? -sc
--
Sean Chittenden
msg03964/pgp0.pgp
Description: PGP signature
x27;;
timestamptz
2036-06-02 22:57:08-07
(1 row)
# SELECT version();
version
PostgreSQL 7.2 on i386--freebsd4.5, compiled by GCC 2.95.3
(1 row)
This isn't happy
74 matches
Mail list logo
