[BUGS] bug in config for cygwin
Hi, I'm not sure if what I've noticed fully qualifies as a bug...but, I run cygwin and also do a lot of development with vc++ (6)...Using version 7.2.1 I built the libpq++ libs/dll for win32 for use in my vc++ progs, and also ran the 'configure' script under cygwin...the problem occurs in the pg_config_os.h file, where an "#include " occurs before an "#ifdef __CYGWIN__" - so naturally my vc++ builds fail. By moving the include to after the ifdef the problem goes away...I thought I'd send this here so somwone with knowledge of patching the configure scripts etc. might have a look. Regards, Scott
Re: [BUGS] bug in config for cygwin
Hi Bruce, The path is: postgresql-7.2.1/src/include/pg_config_os.h Just while I'm here - congrats for a great peice of software, and on such a quick response time! :) Another note - I applied that patch for QNX6 (forget authors name - sorry - but the one that you guys argued about pretty intensly re going into version 7.2) on our QNX (6.2) development system at work...it seems to have worked no problems. Though I didn't try installing the patched version under cygwin or building the libpq stuff under windows... Scott - Original Message - From: "Bruce Momjian" <[EMAIL PROTECTED]> To: "Scott" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, August 17, 2002 1:17 AM Subject: Re: [BUGS] bug in config for cygwin > > I can't seem to find the file you are having a problem with. Would you > supply the full path of the file? > > -- - > > Scott wrote: > > Hi, > > > > I'm not sure if what I've noticed fully qualifies as a bug...but, > > I run cygwin and also do a lot of development with vc++ (6)...Using > > version 7.2.1 I built the libpq++ libs/dll for win32 for use in > > my vc++ progs, and also ran the 'configure' script under > > cygwin...the problem occurs in the pg_config_os.h file, where > > an "#include " occurs before an "#ifdef > > __CYGWIN__" - so naturally my vc++ builds fail. By moving the > > include to after the ifdef the problem goes away...I thought > > I'd send this here so somwone with knowledge of patching the > > configure scripts etc. might have a look. > > > > Regards, Scott > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] bug in config for cygwin
Yep I thought so - that's why I didn't think it's really a bug - but the include really ought to be after the define, and if it was I would be able to use the same headers for both cygwin and non-cygwin builds...would just be 'nice to have'. - Original Message - From: "Peter Eisentraut" <[EMAIL PROTECTED]> To: "Scott" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, August 18, 2002 1:46 AM Subject: Re: [BUGS] bug in config for cygwin > Scott writes: > > > I'm not sure if what I've noticed fully qualifies as a bug...but, I run cygwin and also do a lot of development with vc++ (6)...Using version 7.2.1 I built the libpq++ libs/dll for win32 for use in my vc++ progs, and also ran the 'configure' script under cygwin...the problem occurs in the pg_config_os.h file, where an "#include " occurs before an "#ifdef __CYGWIN__" - so naturally my vc++ builds fail. By moving the include to after the ifdef the problem goes away...I thought I'd send this here so somwone with knowledge of patching the configure scripts etc. might have a look. > > If you configure under cygwin then you can't build under not-cygwin. If > you want to build the libraries for native Windows you need to follow the > instructions for the native build. > > -- > Peter Eisentraut [EMAIL PROTECTED] > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #5613: cannot delete
The following bug has been logged online: Bug reference: 5613 Logged by: Scott Email address: wheels7...@hotmail.com PostgreSQL version: 8.4 Operating system: vista Description:cannot delete Details: I have recently tried to install PostgreSQL to use with poker tracker. I have having problems connecting to the server, where then i was advised to completly remove and download again. I have come accross a file located in c:\programfilmes, called PostgresSQL. I am unable to delete this folder file, even when using CMD it says the file cannot be found. I then proceeded to open this file and delete the items individually to see what was left, all the files were able to delete except one: pg_stat_tmp Please could you help with this as i have spoke to comuter technichian company and they were unable to remove the file. -- 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 #4451: initcap() function capitalizes incorrectly
The following bug has been logged online: Bug reference: 4451 Logged by: Scott V Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Mac OS X 10.5.4 Description:initcap() function capitalizes incorrectly Details: initcap() capitalizes incorrectly when passing strings containing certain two-byte UTF-8 characters. E.g., when argument = 'mātūrāte', initcap returns 'MāTūRāTe'. Correct result should be 'Mātūrāte'. The function appears to be incorrectly interpreting the two-byte chars as non-alphamueric characters. They are in fact alphanumerics, they just have diacritical markings. -- 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 #4451: initcap() function capitalizes incorrectly
Note sure what the correct settings should be, but output from SHOW ALL in psql says: lc_collate C lc_ctype C On Mon, Oct 6, 2008 at 5:37 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Scott V wrote: >>> PostgreSQL version: 8.3.1 >>> Operating system: Mac OS X 10.5.4 > >>> initcap() capitalizes incorrectly when passing strings containing certain >>> two-byte UTF-8 characters. E.g., when argument = 'mātūrāte', initcap >>> returns 'MāTūRāTe'. Correct result should be 'Mātūrāte'. > >> What's your setting for lc_collate? > > I think actually it's lc_ctype that determines case-folding. But the > current theory is that Apple's locale support is simply broken for > UTF-8: > http://archives.postgresql.org/pgsql-general/2008-02/msg01072.php > which means that even if Scott had all his settings right, it wouldn't > work :-( A quick test on OS X here seems to confirm this. > >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] BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always)
The following bug has been logged online: Bug reference: 4575 Logged by: Scott Carey Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.5, 8.3.4 Operating system: Linux (CentOS 5.2 2.6.18-92.1.10.el5) Description:All page cache in shared_buffers pinned (duplicated by OS, always) Details: I have determined that nearly every cached page within shared_buffers is being pinned in memory, preventing the OS from dropping any such pages from its page cache. Effectively, the memory used by shared_buffers for cached file pages is 2* the page size, these won't page out, they are pinned. --- To Reproduce: -- Stop Postgres. drop the OS page caches as follows: # sync;echo 3 > /proc/sys/vm/drop_caches Using 'free -m' or 'top' note the number of bytes that remain in the disk cache after forcing all to clear. This number is the baseline un-evictable page cache size. Configure postgres shared_buffers for ~30% of total RAM. The purpose of this is to make the effect obvious. Start Postgres. Run the same test as above. The value will be only slightly larger than before. Run 'top' and note the size of the "SHR" column for the postgres process with the largest value of "SHR". This is the shared memory used by postgres currently. Execute a query that fills the page cache. This is any insert (create table as select * from other_table works), or any select that does not cause a sequential scan. It does not appear that sequential scans ever end up putting pages in shared_buffers (nor does Vacuum, but I knew about vacuum's ring buffer before this). I used a query on a large table (5GB) with an index, known to do an index scan, and ran repeated variants on the where clause to hit most of it. Run top, and note the largest value of the "SHR" column on all postgres processes. Now execute the os cache eviction. Check the remaining cached memory. Note that it is now larger than the baseline by essentially the exact size of the postgres shared memory. Note, that you can wait for a checkpoint, sync, and be certain that there are no dirty pages from the OS point of view, and the other baselines rule out executable pages. Yet all the pages that correspond to those in shared_buffers seem to be pinned in memory. Running such tests over and over, with different data and different values for shared_buffers, it is consistent and easily reproducible on CentOS 5.2 linux as described above. - Context: - This is a rather large performance and scale issue. For some cases, a large shared_buffers helps because indexes and random-access data tends to be cached in this area well (seq scans don't kick things out of there). If there is memory pressure on the system, it can't kick out the pinned os pages, effectively making this cache cost twice the space. Additionally, for heavy write situations a large shared_buffers is required along with changes to the background writer and checkpoints to make it perform at peak capability (typically, it helps to be around 5 seconds * the MB/sec that the I/O is capable of -- 6GB for me). As far as my previous understanding of how postgres works, pages cached in shared_buffers should be able to differ from those the OS caches. So, if one heavily accessed index is always in shared_buffers, it will not be in the OS cache. When pages are written it will pass through the OS cache, but since no reads make it to the OS, these are evicted relatively quickly from the OS page cache and highly conserved in shared_buffers. This bug is preventing this behavior. There is one other behavior I have seen: kswapd CPU use is much higher when there are a large number of pinned pages in the system. kswapd will use significant CPU during disk reads (10% of a 3Ghz CPU for every 250MB/sec read) if there is ~8GB of pinned data. The more data pinned the higher the CPU used here. Without postgres running, pinning memory, the kswapd time doing the same activity, is significantly lower. This bug was first noticed due to how the linux kernel behaves when it wants to evict items from page cache but they are pinned. With shared_buffers at 25% of RAM, the system was unable to allocate more than 50% of the remaining 75% to processes. The result when approaching that limit was higher and higher system CPU% use, until all 8 cores spin at 100% when the remaining page cache is roughly equal in size to shared_buffers. It takes a low 'swapppiness' value to expose this before a swap storm occurs. Although I have not tried it, it would not surprise me if configuring shared_buffers to 55% of RAM with low swappiness, then filling shared_buffers with data from reads, may make the system fall down. Default swappiness would likely swap storm instead but may have similarly bad behavior, considering that close to half of the system memory should still be fre
Re: [BUGS] BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always)
Ok, I'll double check to validate that there is true duplication. If shared memory cannot be swapped, and shows up in the page cache list (which would be odd, but ok, since shared mem is not page cache it is application memory), then only those pages (the actual shared_buffers) would not be swappable, not a 'clone' of those buffers in the os page cache. I certainly don't care if the shared memory isn't pageable, I do care if a clone of that memory is also not pageable. From: Pavan Deolasee [pavan.deola...@gmail.com] Sent: Thursday, December 11, 2008 12:35 AM To: Scott Carey Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always) On Thu, Dec 11, 2008 at 5:37 AM, Scott Carey wrote: > > > Run top, and note the largest value of the "SHR" column on all postgres > processes. Now execute the os cache eviction. Check the remaining cached > memory. > Note that it is now larger than the baseline by essentially the exact size > of the postgres shared memory. > Isn't the shared memory on Linux non-swappable, unlike Solaris where you have an option to make is swappable ? As and when shared memory pages are accessed, they are allocated and can not be swapped out. I don't know if these pages are counted as part of the OS cache, but assuming they are, I don't see any problem with the above observation. May be you can try to write a C program which creates, attaches and accesses every page of the shared memory and check if you see the same behavior. Thanks, Pavan -- Pavan Deolasee 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] BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always)
I am 99.9% certian its not a fluke of "top" (or 'free'). Or a fluke with the drop_caches linux vm signal. Otherwise, the system would not spin at 100% System cpu getting no work done if an attempt to allocate memory above that threshold, the original symptom that led me down this path of investigation. So on a 32GB machine, setting shared_buffers to 8GB, filling them up via index scans, waiting for a checkpoint and syncing to be sure the dirty pages are negligible, then trying to allocate (and use) more than 16GB of RAM will make the sytem unresponsive. Set shared_buffers to 4GB and repeat, and it takes 24GB of allocations to cause the problem. The system essentially behaves like the shared_buffer space is 2x its size, except that the more useless half of it cannot be paged out. When I first saw this behavior, i did not connect the 8GB that the OS could not free to the 8GB that postgres was caching, and blamed linux, spending much effort with linux vm tunables. But now that they are connected, It would seem more likely to be on this side of things. After all, how can linux even know what pages postgres still has in cache? AFAIK, you aren't memory mapping pages, just read() ing them? Wouldn't the OS only know that there is memory allocated to shared space in a process, and not know those contents are mapped pages? Alternatively, the same behavior could occur if only the first pages put in the buffer, that replace 'empty space,' are being pinned. I would need some sort of tool that can tell me what blocks are in the OS page cache and which are in postgres to distinguish between those given the symptoms. If there are any ideas on how I could truly distinguish where this bug actually is, or further characterize it in ways that would be useful to that end, that would be great. I should have time to set shared_buffers above 50% and see if it kills things later today -- this sort of test would not require any special cache flushing particular to linux to see. Thanks, Scott From: Tom Lane [...@sss.pgh.pa.us] Sent: Thursday, December 11, 2008 5:57 AM To: Scott Carey Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always) "Scott Carey" writes: > I have determined that nearly every cached page within shared_buffers is > being pinned in memory, preventing the OS from dropping any such pages from > its page cache. Shouldn't you be complaining to kernel folk rather than here? What do you think we could do about it? (I'm not convinced that you're seeing anything except a platform-specific vagary in how "top" counts things, anyway.) 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 #4575: All page cache in shared_buffers pinned (duplicated by OS, always)
Thanks Tom, Gregory, and Pavan, I have looked into this on a few other sysstems and what I first thought was a Linux issue, then thought was Postgres related, looks more like Linux again. There is a combination of more memory than expected not being able to drop from the OS page cache, and some odd numbers being reported by 'free', or even the /proc raw data. It all doesn't add up to what the documentation claims it does. I am unaware of anything that may pin pages in os cache from userland, but am certainly not completely knowledgeable on all the things possible in that realm. Now that I am comfortable that you understand the symptoms I see, and you are confident its elsewhere, I trust that the issue's cause must be elsewhere. Thanks! -Scott On 12/11/08 1:16 PM, "Tom Lane" wrote: Scott Carey writes: > I am 99.9% certian its not a fluke of "top" (or 'free'). Or a fluke with the > drop_caches linux vm signal. Otherwise, the system would not spin at 100% > System cpu getting no work done if an attempt to allocate memory above that > threshold, the original symptom that led me down this path of investigation. That's certainly a kernel bug. > If there are any ideas on how I could truly distinguish where this bug > actually is, or further characterize it in ways that would be useful to that > end, that would be great. It's in the kernel. Userland doesn't have any way to "pin" OS disk cache pages in memory, which AFAICT is what you are claiming happens. regards, tom lane
[BUGS] 8.3.5: Query Planner takes 15+ seconds to plan Update or Delete queries on partitioned tables.
Linux, CentOS 5.2, Postgres 8.3.4, 8.3.5. System tables and user tables listed below have been VACUUM'd, ANALYZE'd and REINDEX'd. Summary: Simple update / delete queries that hit a parent table façade of a large partitioned database are taking 15 to 20 seconds to plan (and a couple ms to execute). Worse, the backend will consume about 7GB of memory while planning (measured with top as: Resident memory - shared memory ; it is released after its done). The particular update or delete has a where clause that causes it to only affect one table out of many, and going directly against the child table as named will parse and plan the query in less than 1ms and consumes very little memory. Triggers / rules are not used to modify behavior at all. Workaround: Execute all queries against the table partitions, not the façade. Non-trivial for anything spanning more than 1 partition. Table information and definitions at the end. Queries below, run locally with \timing on. The time it takes to explain them is the same as it is to execute, there is nothing special about the actual explain process causing a delay. I have simplified the case to minimalist forms that demonstrate the issue. Total tables in the system: select count (*) from pg_tables; count --- 53427 Child tables of the table in question: select count (*) from pg_tables where tablename like pp_logs%'; count --- 6062 A simple select against one such table (a very small one). ~1 sec to plan, a couple ms to execute. No noticeable jump in memory use while planning. explain analyze select att from log.pp_logs WHERE s_id=23 AND date='2008-12-01' AND p_id = 3; QUERY PLAN - Result (cost=0.00..24.12 rows=3 width=1) (actual time=0.267..0.267 rows=0 loops=1) -> Append (cost=0.00..24.12 rows=3 width=1) (actual time=0.266..0.266 rows=0 loops=1) -> Seq Scan on p_p_logs (cost=0.00..4.65 rows=1 width=1) (actual time=0.048..0.048 rows=0 loops=1) Filter: ((s_id = 23) AND (date = '2008-12-01'::date) AND (p_id = 3)) -> Seq Scan on p_p_logs_023_2008_12_01 p_p_logs (cost=0.00..19.47 rows=2 width=1) (actual time=0.218..0.218 rows=0 loops=1) Filter: ((s_id = 23) AND (date = '2008-12-01'::date) AND (p_id = 3)) Total runtime: 4.393 ms (7 rows) Time: 1134.866 ms The same in an UPDATE form, 20 seconds to plan, a couple ms to execute. 7GB of memory used while planning (then released). The memory and time consumed does not differ for explain versus explain analyze. explain analyze UPDATE log.p_p_logs SET att=true WHERE s_id=23 AND date='2008-12-01' AND p_id = 3::int; QUERY PLAN - Append (cost=0.00..24.12 rows=3 width=181) (actual time=0.269..0.269 rows=0 loops=1) -> Seq Scan on p_p_logs (cost=0.00..4.65 rows=1 width=124) (actual time=0.045..0.045 rows=0 loops=1) Filter: ((s_id = 23) AND (date = '2008-12-01'::date) AND (p_id = 3)) -> Seq Scan on p_p_logs_023_2008_12_01 p_p_logs (cost=0.00..19.47 rows=2 width=181) (actual time=0.221..0.221 rows=0 loops=1) Filter: ((s_id = 23) AND (date = '2008-12-01'::date) AND (p_id = 3)) Total runtime: 4.246 ms (6 rows) Time: 17194.092 ms A DELETE form. Similar to the above, uses ~ 6.7GB memory. explain DELETE from log.p_p_logs WHERE s_id=23 AND date='2008-12-01' AND p_id=-321; QUERY PLAN - Append (cost=0.00..24.12 rows=3 width=6) -> Seq Scan on p_p_logs (cost=0.00..4.65 rows=1 width=6) Filter: ((s_id = 23) AND (date = '2008-12-01'::date) AND (p_id = (-321))) -> Seq Scan on p_p_logs_023_2008_12_01 p_p_logs (cost=0.00..19.47 rows=2 width=6) Filter: ((s_id = 23) AND (date = '2008-12-01'::date) AND (p_id = (-321))) (5 rows) Time: 16680.702 ms We have no triggers or rules for INSERT on the parent table façade. No rules or triggers at all in relation to any partitioned tables, in fact. For INSERT we go directly to the child tables. It would appear that we have to do this for DELETE and UPDATE as well, and SELECT is expensive too. However, what seems most worrying here is how much more expensive, and HUGELY memory consuming it is for DELETE and UPDATE than SELECT. I would expect all of these to have the same ~1 second of time to identify the candidate tables based on the table constraints. But it seems like this table identification process is
[BUGS] BUG #4699: pg_restore hangs with incorrect file format
The following bug has been logged online: Bug reference: 4699 Logged by: Scott Reed Email address: sr...@avacoda.com PostgreSQL version: 8.3 Operating system: Windows XP Description:pg_restore hangs with incorrect file format Details: "pg_restore " hangs if the file format is not one of the non-plain-text formats created by pg_dump. There does not appear to be a log or error message to explain what is happening. Apparently this also causes the OK button to be disabled in the pgAdmin Restore dialog, again without any explanation, even though the file has been created using the pgAdmin Backup dialog (albeit in plain-text format). My suggestions for a fix is to have pg_restore return an error if the file format is incorrect. Carry over to pgAdmin: 1) in the pgAdmin Backup dialog only display the last file used if 1) the file name has the default file extension for the selected format or b) the selected format matches the format used when backing up to the last file. 2) in the pgAdmin Restore dialog display the error message from pg_restore (see pg_restore suggested fix) when the file format is incorrect to explain why the OK button is disabled. -- 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 #4699: pg_restore hangs with incorrect file format
Tom, My apologies for wasting your time. I wasn't calling pg_restore as I'd described but with the -f flag so of course it was hanging waiting for input. I hope my embarrassment is sufficient punishment. Would you accept the second part of that post about handling the file name in pgAdmin Backup and Restore? I will resubmit if you think it would be useful. Scott Tom Lane [3/10/2009 3:43 PM] wrote: "Scott Reed" writes: > "pg_restore " hangs if the file format is not one of the > non-plain-text formats created by pg_dump. When I try to reproduce this I get pg_restore: [archiver] input file does not appear to be a valid archive Perhaps there are specific cases where it gets confused, but you'll need to submit a sample file for us to poke at. Another possible explanation is that this is a bug that's been fixed since whichever 8.3.x release you are using (which you didn't specify, tut tut). 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] data loss with pg_standby when doing a controlled failover
On Mon, Apr 6, 2009 at 7:37 AM, Andreas Pflug wrote: > Running 8.3.7, I have a warm standby configuration with a > archive_timeout of 10min. > > It's obvious that there's a 10min period where data could be lost if the > master fails and the warm standby server has to take over. What's not > obvious is that this is true even if the master server is shut down > regularly, because it will not write out a last log segment to the > archive. As a consequence, when doing a controlled failover (for > maintenance purposes or so) all data changed after the last archive copy > will be lost. > IMHO this should be mentioned in the docs explicitly (I find it quite > surprising that data can be lost even if the system is shutdown > correctly), or better when shutting down the postmaster should spit all > log segments containing all changes when archiving is on so the warm > standby server can catch up. You make an excellent point. If you're looking for a way to mitigate this risk, run: select pg_switch_xlog() ; Before shutting down. --Scott > > > Regards. > Andreas > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs >
[BUGS] Scripting issue
I am trying to script a pg_dumpall command set to use in a crontab entry. The problem I am finding is that the command pg_dumpall seems to be ignoring the -W input. (I get password prompts on all 4 instances within the DB.) It is happening on a Oracle Enterprise Linux 5 server and PostgreSQL 8.3.5 as well as 8.3.7 Please help. -Scott D. Scott Wells Systems Administrator II Apollo Group Inc. STS | 4325 S. 30th Street | Suite 200 | M/S AA-M002 | Phoenix, AZ 85040 (602) 557.6673 This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Re: [BUGS]
2009/5/14 Hugo > Me rindo > > Llevo una semana tratando de instalar postgres > y simplemente es demasiado difícil, es más fácil > cambiar a otra base de datos > Sorry to hear that you 'surrender' ! I'm not really sure you've provided any information to help us with your problem though, maybe you should submit to pgsql-general list with your actual problem. I'm sure that we can help. When submitting, you should include things like: OS PG Version Installer you're using Error messages / logs Thanks --Scott
Re: [BUGS] PLEASE TAKE ME OFF YOUR MAILING LIST. I DO NOT WAN...
On Fri, May 15, 2009 at 11:13 AM, Hector Saldarriaga wrote: > > PLEASE TAKE ME OFF YOUR MAILING LIST. I DO NOT WANT ANY MORE OF YOUR > PESTERING E-MAILS. > THANK YOU. I´LL APPRECIATE IF YOU DON´T SEND ME ANY MORE MAILS. I DON´T > NEED THEM. > To get on the list, you have to subscribe yourself. I recommend that you unsubscribe. --Scott > > _ > Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. > > http://www.microsoft.com/windows/windowslive/products/photos.aspx > -- > 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] DATABASE DRIVER REQUIRED FOR POSTGRESQL
On Fri, May 15, 2009 at 11:45 AM, wrote: > Hi, > > > > We are trying to access the postgresql database through the Informatica > power Center. Could you please give me the details about the installable > ODBC driver for this database. > > Note :the Informatica powercenter has been installed in Linux box. > > You'll need to download the ODBC driver for linux and install it. http://www.postgresql.org/ftp/odbc/versions/ You'll also need a driver manager such as: http://www.unixodbc.org Most Linux distros install a driver manager either by default or through their package manager. Good luck --Scott
Re: [BUGS] DATABASE DRIVER REQUIRED FOR POSTGRESQL
On Fri, May 15, 2009 at 11:45 AM, wrote: > Hi, > > > > We are trying to access the postgresql database through the Informatica > power Center. Could you please give me the details about the installable > ODBC driver for this database. > > Note :the Informatica powercenter has been installed in Linux box. > You'll need to download the ODBC driver for linux and install it. http://www.postgresql.org/ftp/odbc/versions/ You'll also need a driver manager such as: http://www.unixodbc.org Most Linux distros install a driver manager either by default or through their package manager. Good luck --Scott
Re: [BUGS] BUG #4950: Problem in Job scheduling in Advanced postgre sql
If you're using Postgres Plus Advanced Server, that is a commercial product released by EnterpriseDB. It is not supported here. Please use ' supp...@enterprisedb.com' --Scott
Re: [BUGS] BUG #5186: Not install daemon
On Fri, Nov 13, 2009 at 9:50 PM, Robert Haas wrote: > On Fri, Nov 13, 2009 at 8:52 PM, obelich wrote: > > > Hi we want to report a problem in the instalation with .bin file in > Opensuse > > 11.2 this one give send a message problem, then dont install the daemon > to > > start PostgreSQL service, send the follow error > > > ..snip.. > > I think you might want to report this problem to OpenSuse. If there's > a bug here, it sounds like a packaging problem, rather than a > PostgreSQL problem. > > I agree it's a packaging thing, but if it's a '.bin' file, it could be the one-click installers. It'd be helpful to know where the OP downloaded the installers from. --Scott
Re: [BUGS] BUG #5186: Not install daemon
On Fri, Nov 13, 2009 at 9:50 PM, Robert Haas wrote: > On Fri, Nov 13, 2009 at 8:52 PM, obelich wrote: > > > Hi we want to report a problem in the instalation with .bin file in > Opensuse > > 11.2 this one give send a message problem, then dont install the daemon > to > > start PostgreSQL service, send the follow error > > > > I think you might want to report this problem to OpenSuse. If there's > a bug here, it sounds like a packaging problem, rather than a > PostgreSQL problem. > > I agree it's a packaging thing, but if it's a '.bin' file, it could be the one-click installers. It'd be helpful to know where the OP downloaded the installers from. --Scott
Re: [BUGS] [GENERAL] How duplicate data produce when a UNIQUE index exite ?
2009/11/24 RD黄永卫 : > Dear all, > > > > When "reindex" operation do,this error occurred: > Nov 22 10:22:27 SUC11 postgres[14145]: [2-1] ERROR: could not create unique > index > Nov 22 10:22:27 SUC11 postgres[14145]: [2-2] DETAIL: Table contains > duplicated values. > Nov 22 10:22:27 SUC11 postgres[14145]: [2-3] STATEMENT: REINDEX TABLE > "t_sfh_history" > > My question is: > > How the Duplicate datas produce when a UNIQUE index exite ? > Is this a bug of PostgreSQL ? Either bad hardware, or a pgsql bug can do this. > My postgreSQL version is : > PostgreSQL 8.1.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 > 20030502 (Red Hat Linux 3.2.3-56) You are aware that 8.1.x is up to 8.1.18, right, that's 14 or so updates you're missing. Could one of them have fixed a bug that causes this? Sure. Look through the changelogs to be sure, but why not just keep your pgsql version up to date? It's easier. Or are you running some redhat version that stays the same number while getting bugs back ported to it or something? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: 答复: [GENERAL] How duplicate data produce whe n a UNIQUE index exite ?
2009/11/24 RD黄永卫 : > > 发件人: Scott Marlowe [mailto:scott.marl...@gmail.com] > 发送时间: 2009年11月25日 14:44 > 收件人: RD黄永卫 > 抄送: pgsql-bugs@postgresql.org; pgsql-gene...@postgresql.org > 主题: Re: [GENERAL] How duplicate data produce when a UNIQUE index exite ? > > 2009/11/24 RD黄永卫 : >> Dear all, >> >> >> >> When "reindex" operation do,this error occurred: >> Nov 22 10:22:27 SUC11 postgres[14145]: [2-1] ERROR: could not create unique >> index >> Nov 22 10:22:27 SUC11 postgres[14145]: [2-2] DETAIL: Table contains >> duplicated values. >> Nov 22 10:22:27 SUC11 postgres[14145]: [2-3] STATEMENT: REINDEX TABLE >> "t_sfh_history" >> >> My question is: >> >> How the Duplicate datas produce when a UNIQUE index exite ? >> Is this a bug of PostgreSQL ? > > > >>> My postgreSQL version is : >>> PostgreSQL 8.1.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 >>> 20030502 (Red Hat Linux 3.2.3-56) > >> You are aware that 8.1.x is up to 8.1.18, right, that's 14 or so >> updates you're missing. Could one of them have fixed a bug that >> causes this? Sure. Look through the changelogs to be sure, but why >> not just keep your pgsql version up to date? It's easier. >> >> Or are you running some redhat version that stays the same number >> while getting bugs back ported to it or something? > > Either , or a pgsql bug can do this. > > What kind of " bad hardware " cause that ? May I reproduce that ? Any kind of bad hardware. Bad memory, cpu, motherboard, RAID controller, possibly the OS and on and on. memtest86+ is a good starting place to see if your hardware has cpu / ram /mobo issues. But first, update pgsql. Then hunt down your duplicates and fix the data in the database. I'm pretty sure there were a few problems like this in the early 8.1 series releases. -- 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] PHP .zip File
On Thu, Jan 21, 2010 at 3:53 AM, Antoine Banks < antoinelba...@assistantdirectors.com> wrote: > Hi. > > Do you have a downloadable .zip file that I can download with individual > php files of the windows version of PostgreSQL and move the php files into a > folder inside my cpanel instead of having to install PostgreSQL directly > onto my computer? If not, will you PLEASE create one; I think you should. > PostgreSQL is a relational database system written in C, to run it, you need to have installed the binaries or built the database from source. Are you maybe referring to phpPGadmin, an administration tool for the database? --Scott
Re: [BUGS] BUG #5365: pg_ctl start gives error
On Thu, Mar 11, 2010 at 2:13 PM, Robert Haas wrote: > On Mon, Mar 8, 2010 at 5:19 AM, Savita wrote: > > > > The following bug has been logged online: > > > > Bug reference: 5365 > > Logged by: Savita > > Email address: savita.ha...@gmail.com > > PostgreSQL version: 8.3.5 > > Operating system: SunOS 5.10 Generic_139555-08 sun4u sparc > > SUNW,Sun-Fire-V440 > > Description:pg_ctl start gives error > > Details: > > > > Hi > > > > I have installed postgres in Solaris machine and trying to start the > service > > and it fails with follwoing error > > > > FATAL: syntax error in file "../../pgsql/data/postgresql.conf" line 107, > > near token "MB" > > > > By seeing the error I thought the problem could be with postgresql.conf > > file. But I copied this file from other machine(SunOS 5.10 > Generic_118833-33 > > sun4v sparc sun4v) where postgres start/stop works fine still gives the > same > > error in this box. > > > > Is it something to do with version of SunOS? > > I doubt it. postgresql.conf should be parsed identically on any > platform, I would think. > I've seen this when I accidentally use the wrong pg_ctl on a data directory (i.e. my 8.1 pg_ctl is in the PATH and I use it to try and start an 8.3 cluster). --Scott M
Re: [BUGS] BUG #5423: problems installing postgresql-8.4 deleted folder / .s.PGSQL.lock not initiate the connecti
On Wed, Apr 14, 2010 at 8:15 PM, Alex Soto Paez wrote: > > The following bug has been logged online: > > Bug reference: 5423 > Logged by: Alex Soto Paez > Email address: alejandro.soto...@gmail.com > PostgreSQL version: 8.4 > Operating system: linux 9.10 > Description:problems installing postgresql-8.4 deleted folder / > .s.PGSQL.lock not initiate the connecti > Details: > > problems installing postgresql-8.4 deleted folder / var / run / postgresql > / > .s.PGSQL.lock not initiate the connection to port 5432 > > when installing postgresql-8.4 is installed correctly while running the > command: > > $ Service postgresql-8.4 status > > Published online defautl port 5432, but at reboot the machine no longer > seems in line appears down and restart the server payable are parachute > with > the error: > > > $sudo /ect/init.d/postgresql-8.4 restart > > The PostgreSQL server failed to start. Please check the log output: > 2010-04-14 18:48:24 CDT FATAL: could not lock file postgresql > / .s.PGSQL.lock>>: no such file? directory > > > [Fail] > > run and hand it to guide the pid file and everything goes well but when you > see another restart the computer I get the same error described above. not > save the folder with the Pid and does not connect to port 5432 > > Someone can help me > > In advance thank you very much. > > Does the '/var/run/postgresql' directory exist and is it writeable by the postgres user? If it is not, I would say it's a bug for the packager of this install of postgres. Typically, postgres puts its lock / sockets in '/tmp'. You say linux, but don't say which linux, by your version string (9.10) I'm guessing that this is ubuntu? --Scott > -- > 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] Dump and Restore in postgresql-8.3.6-1PGDG
On Thu, Apr 15, 2010 at 12:47 PM, Scott Mead wrote: > On Thu, Apr 15, 2010 at 10:33 AM, suresh adapa wrote: > >> >> >> I am on Linux using postgresql-8.3.6-1PGDG >> >> >> >> Taking Dump using >> >> = >> >> export PGPASSWORD=suresha && pg_dump -b -c -C --format=c -h localhost -p >> 5432 -U suresha -f /tmp/dump/db/suresha.sql suresha >> >> >> >> Trying to Restore the same like >> >> === >> >> [r...@cu018 scripts]# pg_restore -c --format=c -h localhost -p 5432 -U >> suresha -d suresha /tmp/dump/db/suresha.sql >> >> Password: >> >> pg_restore: [archiver (db)] Error while PROCESSING TOC: >> >> pg_restore: [archiver (db)] Error from TOC entry 6; 2615 2200 SCHEMA >> public postgres >> >> pg_restore: [archiver (db)] could not execute query: ERROR: must be owner >> of schema public >> >> Command was: DROP SCHEMA public; >> >> pg_restore: [archiver (db)] could not execute query: ERROR: schema >> "public" already exists >> >> Command was: CREATE SCHEMA public; >> >> pg_restore: [archiver (db)] Error from TOC entry 2663; 0 0 COMMENT SCHEMA >> public postgres >> >> pg_restore: [archiver (db)] could not execute query: ERROR: must be owner >> of schema public >> >> Command was: COMMENT ON SCHEMA public IS 'standard public schema'; >> >> pg_restore: WARNING: no privileges could be revoked for "public" >> >> pg_restore: WARNING: no privileges could be revoked for "public" >> >> pg_restore: WARNING: no privileges were granted for "public" >> >> pg_restore: WARNING: no privileges were granted for "public" >> >> WARNING: errors ignored on restore: 3 >> >> >> >> Wondering how can I suppress the Error and other messages seen above. >> > > > This is because you're restoring into the same database that you backed up > from. I recommend creating a new database 'suresha_new' > > Then, restore into that new database. Once you've restored, you can: > > > ALTER DATABASE suresha RENAME TO suresha_orig; > > ALTER DATABASE suresha_new RENAME TO suresha; > > --Scott > BTW -- THis is not a bug, you should have posted to the -general or -admin list, not the -bugs list. --Scott > >> >> >> >> Thanks >> >> SureshA >> > >
Re: [BUGS] Dump and Restore in postgresql-8.3.6-1PGDG
On Thu, Apr 15, 2010 at 10:33 AM, suresh adapa wrote: > > > I am on Linux using postgresql-8.3.6-1PGDG > > > > Taking Dump using > > = > > export PGPASSWORD=suresha && pg_dump -b -c -C --format=c -h localhost -p > 5432 -U suresha -f /tmp/dump/db/suresha.sql suresha > > > > Trying to Restore the same like > > === > > [r...@cu018 scripts]# pg_restore -c --format=c -h localhost -p 5432 -U > suresha -d suresha /tmp/dump/db/suresha.sql > > Password: > > pg_restore: [archiver (db)] Error while PROCESSING TOC: > > pg_restore: [archiver (db)] Error from TOC entry 6; 2615 2200 SCHEMA public > postgres > > pg_restore: [archiver (db)] could not execute query: ERROR: must be owner > of schema public > > Command was: DROP SCHEMA public; > > pg_restore: [archiver (db)] could not execute query: ERROR: schema > "public" already exists > > Command was: CREATE SCHEMA public; > > pg_restore: [archiver (db)] Error from TOC entry 2663; 0 0 COMMENT SCHEMA > public postgres > > pg_restore: [archiver (db)] could not execute query: ERROR: must be owner > of schema public > > Command was: COMMENT ON SCHEMA public IS 'standard public schema'; > > pg_restore: WARNING: no privileges could be revoked for "public" > > pg_restore: WARNING: no privileges could be revoked for "public" > > pg_restore: WARNING: no privileges were granted for "public" > > pg_restore: WARNING: no privileges were granted for "public" > > WARNING: errors ignored on restore: 3 > > > > Wondering how can I suppress the Error and other messages seen above. > This is because you're restoring into the same database that you backed up from. I recommend creating a new database 'suresha_new' Then, restore into that new database. Once you've restored, you can: ALTER DATABASE suresha RENAME TO suresha_orig; ALTER DATABASE suresha_new RENAME TO suresha; --Scott > > > > > Thanks > > SureshA >
Re: [BUGS] BUG #5423: problems installing postgresql-8.4 deleted folder / .s.PGSQL.lock not initiate the connecti
On Thu, Apr 15, 2010 at 6:35 PM, Geoffrey Pitman wrote: Offlist reply posted back to list. How did you perform your install? (I think you're running Ubuntu 9.10). > > Did you use the repositories, or did you build it from source? > > If you used the Ubuntu repositories, have you checked the Community guide? > Located here: > > https://help.ubuntu.com/community/PostgreSQL > > The version data (in the guide) is not up-to-date, but you can always do an > aptitude search postgre at the CLI to find the appropriate version number. > > Also, it might not be on port 5432; I've seen some funky installs with > Ubuntu that put Postgre on 5433. You might want to check that? (though that > wouldn't be directly related to your reported issue) which is more likely a > permissions issue, or you're not launching the server as root--either via a > secondary script or maybe your init.rc script is wrong? > > > > On Thu, Apr 15, 2010 at 8:51 AM, Scott Mead > wrote: > >> >> On Wed, Apr 14, 2010 at 8:15 PM, Alex Soto Paez < >> alejandro.soto...@gmail.com> wrote: >> >>> >>> The following bug has been logged online: >>> >>> Bug reference: 5423 >>> Logged by: Alex Soto Paez >>> Email address: alejandro.soto...@gmail.com >>> PostgreSQL version: 8.4 >>> Operating system: linux 9.10 >>> Description:problems installing postgresql-8.4 deleted folder / >>> .s.PGSQL.lock not initiate the connecti >>> Details: >>> >>> problems installing postgresql-8.4 deleted folder / var / run / >>> postgresql / >>> .s.PGSQL.lock not initiate the connection to port 5432 >>> >>> when installing postgresql-8.4 is installed correctly while running the >>> command: >>> >>> $ Service postgresql-8.4 status >>> >>> Published online defautl port 5432, but at reboot the machine no longer >>> seems in line appears down and restart the server payable are parachute >>> with >>> the error: >>> >>> >>> $sudo /ect/init.d/postgresql-8.4 restart >>> >>> The PostgreSQL server failed to start. Please check the log output: >>> 2010-04-14 18:48:24 CDT FATAL: could not lock file >> postgresql >>> / .s.PGSQL.lock>>: no such file? directory >>> >>> >>> [Fail] >>> >>> run and hand it to guide the pid file and everything goes well but when >>> you >>> see another restart the computer I get the same error described above. >>> not >>> save the folder with the Pid and does not connect to port 5432 >>> >>> Someone can help me >>> >>> In advance thank you very much. >>> >>> >> Does the '/var/run/postgresql' directory exist and is it writeable by the >> postgres user? If it is not, I would say it's a bug for the packager of >> this install of postgres. Typically, postgres puts its lock / sockets in >> '/tmp'. You say linux, but don't say which linux, by your version string >> (9.10) I'm guessing that this is ubuntu? >> >> --Scott >> >> >> >> >>> -- >>> >>> 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 #5423: problems installing postgresql-8.4 deleted folder / .s.PGSQL.lock not initiate the connecti
On Thu, Apr 15, 2010 at 6:35 PM, Geoffrey Pitman wrote: Off-list reply posted to list How did you perform your install? (I think you're running Ubuntu 9.10). > > Did you use the repositories, or did you build it from source? > > If you used the Ubuntu repositories, have you checked the Community guide? > Located here: > > https://help.ubuntu.com/community/PostgreSQL > > The version data (in the guide) is not up-to-date, but you can always do an > aptitude search postgre at the CLI to find the appropriate version number. > > Also, it might not be on port 5432; I've seen some funky installs with > Ubuntu that put Postgre on 5433. You might want to check that? (though that > wouldn't be directly related to your reported issue) which is more likely a > permissions issue, or you're not launching the server as root--either via a > secondary script or maybe your init.rc script is wrong? > > > > On Thu, Apr 15, 2010 at 8:51 AM, Scott Mead > wrote: > >> >> On Wed, Apr 14, 2010 at 8:15 PM, Alex Soto Paez < >> alejandro.soto...@gmail.com> wrote: >> >>> >>> The following bug has been logged online: >>> >>> Bug reference: 5423 >>> Logged by: Alex Soto Paez >>> Email address: alejandro.soto...@gmail.com >>> PostgreSQL version: 8.4 >>> Operating system: linux 9.10 >>> Description:problems installing postgresql-8.4 deleted folder / >>> .s.PGSQL.lock not initiate the connecti >>> Details: >>> >>> problems installing postgresql-8.4 deleted folder / var / run / >>> postgresql / >>> .s.PGSQL.lock not initiate the connection to port 5432 >>> >>> when installing postgresql-8.4 is installed correctly while running the >>> command: >>> >>> $ Service postgresql-8.4 status >>> >>> Published online defautl port 5432, but at reboot the machine no longer >>> seems in line appears down and restart the server payable are parachute >>> with >>> the error: >>> >>> >>> $sudo /ect/init.d/postgresql-8.4 restart >>> >>> The PostgreSQL server failed to start. Please check the log output: >>> 2010-04-14 18:48:24 CDT FATAL: could not lock file >> postgresql >>> / .s.PGSQL.lock>>: no such file? directory >>> >>> >>> [Fail] >>> >>> run and hand it to guide the pid file and everything goes well but when >>> you >>> see another restart the computer I get the same error described above. >>> not >>> save the folder with the Pid and does not connect to port 5432 >>> >>> Someone can help me >>> >>> In advance thank you very much. >>> >>> >> Does the '/var/run/postgresql' directory exist and is it writeable by the >> postgres user? If it is not, I would say it's a bug for the packager of >> this install of postgres. Typically, postgres puts its lock / sockets in >> '/tmp'. You say linux, but don't say which linux, by your version string >> (9.10) I'm guessing that this is ubuntu? >> >> --Scott >> >> >> >> >>> -- >>> >>> 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] pgadmin supports on SLES10.3
On Mon, Apr 26, 2010 at 1:29 AM, manohar cr wrote: > Hi Kevin, > Sorry for reply so late. > > Here is more detail for you. > > I am trying to install pgadmin3 in my suse linux enterprise server 10 with > SP3. > I am trying to install pgadmin3-1.10.2 version. I downloaded this version > from internet.(it is mentioned that it supports for Open suse and suse > linux) > Initially it was not finding c++ compiler. I installed it through yast > tool. > Now it is progressing but i am getting a error when i try to configure > using ./configure command, the error says > configure: error: Could not find your wxWidgets installation. You might > need to use the --with-wx=DIR configure option > > I have searched for the word 'widget', and i installedalll the packages, > but still i could not able to configure. Also after i seeing the script, it > says wx-config should be in usr/bin, but i could not able to find wx-config. > Pls help in installing wx-widget. Last time when i tried to install > wx-wdget, i messed up my whole system, and i had to re install OS. Because i > faced lot of graphical related problems. > > i tried downloading wxwdiget and installing, it requires glib2.0, atk1.13, > pango 1.20, cairo 1.6. pixman 0.10.0, freetype, font config. Like this > dependencies keep on growing. When i tried these things, OS was fully > corrupted, i could not able to recover it. > Pls suggest how to overcome this. > Firstly, this isn't a bug. This is PgAdmin3 telling you what its pre-requisites are, and wxWidgets (a GUI framework) is required to compile the tool. You aren't technically 'installing' it here, you are 'compiling'. > *I just need to install PGAdmin3, is it possible on Suselinux? * > > > Have you tried the OpenSuse RPMS? http://www.postgresql.org/ftp/pgadmin3/release/v1.10.0/opensuse/11.1/ If all else fails, download the one-click installer for your platform. It has PGAdmin in there. --Scott
[BUGS] bug in v7.02 on redhat 7
query="select * from product where cat1 like 'Home decoration--%'" this query does not return any tuples in v7.02 but return 1 tuple in v6.5x with the same database population. I ran another query="select * from product where cat1='Home decoration--musical'". This query return one tuple. I ran another query="select * from product where cat1 like '%Home decoration--%'". This query return one tuple.
[BUGS] PROC struct
Hi, May I suggest that watiHolder and waitLock pointers in the proc struct in proc.h be changed from direct pointers to SHMEM_OFFSET. They are both shared memory structures in a shared memory structure and it would be more consistent to make these SHMEM_OFFSET. Direct pointers will be a problem if another process which is not the result of a fork tries to attach to the shared memory. The Direct pointers will not be valid for in this case. Thanks, Myron Scott [EMAIL PROTECTED]
Re: [BUGS] PROC struct
On Mon, 5 Feb 2001, Tom Lane wrote: > Myron Scott <[EMAIL PROTECTED]> writes: > > May I suggest that watiHolder and waitLock pointers > > in the proc struct in proc.h be changed from direct > > pointers to SHMEM_OFFSET. They are both shared memory > > structures in a shared memory structure and it would > > be more consistent to make these SHMEM_OFFSET. Direct > > pointers will be a problem if another process which is > > not the result of a fork tries to attach to the shared memory. > > I don't really foresee that that's an issue --- any process > we might conceivably want to have reading the shmem would be > spawned by the postmaster anyway. I've actually been thinking > about ripping out the shmem-offset-to-pointer-and-back conversions > on the grounds of code simplification, readability, reliability > (the compiler cannot detect whether you are casting a reconverted > SHMEM_OFFSET to the wrong pointer type), and speed. > > regards, tom lane > Thanks for looking into this. I ran into this while working on a threaded version of Postgres. I start a postmaster so I can use psql and then start the multithreaded Postgres which attaches to the shared mem created by the postmaster. This is not a big deal but maybe a note in the header would be helpful to future tinkerers. Thanks, Myron Scott [EMAIL PROTECTED]
[BUGS] On NetBSD, had to add -Wl,-R/usr/local/postgres/lib to the src/Makefile.global LIB variable
Priority: probably low. Background: uname -a: NetBSD scotts 1.5 NetBSD 1.5 (GENERIC) #1: Sun Nov 19 21:42:11 MET 2000 fvdl@sushi:/work/trees/netbsd-1-5/sys/arch/i386/compile/GENERIC i386 Postgresql version: 7.0.3 To configure I did a `./configure --prefix=/usr/local/postgres'. This is straight "out-of-the-box", so I didn't apply any of the NetBSD pkgsrc patches. My problem & fix: I had to add -Wl,-R/usr/local/postgres/lib to the src/Makefile.global LIB variable. Otherwise, doing a 'ldd /usr/local/postgres/bin/psql' after installation reported that it couldn't find libpg (`-lpq.2 => Not Found' or something like that). Remarks: There's almost certainly a better way, since src/Makefile.global is automatically generated, but I'm still getting acclimated to NetBSD and Postgres build. - Scott Williams
[BUGS] Implicit cast of literal in SQL statements
I've seen a few postings in multiple newsgroups saying that in 7.1.x and
up, literals in SQL statements are implicitly cast to strings.
For example in:
select distinct 'hello' from mytable;
the 'hello' is implicitly assumed to be 'hello'::text
However, in both 7.1.3, and a fresh build of 7.2b4 from cvs, (with all
regressions passing) I get:
mytest=# select distinct 'hello' from mytable;
ERROR: Unable to identify an ordering operator '<' for type 'unknown'
Use an explicit ordering operator or modify the query
an explicit 'hello'::text works fine.
I've spent a day looking through the code and can't really find any
obvious #define's or compile time flags that would be causing this
problem.
It looks like
Const *
make_const(Value *value)
{
...
case T_String:
val = DirectFunctionCall1(textin,
CStringGetDatum(strVal(value)));
typeid = UNKNOWNOID;/* will be coerced
later */
typelen = -1; /* variable len */
typebyval = false;
break;
...
}
does the damage, and it never gets 'coerced later', at least not before
transformDistinctClause(...) gets called, which is where the failure
happens (a few levels down).
does this really work for everybody else? Can someone point me to a
compile flag I may be missing, or the code that actually does the
implicit cast?
thanks
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Implicit cast of literal in SQL statements
I've got some 'legacy' code that I'm dealing with - sometimes it will receive query requests that are simply the union of two easier requests it already knows the sql for. These 'easier' queries have 'distincts' in them, and the code doesn't go to the trouble of removing by hand when doing a union. so the query ends up looking like: SELECT DISTINCT firstName, middleName, lastName FROM completeNameTable WHERE (...) UNION SELECT DISTINCT firstName, ' ', lastName FROM partialNameTable WHERE(...) ugly, I know. ( and probably inefficient, I should check the plan ) thanks for the quick response On Thursday, December 27, 2001, at 03:28 PM, Thomas Lockhart wrote: >> I've seen a few postings in multiple newsgroups saying that in 7.1.x >> and >> up, literals in SQL statements are implicitly cast to strings. > > In some contexts, that statement is true, yes. The cases where this is > true is when the parser is trying to match literals with available > function calls. If there is a literal of unknown type, and if there is a > function which could take a string literal as input, then that function > is the one chosen. > >> does this really work for everybody else? Can someone point me to a >> compile flag I may be missing, or the code that actually does the >> implicit cast? > > It looks like we are not handling the case where there is no explicit > function call, and there a string literal in the target list (so no > underlying column to infer a type from), and there is a subsequent > ordering operation. That might be fixable, but it may not be a useful > real world example afaict. > > Do you have another example to illustrate the problem for a query which > one might actually need to use? > > - Thomas > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #3046: odbc zip file corrupt
The following bug has been logged online: Bug reference: 3046 Logged by: Cedric Scott Email address: [EMAIL PROTECTED] PostgreSQL version: odbc 8 2 200 Operating system: WindowsXP Description:odbc zip file corrupt Details: I downloaded 4 versions of psqlodbc-8_02_200.zip 1) From first Irish Mirror 2) From second Irish Mirror 3) From first UK Mirror% ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #3544: SQLException from JDBC driver
The following bug has been logged online: Bug reference: 3544 Logged by: Scott Harper Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.9 Operating system: Debian Linux (2.6.18-4-486) Description:SQLException from JDBC driver Details: I have installed PostgreSQL 8.1 via the Debian package manager (APT) -- installed the package postgresql-8.1. We are running Sun Java 5, Apache 2, and Tomcat 5.5. >From the discussion at http://jdbc.postgresql.org/download.html, I have determined that I should be using the 8.1-410 JDBC 3 driver. I downloaded the driver, and it is bundled into my servlet's war file in WEB-INF/lib. When the servlet makes the DriverManager.getConnection() call, the following exception is thrown: org.postgresql.util.PSQLException: Something unusual has occured to cause the driver to fail. Please report this exception. I wasn't sure to whom I should report the exception, so I started here. :) I should point out that I have successfully run the same servlet, with the same JDBC driver, on an equivalent installation on Mac OS X. Any ideas? Is there anything special I need to know about running JDBC on a Debian Linux platform? Thanks, Scott ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #3706: ecpg regression: "MOVE FORWARD"
The following bug has been logged online: Bug reference: 3706 Logged by: Scott Bailey Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3beta1 Operating system: Tru64 Description:ecpg regression: "MOVE FORWARD" Details: The following statement: exec sql MOVE FORWARD :RowMove IN Sniffer; which worked correctly in 8.2.4 and previous versions, now fails to compile in 8.3beta1; I receive the following error message: ERROR: fetch/move count must not be a variable. This sucks and I couldn't find anything about it in the TODO list or Release Notes. Is this unintentional, or should I be recoding my program to use a loop to move forward 1 row at a time? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3706: ecpg regression: "MOVE FORWARD"
I haven't seen any feedback on this report, but FYI... I worked around this problem by rewriting my code to use a dynamic prepared statement instead, e.g. OLD: EXEC SQL MOVE FORWARD :RowMove IN Sniffer; NEW: const char mover[] = "MOVE FORWARD ? IN Sniffer"; [...] EXEC SQL PREPARE MoverSQL FROM :mover; [...] EXEC SQL EXECUTE MoverSQL USING :RowMove; [...] EXEC SQL DEALLOCATE PREPARE MoverSQL; Assuming the new restriction on the original "MOVE FORWARD" is intentional, it would be nice to see a warning that code changes are required get into the documentation. Thanks, Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Bailey Sent: Monday, October 29, 2007 11:45 AM To: pgsql-bugs@postgresql.org Subject: [BUGS] BUG #3706: ecpg regression: "MOVE FORWARD" The following bug has been logged online: Bug reference: 3706 Logged by: Scott Bailey Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3beta1 Operating system: Tru64 Description:ecpg regression: "MOVE FORWARD" Details: The following statement: exec sql MOVE FORWARD :RowMove IN Sniffer; which worked correctly in 8.2.4 and previous versions, now fails to compile in 8.3beta1; I receive the following error message: ERROR: fetch/move count must not be a variable. This sucks and I couldn't find anything about it in the TODO list or Release Notes. Is this unintentional, or should I be recoding my program to use a loop to move forward 1 row at a time? ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #4264: Optimizer fails to use hash_aggregate when appropriate.
The following bug has been logged online:
Bug reference: 4264
Logged by: Scott Carey
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Linux (CentOS)
Description:Optimizer fails to use hash_aggregate when appropriate.
Details:
The query optimizer fails to use a hash aggregate most of the time. This is
an inconsistent behavior.
On one particular table this is especially painful. This table has 24
million rows, and when aggregating on a column that the optimizer expects
only a few unique values, it chooses a full sort of those 24 million rows
before a group aggregate, rather than using a hash aggregate that would be 2
to 3 orders of magnitude faster and use less memory.
The simple statement of this bug is the following EXPLAIN output and
corresponding output from the statistics tables. The actual query used has
a more complicated GROUP BY and aggregation (and joins, etc).
The condition will occur for any column used to group by. Even one that has
only two unique values in a 25 million row table.
rr=# explain SELECT count(distinct v_guid) as view_count, p_type FROM
p_log.creative_display_logs_012_2008_06_15 GROUP BY p_type;
QUERY PLAN
--
GroupAggregate (cost=5201495.80..5395385.38 rows=7 width=47)
-> Sort (cost=5201495.80..5266125.63 rows=25851932 width=47)
Sort Key: p_type
-> Seq Scan on creative_display_logs_012_2008_06_15
(cost=0.00..1223383.32 rows=25851932 width=47)
rr=# select attname, null_frac, avg_width,n_distinct
,correlation from pg_stats where
tablename='creative_display_logs_012_2008_06_15' and attname in ('g_id',
'p_type', 'strat', 'datetime', 'ext_s_id', 't_id');
attname | null_frac | avg_width | n_distinct | correlation
+---+---++--
g_id | 0 | 8 | 14 | 0.221548
p_type | 0 | 4 | 7 | 0.350718
datetime | 0 | 8 | 12584 | 0.977156
ext_s_id | 0.001 |38 | 11444 | -0.000842848
strat | 0 |13 | 11 | 0.147418
t_id | 0 | 8 | 2 | 0.998711
(5 rows)
I have dumped, dropped, and restored this table twice recently. Both times
followed by a full vacuum analyze. And in both cases the query optimizer
behaves differently.
Additionally, this table is a partition table, and using the inheritance
facade instead of the table produces consistently worse plans -- at first
the direct-to-table query used the hash aggregate but not the one through
inheritance and I thought this was a partitioning bug. But it definitely
occurs in general and its reproducibility is affected by partitioning but
not dependent on it.
The database is tuned with the default optimizer settings for 8.3.3 +
constraint exclusion for the partition tables. Yes, hash_agg is ON. It
happens sometimes on some tables.
The configuration has ample RAM and all the memory tuning parameters are
generous (shared_mem 7g, temp space 200m, sort/agg space 500m -- I've tried
various settings here with no effect on the plan, just the execution of it
w.r.t. disk based sort or mem based sort).
The table definition is:
Column |Type | Modifiers
+-+---
v_guid | character varying(255) |
site_id| bigint |
c_id | bigint |
item_id| bigint |
creative_id| bigint |
camp_id| bigint |
p_type | integer |
datetime | timestamp without time zone |
date | date|
ext_u_id | character varying(50) |
ext_s_id | character varying(50) |
u_guid | character varying(50) |
strat | character varying(50) |
sub_p_type | character varying(32) |
exp_id | bigint |
t_id | bigint |
htmlpi_id | bigint |
p_score| double precision|
Of course DB hints would solve this. So would some sort of tuning parameter
that lets you dial up or down the tendency to do a hash aggregate rather
than a full sort followed by a group aggregate. This is broken rather
severely, especially in combination with partitions (where it is about 3x as
likely to fail to use a hash_aggregate where appropriate
Re: [BUGS] BUG #4264: Optimizer fails to use hash_aggregate when appropriate.
in a distinct are aggregated, as in the first example, since aggregates are input-order insensitive. Lastly, a more sophisticated hash-aggregate could be multi-tiered and apply to my first example, hashing by the the group by clause and then sub-hashing the column distinct values. No intermediate table would be required in this case, unlike my query butchering above. This combined with the other query plan options would allow for clear, natural - looking queries without hints or hacking up the query into more ugly and less flexible forms as I am required to above (both are mere work-arounds, but work-arounds are necessary stopgaps). Thanks for the clarification on the limitations of the query planner Tom, and the reminder that DISTINCT forces a sort -- I forgot all about that. -Scott Carey On Wed, Jun 25, 2008 at 1:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Scott Carey" <[EMAIL PROTECTED]> writes: > > The query optimizer fails to use a hash aggregate most of the time. This > is > > an inconsistent behavior. > > Hash aggregation is not used when a DISTINCT aggregate is specified. > DISTINCT forces a sort, so there wouldn't be any advantage. > > > Of course DB hints would solve this. > > No, they wouldn't. > >regards, tom lane >
Re: [BUGS] VACUUM FULL changes the order of rows in a table?
Pg 104 of "A Guide to THE SQL STANDARD" Fourth Edition by Date/Darwen says: ... 2. Observe that the definition makes no mention of row ordering. As explained in Chapter 2, the rows of an SQL table have no ordering (and the same is true of true relational tables). It is possible, as we will see in Chapter 10, to impose an ordering on the rows... ; however imposing such an order should not be thought of as "ordering the table," but rather as converting the table into something that is not a table, but instead a sequence or odered list of rows. ... Even the column ordering isn't required to remain consistent although most implementations allow the programmer to get lazy and rely on "select *..." to behave consistently in the absense of an intervening ALTER TABLE or other schema altering event. A pure relational implementation would likely require that you specify both row and column ordering since the underlying data storage is free to be optimized or altered by the implementation for performance reasons. Good programming practices would require that in any case to ensure you were insulated from changes the DBA might choose to make to optimize the schema or allow it to serve multiple applications more efficiently. ss - Original Message - From: "Douglas Trainor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, July 23, 2002 1:01 AM Subject: [BUGS] VACUUM FULL changes the order of rows in a table? > WARNING: Not sure if what I am about to describe is a bug. > > The PostgreSQL 7.2.1 Documentation for VACUUM says: > > "VACUUM FULL does more extensive processing, including moving of tuples > across blocks to try to compact the table to the minimum number of disk blocks." > > Does above quote explain why the order of rows in an unindexed table would > change after doing a VACUUM FULL on that table with PostgreSQL version 7.1.3? > Would this be considered bug or am I just misunderstanding something? > > I am trying to simplify my code to get a tiny working example, but before I spend > a lot of time on that, is there any reason the row order would change? > > Scenario: > (1) i have a table with two dozen or so VARCHAR fields. > (2) i populate the table with data in a certain order. > (3) i ALTER TABLE and ADD a TEXT field. > (4) i SET the new text field to a constant, say 'foo'. > (5) i VACUUM FULL the table. > > It doesn't matter if I index the table and then cluster it on that index. > Step (4) and the VACUUM FULL in (5) is necessary for the row order to change. > > Everything is fine if I do (1)(2)(3)(5). > > Everything is fine if I do (1)(2)(3)(4) and tweak (5) so as to just VACUUM (no FULL). > > It's like the table was re-ordered in DESCENDING order... > > I peeked at vacuum.c, but I think I should go back to simplifying the > example... :-) > > douglas > > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] test
give me an error message telling me how to subscribe without getting postings. ;-) R. Scott Bailey EDS - Global Operations Solutions Delivery - Midwest MS 2O 1075 West Entrance Drive Auburn Hills, MI 48326 * phone: +01-248-276-5770 (8-351) * mailto:[EMAIL PROTECTED] www.eds.com > This e-mail, and any attachments thereto, is intended only for use by the > addressee(s) named herein and may contain privileged and/or confidential > information. If you are not the intended recipient of this e-mail, any > dissemination, distribution or copying of this e-mail, and any attachments > thereto, is strictly prohibited. If you have received this e-mail in > error, please immediately notify the sender by e-mail or telephone and > permanently delete all copies of this e-mail and any attachments. > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] ECPG - Keywords as variable names (7.4 regression)
POSTGRESQL BUG REPORT TEMPLATE
Your name : Gavin Scott
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.20
PostgreSQL version (example: PostgreSQL-7.3): PostgreSQL-7.4beta4
Compiler used (example: gcc 2.95.2) : gcc 2.96
Please enter a FULL description of your problem:
Certain keywords (specifically unreserved_keyword, reserved_keyword,
and ECPGkeywords_rest in preproc.y) produce a syntax error when used
as variable names in sql struct definitions.
These keywords are accepted as variable names in declare sections.
The difference appears to be that the lexer is in C mode within
declare sections which causes the keywords to be returned as IDENT
tokens. Within sql struct sections the lexer is in SQL mode and
returns them as keyword tokens (i.e. INDEX for index, etc).
This is a regression; ecpg has no problems processing the sample code
below in PostgreSQL version 7.3.4. and under.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
int main()
{
/* no problem with keywords as variable names in declare section */
exec sql begin declare section;
int index;
int explain;
exec sql end declare section;
/* keywords here cause ecpg syntax error (worked in PostgreSQL
version 7.3.4 and under) */
exec sql type struct_t is struct
{
int index;
int explain;
};
return 0;
}
If you know how this problem might be fixed, list the solution below:
-
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[BUGS] PostgreSQL 7.4RC1 crashes on Panther
I've encountered a problem where the PostgreSQL database crashes when attempting to load pltcl.so on Mac OS 10.3. PostgreSQL fails because memory cannot be allocated during a shmget call. Here is the exact error message: FATAL: could not create shared memory segment: Cannot allocate memory DETAIL: Failed system call was shmget(key=5432001, size=3809280, 03600). HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space. To reduce the request size (currently 3809280 bytes), reduce PostgreSQL's shared_buffers parameter (currently 300) and/or its max_connections parameter (currently 50). The PostgreSQL documentation contains more information about shared memory configuration. Here's the code that triggers it: create function pltcl_call_handler() RETURNS LANGUAGE_HANDLER as 'pltcl.so' language 'c'; I have 1GB of memory and very little running on the powerbook (I rebooted just to be sure I started with a clean system). Not sure whether this is a PostgreSQL problem or a Mac OS 10.3 problem, but I can load plpgsql.so right before loading pltcl.so and it still only fails on the pltcl.so load. Commenting out the plpgsql.so load and trying again it still fails on the pltcl.so load. I'm compiling against a locally compiled version of Tcl 8.4.4. Here are the configure settings: ./configure \ --prefix=$INSTALL/postgresql \ --with-tcl \ --with-tclconfig=$INSTALL/tcl/lib \ --with-includes=$INSTALL/tcl/include:$INSTALL/readline/include \ --with-libraries=$INSTALL/readline/lib \ --without-tk \ --without-openssl thanks, /s. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] PostgreSQL 7.4RC1 crashes on Panther
Hi Tom, On Nov 4, 2003, at 4:48 PM, Tom Lane wrote: Here's the code that triggers it: create function pltcl_call_handler() RETURNS LANGUAGE_HANDLER as 'pltcl.so' language 'c'; I don't think so. That's a startup failure; it can not be triggered by executing a SQL command, because if the postmaster is alive enough to accept a SQL command in the first place, it's already gotten past creation of the shared memory segment. I have to differ here. This problem is being triggered by the create function section above, it is doing it after startup, and it's doing it on Mac OS 10.3. Here are the commands I'm using, in the order I'm using them. I'll be glad to admit I'm the one screwing it up, but I don't see where. # Define vars ROOT=/Users/scott/m INSTALL=$ROOT/install PG=$INSTALL/postgresql PGLIB=$PG/lib PGDATA=$ROOT/var/db PORT=5432 DB=m DYLD_LIBRARY_PATH=$INSTALL/tcl/lib:$INSTALL/postgresql/lib:$INSTALL/ openssl/lib export DYLD_LIBRARY_PATH # Initialize the database cluster $PG/bin/initdb -D $PGDATA --locale=C -L $PG/share ...output of the above command is: The files belonging to this database system will be owned by user "scott". This user must also own the server process. The database cluster will be initialized with locale C. creating directory /Users/scott/m/var/db... ok creating directory /Users/scott/m/var/db/base... ok creating directory /Users/scott/m/var/db/global... ok creating directory /Users/scott/m/var/db/pg_xlog... ok creating directory /Users/scott/m/var/db/pg_clog... ok selecting default max_connections... 30 selecting default shared_buffers... 200 creating configuration files... ok creating template1 database in /Users/scott/m/var/db/base/1... ok initializing pg_shadow... ok enabling unlimited row size for system tables... ok initializing pg_depend... ok creating system views... ok loading pg_description... ok creating conversions... ok setting privileges on built-in objects... ok creating information schema... ok vacuuming database template1... ok copying template1 to template0... ok Success. You can now start the database server using: /Users/scott/m/install/postgresql/bin/postmaster -D /Users/scott/m/var/db or /Users/scott/m/install/postgresql/bin/pg_ctl -D /Users/scott/m/var/db -l logfile start # Start the database $PG/bin/pg_ctl start -D $PGDATA -l $ROOT/database/postgres.log -o "-i" ...at this point the database is running, as shown by ps: scott 2712 0.0 0.137288936 std S 12:10PM 0:00.02 /Users/scott/m/install/postgresql/bin/postmaster -i -D /Users/scott/m/var/db scott 2715 0.0 0.038276168 std S 12:10PM 0:00.00 /Users/scott/m/install/postgresql/bin/postmaster -i -D /Users/scott/m/var/db scott 2717 0.0 0.037288260 std S 12:10PM 0:00.00 /Users/scott/m/install/postgresql/bin/postmaster -i -D /Users/scott/m/var/db ...and by the log file: LOG: database system was shut down at 2003-11-06 12:10:49 CST LOG: checkpoint record is at 0/9B13D8 LOG: redo record is at 0/9B13D8; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 534; next OID: 17142 LOG: database system is ready # Create the database $PG/bin/psql -d template1 -c "create database $DB" ...output on the command line: CREATE DATABASE # Add PL/pgsql and PL/tcl $PG/bin/psql -d $DB -f $OPS/database/sql/add_languages.sql ...output on the command line is: psql:/Users/scott/m/ops/database/sql/add_languages.sql:13: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. psql:/Users/scott/m/ops/database/sql/add_languages.sql:13: connection to server was lost ...output in the log file is: LOG: server process (PID 2739) was terminated by signal 10 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing FATAL: could not create shared memory segment: Cannot allocate memory DETAIL: Failed system call was shmget(key=5432001, size=3809280, 03600). HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space. To reduce the request size (currently 3809280 bytes), reduce PostgreSQL's shared_buffers parameter (currently 300) and/or its max_connections parameter (currently 50). The PostgreSQL documentation contains more information about shared memory configuration. ...at this point, the server is no longer running. The add_languages.sql file contains: create function plpgsql_call_handler() RETURNS LANGUAGE_HANDLER as 'plpgsql.so' language 'c'; create trusted procedural language 'plpgsql' HANDLER plpgsql_call_handler LANCOMPILER 'PL/pgSQL'; create function pltcl_call_handler() RETURNS LANGUAGE_HANDLER as 'pltcl.so' language &#x
Re: [BUGS] PostgreSQL 7.4RC1 crashes on Panther
Just compiled PG 7.3.4 with GCC 3.1 on Panther and it exhibits the same problem, but generates a SIGSEGV instead of a SIGBUS. Here's the log: LOG: server process (pid 12078) was terminated by signal 11 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing shared memory and semaphores LOG: database system was interrupted at 2003-11-06 14:19:26 CST LOG: checkpoint record is at 0/80212C LOG: redo record is at 0/80212C; undo record is at 0/0; shutdown TRUE LOG: next transaction id: 480; next oid: 16976 LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 0/80216C LOG: ReadRecord: record with zero length at 0/81E754 LOG: redo done at 0/81E730 LOG: database system is ready A reboot does not help -- it still fails. I recompiled at GCC 3.1 and it's failing at pltcl load again. I rebooted, then tried to add the languages again. plpgsql was already loaded from the last time, but shared memory failed again when it tried to load pltcl. ipcs isn't installed on Panther. Strangely though, I've found ipcs in the Darwin source tree (previous version) under /usr/bin, and in the same place in FreeBSD source tree. /s. On Nov 6, 2003, at 2:41 PM, Tom Lane wrote: Scott Goodwin <[EMAIL PROTECTED]> writes: psql:/Users/scott/m/ops/database/sql/add_languages.sql:13: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. ...output in the log file is: LOG: server process (PID 2739) was terminated by signal 10 Here's the real problem --- why are you getting a SIGBUS while trying to load the pltcl handler function? I suspect something broken in Tcl's shared library, but dunno what. You should be getting a core file from the crashed process --- can you get a stack trace from it with gdb? FATAL: could not create shared memory segment: Cannot allocate memory DETAIL: Failed system call was shmget(key=5432001, size=3809280, 03600). This is evidently happening during attempted restart after the backend crash. I suspect it is a matter of the OS not having released the old memory segment yet, together with the SHMMAX limit being too tight to allow two such segments to exist concurrently. Are you able to start the server by hand immediately afterwards, or a few seconds afterwards? Or do you have to reboot before it will restart? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] PostgreSQL 7.4RC1 crashes on Panther
After recompiling with GCC 3.1 it fails when I'm running initdb to create the cluster -- it's a shmget error again. I believe that takes both Tcl and PostgreSQL out of the suspect pool and leaves Mac OS 10.3 as the primary culprit. I installed Panther last week from scratch (reformatted disk etc.) and haven't made any mods to it aside from the SystemTuning params today. I haven't had any other apps crash, and I'm using the system all day using Apple's apps, AOLserver, OpenSSL and others. I tried gdb to get a backtrace but the signal gets caught by postgres, so it doesn't dump me back to the gdb command line. I'll have to set breakpoints, have GDB do something with the signal, or mod PG to not catch it. That'll have to wait until tomorrow or Saturday. thanks for the assist, /s. On Nov 6, 2003, at 2:41 PM, Tom Lane wrote: Scott Goodwin <[EMAIL PROTECTED]> writes: psql:/Users/scott/m/ops/database/sql/add_languages.sql:13: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. ...output in the log file is: LOG: server process (PID 2739) was terminated by signal 10 Here's the real problem --- why are you getting a SIGBUS while trying to load the pltcl handler function? I suspect something broken in Tcl's shared library, but dunno what. You should be getting a core file from the crashed process --- can you get a stack trace from it with gdb? FATAL: could not create shared memory segment: Cannot allocate memory DETAIL: Failed system call was shmget(key=5432001, size=3809280, 03600). This is evidently happening during attempted restart after the backend crash. I suspect it is a matter of the OS not having released the old memory segment yet, together with the SHMMAX limit being too tight to allow two such segments to exist concurrently. Are you able to start the server by hand immediately afterwards, or a few seconds afterwards? Or do you have to reboot before it will restart? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] PostgreSQL 7.4RC1 crashes on Panther
Awesome! Thanks so much for the fix -- I depend on PostgreSQL and Tcl on my powerbook to do development work. cheers, /s. On Nov 8, 2003, at 2:09 PM, Tom Lane wrote: It turns out that the "createlang pltcl" failure on OS X 10.3 was due to our ps_status code doing the wrong thing. I have committed a fix. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] connection handling in 7.4.1
Hi, Postgres is part of the openSource repository DSpace which we are running here at ANU. I upgraded from 7.4 to 7.4.1 on 17 January. Today (21/1) it appears that either the number of connections has been reached (which is not possible on my local install) or the database itself has locked up. Postmaster was restarted on 20/1 so the problemt has taken 2 days to surface. I have not had a chance to look much deeper into the problem as I don't expect to get time to investigate until next week. The log output postgres returned is as follows: FATAL: the database system is shutting down The application log is as follows: Note that postgres is the only thing that has changed, no other software has been updated. This did not occur under 7.4 A secondary issue is that postmaster will not shut down properly under 7.4.1, I always have to use the "fast" shutdown mode. Has anything changed in the connection handling, as if connections are not being released this could easily cause the first problem? Again, this appears peculiar to 7.4.1. Thanks. Scott. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] [HACKERS] Mac OS X, PostgreSQL, PL/Tcl
Found the problem. If I have a very long environment variable exported and I start PG, PG crashes when I try to load PG/Tcl. In my case I use color ls and I have a very long LS_COLORS environment variable set. I have duplicated the problem by renaming my .bashrc and logging back in. With this clean environment, I started PG and loaded PG/Tcl without any problems. I then created the following environment variable on the command line: LONG_VAR=aa:bbb:cc: ddd:eee:fff: g::iii: j:kk:: mmm:n: ooo:pp:qqq: rrr:ss: ttt:u: vv:ww: xxx:y: zzz and exported it. (Obviously the line above is going to be broken into multiple lines by the mailer...). Then I stopped and restarted PG, loaded PG/Tcl and PG crashed. You *must* stop and restart PG for the problem to exhibit itself, otherwise it won't pick up the change in the environment. I suspect I'm running into a buffer overflow situation. Ok, it fails consistently when LONG_VAR is 523 characters or greater; works consistently when LONG_VAR is 522 characters or smaller. Might not fail at the same number for others. /s. To prove that this was the problem, I cleaned out my environment by moving my .bashrc file to another name, logged out, logged in, start On Feb 21, 2004, at 1:51 AM, Tom Lane wrote: Scott Goodwin <[EMAIL PROTECTED]> writes: Hoping someone can help me figure out why I can't get PL/Tcl to load without crashing the backend on Mac OS 10.3.2. FWIW, pltcl seems to work for me. Using up-to-date Darwin 10.3.2 and PG CVS tip, I did configure --with-tcl --without-tk then make, make install, etc. pltcl installs and passes its regression test. psql:/Users/scott/pgtest/add_languages.sql:12: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Can you provide a stack trace for this? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] [HACKERS] Mac OS X, PostgreSQL, PL/Tcl
I'm certain that the length of a single env var is the only factor
involved, and not the size of the enviroment itself. If I login to my
normal environment and unset LS_COLORS, everything works fine. If I
move my .bashrc out of the way, login fresh and create an env var > 522
chars, it fails. My login environment is much larger than the
environment I get without . bashrc, and the results of setting a single
env var to > 522 chars duplicates the problem in both envs. leading me
to believe that env size doesn't have an effect on this problem. I've
now set my PG startup script to 'unset LS_COLORS' before starting PG,
and this works great. Has anyone else tried to duplicate this problem?
I'm using Mac OS 10.3.2, PG 7.4.1, Tcl 8.4.5.
/s.
On Feb 22, 2004, at 12:21 PM, Tom Lane wrote:
Scott Goodwin <[EMAIL PROTECTED]> writes:
Found the problem. If I have a very long environment variable exported
and I start PG, PG crashes when I try to load PG/Tcl. In my case I use
color ls and I have a very long LS_COLORS environment variable set.
Interesting. Did you check whether the limiting factor is the longest
variable length, or the total size of the environment? ("env|wc" would
probably do as an approximation for the latter.)
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] [HACKERS] Mac OS X, PostgreSQL, PL/Tcl
I'll grab the CVS PG copy and try it out. Is this something the Darwin folks should be notified about? It might cause problems with other apps. thanks, /s. On Feb 22, 2004, at 4:47 PM, Tom Lane wrote: Scott Goodwin <[EMAIL PROTECTED]> writes: Found the problem. If I have a very long environment variable exported and I start PG, PG crashes when I try to load PG/Tcl. In my case I use color ls and I have a very long LS_COLORS environment variable set. I was able to duplicate this. I am not entirely sure why the problem is dependent on the environment size, but I now know what causes it. It seems Darwin's libc keeps its own copy of the argv pointer, and when we move argv and then scribble on the original, it causes problems for subsequent code that tries to look at argv[0] to determine the executable's location. (It's a good thing Darwin is open source, 'cause I'm not sure we'd have ever seen the connection if we hadn't been able to look at the source code for their libc.) The fix is basically + #if defined(__darwin__) + #include + #endif + #if defined(__darwin__) + *_NSGetArgv() = new_argv; + #endif which you can stick into main.c if you need a workaround. I applied a more extensive patch to HEAD that refactors this code into ps_status.c, but I'm disinclined to apply that patch to stable branches... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] [GENERAL] bug in 7.4.2, concern unicode and russian content of
On Mon, 2004-06-07 at 12:11, Alexander S. wrote: > There is bug in 7.4.2, concerning unicode and russian letters. For db > in unicode russian data doesn`t order in alphabetical order (rows group > with the same first letter but not in alphabetical order). > SELECT "person" from my_table ORDER BY "person"; > Rows group in such order (approximately): Ð-Ð-Ð-Ð-Ð, but must be : > Ð-Ð-Ð-Ð-Ð. > For english letters all looks fine. For db in koi8r encoding also all > works right. So, I CANNOT use unicode with russian content of db in > postgres. Is it bug or not? What locale was your database initialized with? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] [GENERAL] Question on the 8.0Beta Version
On Fri, 2004-10-22 at 00:59, Davide Negri wrote: > Hello, > > i have installed postgres 8.0 beta3 as a program on my pc on windows > xp. I have read on the installation note file that postgres server > will not run with administrative permissions. I have read on your > forum that this happened because i have installed the beta version: is > it true that this happen only with the beta version? When will you > plan to release the production version? I think you may have misunderstood the docs. PostgreSQL doesn't run under any account that has machine admin / root privelages because that makes any small security issue in postgresql into a root level exploit, and that's a bad thing. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] PostgreSQL 8.0 Beta 4 - Qualified ORDER BY column name not working on UNION query
I am running PostgreSQL 8.0 Beta 4 (Windows installer) on Windows XP Pro SP2. The query below has three ORDER BY clauses. When I execute it with the uncommented clause an error results. Some further commentary is included in the comments below. I would expect the uncommented clause to produce the same result as the other two commented out clauses. -- Qualified ORDER BY column name not working on UNION query (simple example). SELECT TURBINE_USER.USER_ID FROM TURBINE_USER WHERE TURBINE_USER.USER_ID = 1 UNION SELECT TURBINE_USER.USER_ID FROM TURBINE_USER WHERE TURBINE_USER.USER_ID = 2 -- The following works. --ORDER BY 1 ASC -- The following does not work when I would perhaps expect it to (it certainly works when a non-UNION query is used). ORDER BY TURBINE_USER.USER_ID ASC -- The following also works as I would expect it to unless more than one USER_ID column appears in the column list. --ORDER BY USER_ID ASC -- For the case that does not work the message is: -- -- NOTICE: adding missing FROM-clause entry for table "turbine_user" -- -- ERROR: ORDER BY on a UNION/INTERSECT/EXCEPT result must be on one of the result columns -- I haven't tried a case where the sort column (in this case USER_ID) appears more than once in the column list. I will not be surprised at all if the above is expected behaviour, in which case I apologise for wasting your time. Incidentally, the error message that occurs if I EXPLAIN the above query is as above but with an additional line that seems out of place to me: Query inserted one rows with OID 0. Also, if I EXPLAIN this query with one of the working ORDER BY clauses it produces a result, but if I select the ANALYSE option (I am using the pgAdmin III that comes bundled with the Beta 4 Windows installer) I get something completely nonsensical: ERROR: syntax error at or near "ROLLBACK" at character 897 Thanks, Scott -- Scott Eade Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] [pgsql-www] BUG #1355: 8.0.0 rc2 installer fails
The following bug has been logged online: Bug reference: 1355 Logged by: Scott Stillwell Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Windows XP Pro SP2 Description:8.0.0 rc2 installer fails Details: When installing PostgreSQL 8.0.0 rc2 on my computer (Windows XP Professional, SP2 and all current patches), I accepted all defaults (with the exception of assigning a password to the local Windows account and the postgres password). I get the following error near the end of the process: Failed to run initdb: -1073741512! Please see the logfile in 'C:\Program Files\PostgreSQL\8.0.0-rc2\tmp\initdb.log'. Note! You must read/copy this logfile before you click OK, or it will be automatically removed. While the dialog box is still displayed, I checked the initdb.log file. It is zero bytes with no contents. After clicking OK, the installer rolls back, at which point I get another dialog titled "Fatal Error" saying Installation ended prematurely because of an error. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] [pgsql-www] BUG #1355: 8.0.0 rc2 installer fails
I assume the script is broken..._I_ sure didn't send it to -www :) No, no real lockdown except for the Windows Firewall that installs with SP2, but it didn't complain or offer to block or unblock as usual. The postgres account that it created was granted the 'logon as a service' right, but I haven't checked permissions...what directories would it need access to beyond its own tree? Special permissions beyond "logon as a service"? I will retry the install and check the initdb.bat file for paths. The Application event log contains two messages for each attempted install. The first error nearly mirrors the displayed error: Product: PostgreSQL 8.0.0-rc2 -- Failed to run initdb: -1073741512! Please see the logfile in 'C:\Program Files\PostgreSQL\8.0.0-rc2\tmp\initdb.log'. Note! You must read/copy this logfile before you click OK, or it will be automatically removed. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. The second message is informational and is as follows: Product: PostgreSQL 8.0.0-rc2 -- Installation failed. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. No further information is in the System or Security event logs. Thanks for the reply...I'll forward more information as I acquire it. Regards, Scott Stillwell -Original Message- From: Magnus Hagander [mailto:[EMAIL PROTECTED] Sent: Thursday, December 23, 2004 3:00 AM To: Scott Stillwell; [EMAIL PROTECTED]; pgsql-bugs@postgresql.org Subject: RE: [pgsql-www] BUG #1355: 8.0.0 rc2 installer fails (um, why was this filed to -www? Copying over to -bugs where it should be. Something wrong with the scripts, I assume) > The following bug has been logged online: > > Bug reference: 1355 > Logged by: Scott Stillwell > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0 > Operating system: Windows XP Pro SP2 > Description:8.0.0 rc2 installer fails > Details: > > When installing PostgreSQL 8.0.0 rc2 on my computer (Windows XP > Professional, SP2 and all current patches), I accepted all defaults > (with the exception of assigning a password to the local Windows > account and the postgres password). I get the following error near > the end of the process: > > Failed to run initdb: -1073741512! > Please see the logfile in 'C:\Program > Files\PostgreSQL\8.0.0-rc2\tmp\initdb.log'. > Note! You must read/copy this logfile before you click OK, or it will > be automatically removed. > > While the dialog box is still displayed, I checked the initdb.log > file. It is zero bytes with no contents. > > After clicking OK, the installer rolls back, at which point I get > another dialog titled "Fatal Error" saying > > Installation ended prematurely because of an error. Very interesting error :-) That means the initdb process exited with an error code that certainly didn't come from initdb... Have you installed any non-standard security products, or done any lockdown from the standard level of the system? So that perhaps the postgres account doesn't have access to required DLL files? Also, when this happens, can you check the contents of 8.0.0-rc2\tmp\initdb.bat and see if the paths entered there are correct? Finally, do you get anything in the windows event logs when this happens? //Magnus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] [pgsql-www] BUG #1355: 8.0.0 rc2 installer fails
Found the problem...it's been reported before. http://archives.postgresql.org/pgsql-bugs/2004-11/msg00195.php I was a bad boy and left off the part about the missing ordinal in libeay32.dll... Dunno if that's something that still needs to be fixed, but at least I've got a workaround. Scott -Original Message- From: Magnus Hagander [mailto:[EMAIL PROTECTED] Sent: Thursday, December 23, 2004 3:00 AM To: Scott Stillwell; [EMAIL PROTECTED]; pgsql-bugs@postgresql.org Subject: RE: [pgsql-www] BUG #1355: 8.0.0 rc2 installer fails (um, why was this filed to -www? Copying over to -bugs where it should be. Something wrong with the scripts, I assume) > The following bug has been logged online: > > Bug reference: 1355 > Logged by: Scott Stillwell > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0 > Operating system: Windows XP Pro SP2 > Description:8.0.0 rc2 installer fails > Details: > > When installing PostgreSQL 8.0.0 rc2 on my computer (Windows XP > Professional, SP2 and all current patches), I accepted all defaults > (with the exception of assigning a password to the local Windows > account and the postgres password). I get the following error near > the end of the process: > > Failed to run initdb: -1073741512! > Please see the logfile in 'C:\Program > Files\PostgreSQL\8.0.0-rc2\tmp\initdb.log'. > Note! You must read/copy this logfile before you click OK, or it will > be automatically removed. > > While the dialog box is still displayed, I checked the initdb.log > file. It is zero bytes with no contents. > > After clicking OK, the installer rolls back, at which point I get > another dialog titled "Fatal Error" saying > > Installation ended prematurely because of an error. Very interesting error :-) That means the initdb process exited with an error code that certainly didn't come from initdb... Have you installed any non-standard security products, or done any lockdown from the standard level of the system? So that perhaps the postgres account doesn't have access to required DLL files? Also, when this happens, can you check the contents of 8.0.0-rc2\tmp\initdb.bat and see if the paths entered there are correct? Finally, do you get anything in the windows event logs when this happens? //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #1569: Threads don't see ecpg default connection
The following bug has been logged online:
Bug reference: 1569
Logged by: Gavin Scott
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: Fedora Core 3
Description:Threads don't see ecpg default connection
Details:
When using postgresql 8.0 compiled with --enable-thread-safety, new threads
no longer see the default ecpg connection. That was not the case in 7.4.x
compiled with or without --enable-thread-safety.
TEST CASE
The program at the end of this mail sets up a database table named
"dbthreadtest" in the default database. It then spawns 5 threads which each
do a select from that table using the default connection.
If the program is saved as dbthreadtest.pgc, compile with:
ecpg -t -o dbthreadtest.c dbthreadtest.pgc
gcc -Wall -o dbthreadtest dbthreadtest.c -lecpg -lpthread
Results under 7.4.x / 8.0 without --enable-thread-safety:
[EMAIL PROTECTED] protocol_lib]$ psql --version
psql (PostgreSQL) 7.4.7
contains support for command-line editing
[EMAIL PROTECTED] protocol_lib]$ ./dbthreadtest
got id = 1
got id = 1
got id = 1
got id = 1
got id = 1
Results under 8.0 with --enable-thread-safety:
[EMAIL PROTECTED] protocol_lib]$ psql --version
psql (PostgreSQL) 8.0.1
contains support for command-line editing
[EMAIL PROTECTED] protocol_lib]$ ./dbthreadtest
'No such connection NULL in line 76.', sqlcode = -220 select id
TEST PROGRAM
/* -*-C-*- */
#include
#include
#define CHECK_SQL(fmt, args...) \
do \
{ \
if (sqlca.sqlcode != ECPG_NO_ERROR) \
{ \
fprintf (stderr, "'%s', sqlcode = %ld " fmt "\n", \
sqlca.sqlerrm.sqlerrmc, \
sqlca.sqlcode, ## args); \
exit (1); \
} \
} \
while (0)
#define FATAL(fmt, args...) \
do \
{ \
fprintf (stderr, fmt "\n", ## args); \
exit (1); \
} \
while (0)
pthread_mutex_t global_lock;
pthread_t global_threads[5];
void
setup_db ()
{
exec sql begin declare section;
const char *_user;
exec sql end declare section;
pthread_mutex_lock (&global_lock);
_user = getenv ("LOGNAME");
exec sql connect to :_user;
CHECK_SQL ("connect");
exec sql create table dbthreadtest (id int);
CHECK_SQL ("create dbthreadtest");
exec sql insert into dbthreadtest (id) values (1);
CHECK_SQL ("insert 1");
pthread_mutex_unlock (&global_lock);
}
void
teardown_db ()
{
pthread_mutex_lock (&global_lock);
exec sql drop table dbthreadtest;
CHECK_SQL ("drop dbthreadtest");
exec sql disconnect;
CHECK_SQL ("disconnect");
pthread_mutex_unlock (&global_lock);
}
void *query_db (void *ignorep)
{
exec sql begin declare section;
int _id;
exec sql end declare section;
pthread_mutex_lock (&global_lock);
exec sql select id into :_id from dbthreadtest;
CHECK_SQL ("select id");
fprintf (stdout, "got id = %d\n", _id);
pthread_mutex_unlock (&global_lock);
return NULL;
}
int
main ()
{
int i;
pthread_mutex_init (&global_lock, NULL);
setup_db ();
for (i = 0; i < sizeof (global_threads) / sizeof (global_threads[0]);
++i)
{
if (pthread_create (&global_threads[i], NULL, query_db, NULL))
FATAL ("pthread_create %d failed", i);
}
for (i = 0; i < sizeof (global_threads) / sizeof (global_threads[0]);
++i)
{
if (pthread_join (global_threads[i], NULL))
FATAL ("pthread_join %d failed", i);
}
teardown_db ();
return 0;
}
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #1569: Threads don't see ecpg default connection
On Sat, 2005-05-07 at 12:37 -0400, Bruce Momjian wrote: > Are you still seeing a failure in ecpg? I ran your test here and got: > > got id = 0 > got id = 0 > got id = 0 > got id = 0 > got id = 0 > > This is with thread safety enabled and CVS HEAD, which matches 8.0.X. Hi Bruce, This was fixed by r1.25 of pgsql/src/interfaces/ecpg/ecpglib/connect.c : revision 1.25 date: 2005/04/14 10:08:57; author: meskes; state: Exp; lines: +24 -7 Added patch by Philip Yarra <[EMAIL PROTECTED]> for a bug in thread support. ---- -- Gavin Scott [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] BUG #2226: Can't delete elements from Enterprise Architect diagram when using PostgreSQL ANSI ODBC driver
The following bug has been logged online: Bug reference: 2226 Logged by: Doug Scott Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Windows XP Pro Description:Can't delete elements from Enterprise Architect diagram when using PostgreSQL ANSI ODBC driver Details: Sparx, makers of EA, allows many DBMSs such as Postgres DBMS to be a backend repository for this UML modeling tool. PostgreSQl ANSI ODBC driver found in file psqlodbc-08_01_0102.zip does not permit diagram elements in Enterprise Architect (v. 6.1) to be deleted. Adds, updates work, but deletes do not. Get msg "Enterprise Architect has encountered a problem and will close now." when attempt to delete elements (eg. classes, activities) from a UML (eg. class, activity) model. When version found in psqlodbc-08_00_0101.zip was used instead, deletes worked fine. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #2299: pg_dump error w/ renamed primary keys
The following bug has been logged online: Bug reference: 2299 Logged by: Gavin Scott Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: fedora core 4 Description:pg_dump error w/ renamed primary keys Details: If you rename a primary key, pg_dump tries to recreate it with the original name. Here is how to recreate: [EMAIL PROTECTED] ~]$ createdb bug CREATE DATABASE [EMAIL PROTECTED] ~]$ psql bug << EOF > CREATE TABLE foo ( id integer ); > ALTER TABLE foo ADD CONSTRAINT foo_pkey PRIMARY KEY (id); > ALTER TABLE foo_pkey RENAME TO bar_pkey; > EOF CREATE TABLE NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "foo_pkey" for table "foo" ALTER TABLE ALTER TABLE [EMAIL PROTECTED] ~]$ echo '\d foo' | psql bug Table "public.foo" Column | Type | Modifiers +-+--- id | integer | not null Indexes: "bar_pkey" PRIMARY KEY, btree (id) [EMAIL PROTECTED] ~]$ pg_dump bug | grep -B 1 -i key -- -- Name: foo_pkey; Type: CONSTRAINT; Schema: public; Owner: postgres81; Tablespace: -- ALTER TABLE ONLY foo ADD CONSTRAINT foo_pkey PRIMARY KEY (id); ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #5613: cannot delete
I already have done this but this file still remains. There is no problem with windows, the compute is like new and runs everyting else smooth. This is the only problem i have ever had, i have even tried deleting the file through CMD but no luck it still will not delete. Can you tell me what the pg_stat_tmp file is used for? > Date: Thu, 12 Aug 2010 16:39:54 -0400 > Subject: Re: [BUGS] BUG #5613: cannot delete > From: robertmh...@gmail.com > To: wheels7...@hotmail.com > CC: pgsql-bugs@postgresql.org > > On Wed, Aug 11, 2010 at 1:41 PM, Scott wrote: > > > > The following bug has been logged online: > > > > Bug reference: 5613 > > Logged by: Scott > > Email address: wheels7...@hotmail.com > > PostgreSQL version: 8.4 > > Operating system: vista > > Description:cannot delete > > Details: > > > > I have recently tried to install PostgreSQL to use with poker tracker. I > > have having problems connecting to the server, where then i was advised to > > completly remove and download again. I have come accross a file located in > > c:\programfilmes, called PostgresSQL. I am unable to delete this folder > > file, even when using CMD it says the file cannot be found. I then proceeded > > to open this file and delete the items individually to see what was left, > > all the files were able to delete except one: pg_stat_tmp Please could you > > help with this as i have spoke to comuter technichian company and they were > > unable to remove the file. > > I think you have a Windows program rather than a PostgreSQL problem. > Based on my limited previous experience with Windows, problems like > this are often caused by trying to delete a file while it's in use. > Perhaps you need to stop the PostgreSQL service. > > An even better idea might be to uninstall PostgreSQL using Add/Remove > Programs, or whatever uninstaller came with the installer you used. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise Postgres Company
Re: [BUGS] [GENERAL] postgresql-8.4 error
On Mon, Nov 29, 2010 at 8:02 AM, Mohammed Rashad wrote: > > I am running ubuntu 10.04 > I have problem installing postgresql-8.4 > when i tried to start postgresql > /etc/init.d/postgresql-8.4 start > I am getting this error > * Starting PostgreSQL 8.4 database server > * Error: could not exec > /usr/lib/postgresql/8.4/bin/pg_ctl /usr/lib/postgresql/8.4/bin/pg_ctl start > -D /var/lib/postgresql/8.4/main -l > /var/log/postgresql/postgresql-8.4-main.log -s -o -c > config_file="/etc/postgresql/8.4/main/postgresql.conf" : I run ubuntu 10.04 and postgresql 8.4 just fine. Could you provide more info on how you've instaled 8.4? Was it through a normal apt-get install method? Or did you download some .deb packages somewhere and dpkg install them? Or compile by hand and using the service scripts that come with pgsql? The more you tell us how you've done things, the more we can help. -- 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 #5898: Nested "in" clauses hide bad column names
The following bug has been logged online: Bug reference: 5898 Logged by: Scott Dunbar Email address: sc...@xigole.com PostgreSQL version: 9.0.3 Operating system: Ubuntu 10.10 Description:Nested "in" clauses hide bad column names Details: I have a nested in clause like: select respondent_id from respondent where respondent_id in (select respondent_id from chat_session where project_id in (select project_id from project where company_id = 4)); However, in this example, there is no column named respondent_id in the chat_session table. But the query runs and, indeed, returns all of the rows in respondent. Since this was then part of another nested in it deleted far more that it was supposed to. -- 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 #5898: Nested "in" clauses hide bad column names
Yes, you're correct. I guess this makes sense but it does seem strange
that I can enter garbage in a query but it still runs. And in my case
the output from this (the entire table) was then used in a delete
statement that toasted the entire table. Allowing bogus SQL just seems
"wrong" but I do understand what's going on.
Thanks for your help.
On 02/22/2011 10:45 AM, Tom Lane wrote:
"Scott Dunbar" writes:
I have a nested in clause like:
select respondent_id from respondent where respondent_id in (select
respondent_id from chat_session where project_id in (select project_id from
project where company_id = 4));
However, in this example, there is no column named respondent_id in the
chat_session table.
Probably there is one in respondent, though? This behavior is not a bug
--- what you have there is an outer reference, and it is working exactly
as specified by the SQL standard. Sub-selects would be a whole lot less
useful if they couldn't refer to variables of the outer query.
regards, tom lane
--
Scott Dunbar
Xigole Systems, Inc.
Enterprise software consulting, development, and hosting
303·667·6343
Re: [BUGS] BUG #5995: connection pooling not working
First, this isn't a bug... this is more of a discussion for -general or -admin. On Wed, Apr 27, 2011 at 9:44 AM, Kevin Grittner wrote: > "Suprabhat" wrote: > > > FATAL: too many connections already and there are too many > > postgres processes on the server. We have used connection > > pooling methods after unsuccessfully using pgpool2. > > Is there a thread somewhere where you were trying to get help > configuring pgpool? > Agreed, pgpool is quite sensitive to being configured properly. If you're using the pooler and you are still getting that error, it is definitely a configuration issue. > > > Probably we are doing some basics wrong. > > > > Total number of connections we are trying to make is something > > around 300 concurrently. > > Well, the main point of a connection pool is to allow multiple > client-side processes or threads to see a large number of logical > connections to the database while those funnel down to a small > number on the database side. 300 active users might do quite well > on a connection pool which maintains 10 or 20 connections to the > database. It sounds like you haven't used the correct settings to > achieve that. > > In all honesty, if you're just looking for a connection pool, I personally prefer pgbouncer. That being said, pgpool provides a lot of other features (load-balancing, replication,etc...). -Kevin > > -- > 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 #6132: Cannot install rpm files
On Wed, Jul 27, 2011 at 11:19 AM, Nivas wrote: > > The following bug has been logged online: > > Bug reference: 6132 > Logged by: Nivas > Email address: niva...@gmail.com > PostgreSQL version: 9.0 > Operating system: Fedora 15 > Description:Cannot install rpm files > Details: > > Hi > > I cannot install postgresql on Fedora 15, please provide the installation > procedure for Fedora 15. > > A) Where did you download them from (exact URL) ? B) What is the error you are getting? C) http://wiki.postgresql.org/wiki/Guide_to_reporting_problems --Scott > Thank you > > -- > 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 #6182: /etc/init.d/postgresql-8.4 is incomplete for chkconfig
On Mon, Aug 29, 2011 at 1:19 PM, Steven Williams wrote: > > The following bug has been logged online: > > Bug reference: 6182 > Logged by: Steven Williams > Email address: stwilli...@novell.com > PostgreSQL version: 8.5.3 > I'm guessing you mean 8.4.3? > Operating system: SuSE Linux 11 > Description:/etc/init.d/postgresql-8.4 is incomplete for chkconfig > Details: > > currently in the script, there is the following: > > # chkconfig: 2345 85 15 > # description: Starts and stops the PostgreSQL 8.4 database server > > > The following also needs to be added: > > ### BEGIN INIT INFO > # Provides: PostgreSQL > # Required-Start: > # Required-Stop: > # Default-Start: 3 5 > # Default-Stop: 0 1 6 > # Description: Start/Stop Script for PostgreSQL 8.4 database server > ### END INIT INFO > > Where did you download postgres from / how did you install it? --Scott > -- > 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] Could not find your PostgreSQL installation in /var/lib/pgsql
On Thu, Apr 5, 2012 at 8:14 AM, Terrance Chen wrote:
> system=fedora15
> software env=all software in DVD are completely installed(include pgsql
> psql) and some thing like pppoe
> postgresql are install with fedora by default option,
> /etc/passwd/:postgres PostgreSQL
> Server:/var/lib/pgsql:/bin/bash
>
> operations:
> su - postgres
> initdb -D /var/lib/pgsql/data -E UTF-8
> pg_ctl -D /var/lib/pgsql/data -l logfile start
> pg_ctl status {terminal return pg_ctl: (PID:
> 3052)/usr/bin/postgres
> "-D" "/var/lib/pgsql/data"}
> createdb DatabaseName
> psql DatabaseName
> su - root
> cd /home/download/pgadmin3-1.14.0
> ./configure --with-pgsql=/var/lib/pgsql
>
/var/lib/pgsql is your data directory. --with-pgsql is looking for
binaries.
try ./configure --with-pgsql=/usr/
or
./configure --with-pgsql=/usr/bin/
--Scott
>
> { Could not find your PostgreSQL installation in /var/lib/pgsql }
>
Re: [BUGS] BUG #6649: Reg: Password error
On Thu, May 17, 2012 at 8:26 AM, wrote: > The following bug has been logged on the website: > > Bug reference: 6649 > Logged by: Subramanian > Email address: subu@gmail.com > PostgreSQL version: 9.1.3 > Operating system: Windows Xp > Description: > > Hello there. We in our company using your product of PostgreSQL - 9.1.3 & > 8.3. But both of these products results in a Password Error. We all tried > with variuos passwords and got a Single error as Failed... Please respond > to > this bug ASAP. Thank you. > > This is most likely a configuration issue, not a bug. Please refer to http://wiki.postgresql.org/wiki/Guide_to_reporting_problems in order to get the solution to your problem. --Scott > > -- > 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 #7800: Welcome email with login ifnormation NOT received
Chrystel, I just verified, you never need to register in order to download postgres from the OpenSCG site. If you hit this link (from the postgres download site: http://www.openscg.com/se/postgresql/packages.jsp). You can click through and download without ever registering. --Scott On Tue, Jan 8, 2013 at 12:43 PM, wrote: > The following bug has been logged on the website: > > Bug reference: 7800 > Logged by: Brunet-Cambus > Email address: camb...@slb.com > PostgreSQL version: 9.2.2 > Operating system: PostgreSQL > Description: > > > I subscribed to be able to login to OpenSCG portal and so to download > PostgreSQL. Web site state that: "Your email is successfully subscribed. If > you are a new subscriber, you will receive a welcome email with > instructions > on how to login to OpenSCG portal." BUT I never received something and so > cannot download PostgreSQL! > > Could you please help me? > Many thanks in advance for your help. > > Best regards, > Chrystel > > > > > -- > 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 #7800: Welcome email with login ifnormation NOT received
On Tue, Jan 8, 2013 at 2:47 PM, Scott Mead wrote: > Chrystel, > >I just verified, you never need to register in order to download > postgres from the OpenSCG site. > > If you hit this link (from the postgres download site: > http://www.openscg.com/se/postgresql/packages.jsp). You can click > through and download without ever registering. > Just to be specific, the postgres download page never requires registration for download. ( We don't check for what site you are coming from ). --Scott > > --Scott > > > > On Tue, Jan 8, 2013 at 12:43 PM, wrote: > >> The following bug has been logged on the website: >> >> Bug reference: 7800 >> Logged by: Brunet-Cambus >> Email address: camb...@slb.com >> PostgreSQL version: 9.2.2 >> Operating system: PostgreSQL >> Description: >> >> >> I subscribed to be able to login to OpenSCG portal and so to download >> PostgreSQL. Web site state that: "Your email is successfully subscribed. >> If >> you are a new subscriber, you will receive a welcome email with >> instructions >> on how to login to OpenSCG portal." BUT I never received something and so >> cannot download PostgreSQL! >> >> Could you please help me? >> Many thanks in advance for your help. >> >> Best regards, >> Chrystel >> >> >> >> >> -- >> 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] MD5 checksum or RPM for PostgreSQL 8.7.3
Sorry for the confusion and ambiguity of the request. The files we are requesting the MD5 checksum for are located here: http://www.postgresql.org/ftp/binary/v8.3.7/linux/rpms/redhat/rhel-4-i386/ Thanks! P. Scott Hill Software Engineer, Web Development Group National Coastal Data Development Center General Dynamics Information Technology Stennis Space Center, MS 39529 (228) 688-3516 direct (228) 688-2968 fax p.scott.h...@noaa.gov John R Pierce said the following on 4/3/2009 11:24 AM: Dafina.Abernathy wrote: Hello Mr. Pierce, You are correct it is for version 8.3.7. for Redhat. My apologies for the mix-up. A member of the group has checked http://yums.postgresql.org and was unable to locate an RPM for Redhat. "Redhat" describes a dozen versions of Linux and a half dozen or more platforms. The yum postgres project has RPMs for RHEL 4.x and 5.x, on X86 and x86_64. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
