Re: [BUGS] BUG #4020: RFE: have way to log autovacuum activity
Joseph S wrote: > When autovacuum decides to vacuum one of our large tables, the whole site > slows down, but it is not always obvious why. It would be nice if there was > an option to log autovacuum activity so I know how often a vacuum runs and > how long it takes. Yeah, we have a configurable autovacuum log on 8.3. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4020: RFE: have way to log autovacuum activity
The following bug has been logged online: Bug reference: 4020 Logged by: Joseph S Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.5 Operating system: CentOS 5 Description:RFE: have way to log autovacuum activity Details: When autovacuum decides to vacuum one of our large tables, the whole site slows down, but it is not always obvious why. It would be nice if there was an option to log autovacuum activity so I know how often a vacuum runs and how long it takes. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [PATCH] Don't bail with legitimate -N/-B options
I wrote: > Anyway, it seems that we cannot raise the minimum value of > shared_buffers to 200, or even 100, unless we are prepared to blow off > SHMMAX = 2MB or do something about the fixed SLRU allocation. After further thought I propose that we just eliminate the interlock between -N and -B. I don't think it's accomplishing anything very useful (for sure it's not enough to guarantee that you can't run out of pinnable buffers), and the addition of the autovac worker processes makes the whole thing too confusing to be helpful. I am still interested in a TODO of increasing the minimum allowed value of shared_buffers, but that's really an independent issue. And we can't do very much there anyway until after eliminating the fixed-size-SLRU- buffers problem. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #3829: Wrong index reporting from pgAdmin III (v1.8.0 rev 6766-6767)
Added to TODO: * Add a function like pg_get_indexdef() that report more detailed index information http://archives.postgresql.org/pgsql-bugs/2007-12/msg00166.php --- Dave Page wrote: > Tom Lane wrote: > >> We use the data in various UI elements as well as for reverse > >> engineering the SQL - it's easier to get it broken down than to parse it > >> back out of the complete definition. > > > > Seems like all the more argument for having functions that extract > > single pieces of information, rather than several pieces (especially > > if some pieces get left off when default). > > Well it might well have been if the pgAdmin code didn't already work and > it wasn't so close to release :-) > > > For the moment I've reverted pg_get_indexdef() to its prior behavior > > of printing only the index column key or expression when colno!=0. > > We can look at having another function to do the other thing in 8.4. > > Thanks. > > /D > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4019: Comparison of user defined domain doesn't work
Stephan Szabo <[EMAIL PROTECTED]> writes: > On Fri, 7 Mar 2008, Tom Lane wrote: >> "Jan Strube" <[EMAIL PROTECTED]> writes: Description:Comparison of user defined domain doesn't work >> >> I can't reproduce this here --- the test case gives the expected output >> on both 8.2 and 8.3. (I'm checking CVS tip not the 8.3.0 release, but >> there surely haven't been any bug fixes that seem likely to affect >> this.) > Actually, I think it was fixed by your change in revision 1.103 which > appears to be newer than 8.3.0. Ohhh ... yeah, you're right, because the type it'd be using would be the declared input type of the comparison operator, so bpchar not the domain. So: closed, already fixed for 8.3.1. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4019: Comparison of user defined domain doesn't work
On Fri, 7 Mar 2008, Tom Lane wrote: > "Jan Strube" <[EMAIL PROTECTED]> writes: > > Description:Comparison of user defined domain doesn't work > > I can't reproduce this here --- the test case gives the expected output > on both 8.2 and 8.3. (I'm checking CVS tip not the 8.3.0 release, but > there surely haven't been any bug fixes that seem likely to affect > this.) Actually, I think it was fixed by your change in revision 1.103 which appears to be newer than 8.3.0. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Error during hash index scans can cause postgres halt!
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Ouch. So this has been broken (by me, I think :-() since 8.0. Tells >> you something about how many people use hash indexes :-( > Yeah. Also, this is very hard to trigger without --enable-cassert (or > just CLOBBER_FREED_MEMORY). It's extremely unlikely that something new > is allocated on the piece of memory that was used by an HashScanList > item, during AbortTransaction processing. > ykhuang, were you running an assertion-enabled build as well? The pfree() would touch the context control data, not just the HashScanList struct itself. Also on some platforms it's possible that malloc would've returned the freed context to the system, resulting in a segfault because we touch unmapped memory. But I agree that it'd be far more probable to see the problem with --enable-cassert. > Want me to hack up a patch, or you going to just commit that yourself? Already done, I didn't see your message till just now. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Error during hash index scans can cause postgres halt!
I wrote: > Ouch. So this has been broken (by me, I think :-() since 8.0. Tells > you something about how many people use hash indexes :-( Actually it's not that bad --- this particular test case doesn't crash in 8.0 or 8.1. I'm guessing we rearranged the order of transaction abort processing in 8.2 in a way that exposed the problem. I patched 8.0 and 8.1 anyway, since it seems likely that some other more complicated case might still show the problem there (eg something with subtransactions). regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Loading pljava: specified module could not be found
Version: 8.3 Platform: Windows Installation: Clicked the pl/java checkbox on installation Postgresql.conf changes custom_variable_classes = 'pljava' pljava.classpath='C:\\Program Files\\PostgreSQL\\8.3\\share\\pljava.jar' OS Path: I added C:\Program Files\Java\jdk1.6.0_02\jre\bin\client and this is where my jvm.dll file is. Executing: CREATE SCHEMA sqlj; CREATE FUNCTION sqlj.java_call_handler() RETURNS language_handler AS 'pljava' LANGUAGE C; ERROR: could not load library "C:/Program Files/PostgreSQL/8.3/lib/pljava.dll": The specified module could not be found. ** Error ** ERROR: could not load library "C:/Program Files/PostgreSQL/8.3/lib/pljava.dll": The specified module could not be found. SQL state: 58P01 I confirmed that pljava.dll is in that directory so it must be a dependency problem. Bug #3897 indicates this was a problem for 8.3RC3. Was this fixed in the final release? Jon -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Error during hash index scans can cause postgres halt!
Tom Lane wrote: "Heikki Linnakangas" <[EMAIL PROTECTED]> writes: I can reproduce this, with --enable-cassert. It crashes when aborting the transaction, in ReleaseResources_hash. The HashScanList items are allocated in ExecutorState memory context, but that context has already been deleted by the time we get to ReleaseResources_hash. Ouch. So this has been broken (by me, I think :-() since 8.0. Tells you something about how many people use hash indexes :-( Yeah. Also, this is very hard to trigger without --enable-cassert (or just CLOBBER_FREED_MEMORY). It's extremely unlikely that something new is allocated on the piece of memory that was used by an HashScanList item, during AbortTransaction processing. ykhuang, were you running an assertion-enabled build as well? Another idea would be to allocate the HashScanList items in a longer-lived memory context. The IndexScanDesc struct pointed to by the HashScanList would still be in ExecutorState context, but that's all right because we don't need to access it in ReleaseResources_hash. That seems like a winner to me. We can rely on the resource owner mechanism to free up individual HashScanList items, so there's no real need to keep them in a short-lived context. I'm inclined to just drop them into TopMemoryContext. We could make a hash-specific context but I'm not convinced it's worth the extra code to do it. Want me to hack up a patch, or you going to just commit that yourself? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Error during hash index scans can cause postgres halt!
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > I can reproduce this, with --enable-cassert. It crashes when aborting > the transaction, in ReleaseResources_hash. The HashScanList items are > allocated in ExecutorState memory context, but that context has already > been deleted by the time we get to ReleaseResources_hash. Ouch. So this has been broken (by me, I think :-() since 8.0. Tells you something about how many people use hash indexes :-( > Another idea would be to allocate the HashScanList items in a > longer-lived memory context. The IndexScanDesc struct pointed to by the > HashScanList would still be in ExecutorState context, but that's all > right because we don't need to access it in ReleaseResources_hash. That seems like a winner to me. We can rely on the resource owner mechanism to free up individual HashScanList items, so there's no real need to keep them in a short-lived context. I'm inclined to just drop them into TopMemoryContext. We could make a hash-specific context but I'm not convinced it's worth the extra code to do it. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4019: Comparison of user defined domain doesn't work
"Jan Strube" <[EMAIL PROTECTED]> writes: > Description:Comparison of user defined domain doesn't work I can't reproduce this here --- the test case gives the expected output on both 8.2 and 8.3. (I'm checking CVS tip not the 8.3.0 release, but there surely haven't been any bug fixes that seem likely to affect this.) Is it possible that you need a particular locale/encoding, or some other non-default setting, to reproduce the problem? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Error during hash index scans can cause postgres halt!
ykhuang wrote: recurred through deadlock. client1: create table test(a int); create index id on test using hash(a); insert into test values(1); insert into test values(2); set enable_seqscan=off; begin; update test set a=a+1 where a=1; client2: set enable_seqscan=off; begin; update test set a=a+1 where a=2; client1: update test set a=a+1 where a=2; client2: update test set a=a+1 where a=1; I can reproduce this, with --enable-cassert. It crashes when aborting the transaction, in ReleaseResources_hash. The HashScanList items are allocated in ExecutorState memory context, but that context has already been deleted by the time we get to ReleaseResources_hash. Not sure how to fix this. There's this piece of code in AtAbort_Portals: /* * Any resources belonging to the portal will be released in the * upcoming transaction-wide cleanup; they will be gone before we run * PortalDrop. */ portal->resowner = NULL; /* * Although we can't delete the portal data structure proper, we can * release any memory in subsidiary contexts, such as executor state. * The cleanup hook was the last thing that might have needed data * there. */ MemoryContextDeleteChildren(PortalGetHeapMemory(portal)); MemoryContextDeleteChildren is where we free the HashScanList item we later try to access. It seems like a simple fix would be to call ResourceOwnerRelease before that, instead of relying on the transaction-wide cleanup. Another idea would be to allocate the HashScanList items in a longer-lived memory context. The IndexScanDesc struct pointed to by the HashScanList would still be in ExecutorState context, but that's all right because we don't need to access it in ReleaseResources_hash. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4019: Comparison of user defined domain doesn't work
The following bug has been logged online:
Bug reference: 4019
Logged by: Jan Strube
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: openSUSE Linux 10.2
Description:Comparison of user defined domain doesn't work
Details:
Hi,
I think when cascading a DELETE to a dependent table Postgres doesn't
compare the whole related fields when they are of an user defined DOMAIN
type.
I have two tables "z_base" and "z_ul". "z_base"'s primary key is of type
"isin" which is referenced by "z_ul". "isin" is a DOMAIN of type
CHARACTER(12). When I delete a record from "z_base", all records of "z_ul"
whose "isin" has the same first character are also deleted. On Postgres
8.2.6 it's working as intended but not on 8.3.
Here is a test case:
create schema test;
create domain test.isin as character(12);
create table test.z_base (id test.isin primary key);
create table test.z_ul (id test.isin references test.z_base(id) on update
cascade on delete cascade);
insert into test.z_base values ('a111');
insert into test.z_base values ('a222');
insert into test.z_base values ('x333');
insert into test.z_ul values ('a111');
insert into test.z_ul values ('a222');
insert into test.z_ul values ('x333');
select * from test.z_base join test.z_ul using (id) where z_base.id =
'a222';
-- gives a222, ok
delete from test.z_base where id = 'a222';
select * from test.z_ul;
-- on PG 8.2.6. gives ('a111', 'x333'), ok
-- on PG 8.3 gives just 'x333', so 'a111' has also been deleted!!!
Regard,
Jan Strube
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4018: Installation failure
The following bug has been logged online: Bug reference: 4018 Logged by: Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.6 Operating system: Windows XP Professional Service Pack 2 Description:Installation failure Details: The installer for PostgreSQL 8.2.6 fails when it attempts to install the software. A message will display stating "failed to set permissions on the installed files". The installer will then perform a rollback. I am the administrator on my computer, and even when I set the permissions and attempt to reinstall the software, my permissions will be automatically set to deny, and the same "failed to set permissions" message will appear again. I even created another user account with administrative privileges and the same thing happened again. I also set my permissions to "Full Control" and the same thing happened again. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Error during hash index scans can cause postgres halt!
recurred through deadlock. client1: create table test(a int); create index id on test using hash(a); insert into test values(1); insert into test values(2); set enable_seqscan=off; begin; update test set a=a+1 where a=1; client2: set enable_seqscan=off; begin; update test set a=a+1 where a=2; client1: update test set a=a+1 where a=2; client2: update test set a=a+1 where a=1; -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
