Re: [BUGS] BUG #5966: extract(epoch..) function error
On Wed, Apr 06, 2011 at 11:17:42PM +, Ricardo Solanilla wrote:
> -- try this
>
> select (extract(epoch from (date('2011-03-20'))) - extract(epoch from
> (date('2011-03-19' / 3600
>
> -- it must be 24 (hours), only occurs in march 19,2011
> -- in v. 8.0 work fine!!
Are you sure this isn't just daylight saving time coming into play? I get
this, using US/Mountain time, which is explainable because DST started on
2011-03-13. The specific date where this happens will vary by your time zone
of choice, as different places start daylight saving time on different dates.
5432 josh@josh*# select extract(epoch from '2011-03-13'::date) - extract(epoch
from '2011-03-12'::date);
?column?
--
86400
(1 row)
5432 josh@josh*# select extract(epoch from '2011-03-14'::date) - extract(epoch
from '2011-03-13'::date);
?column?
--
82800
(1 row)
5432 josh@josh*# select extract(epoch from '2011-03-15'::date) - extract(epoch
from '2011-03-14'::date);
?column?
--
86400
(1 row)
If I set my timezone to US/Arizona, where daylight saving time is not used at
all, I get the behavior you expected:
5432 josh@josh*# set timezone to "US/Arizona";
SET
5432 josh@josh*# select extract(epoch from '2011-03-13'::date) - extract(epoch
from '2011-03-12'::date);
?column?
--
86400
(1 row)
5432 josh@josh*# select extract(epoch from '2011-03-14'::date) - extract(epoch
from '2011-03-13'::date);
?column?
--
86400
(1 row)
5432 josh@josh*# select extract(epoch from '2011-03-15'::date) - extract(epoch
from '2011-03-14'::date);
?column?
--
86400
(1 row)
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
signature.asc
Description: Digital signature
Re: [BUGS] BUG #5945: serial repetition Error!
On Fri, Mar 25, 2011 at 08:26:09AM +, shenwenguang wrote: > PHP5 + PostgreSQL8.4 + ubuntu 11.04 > > 1: insert any items , about 1000 rows > 2: delete any items, about 100 rows > 3: repeat 1,2; > > When restart server, > that Error disappear, > repeat some deleted,insert operation, > mistakes occur again You haven't actually said what the error is, or what "mistakes" you've noticed. Without those details we can't do much to help you. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #5809: bigserial duplicate value
On Mon, Jan 03, 2011 at 11:04:17AM -0800, Jeff Davis wrote: > On Sun, 2011-01-02 at 11:40 +, mahmoud elzaiady wrote: > > i ask ,bigserial must not duplicate the value ? > > how solve this problem > > This is probably due to the sequence being reset somehow. Have you > dumped/reloaded recently? Did you manually back up or copy the table? Alternatively, perhaps at some point you've added data to that column, rather than relying on PostgreSQL to supply a default value. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme
On Sat, Nov 27, 2010 at 11:23:46AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > Where does your uniqueidentifier.so file come from? It's not a part of
> > standard PostgreSQL 9.0, and this is the part that's crashing..
>
> There used to be a project of that name on gborg. I can't find the
> source code anymore though.
How about
http://www.postgresql.org/ftp/projects/gborg/uniqueidentifier/stable/
> > Any chance it's a third party module that you didn't recompile for 9.0?
>
> The magic-block mechanism should prevent that. What I'm wondering about
> is whether the input function is (a) careless about null input and (b)
> not marked STRICT.
I think you're right:
PG_FUNCTION_INFO_V1(uniqueidentifier_out);
Datum
uniqueidentifier_out(PG_FUNCTION_ARGS)
{
char *result;
uniqueidentifier *in = (uniqueidentifier *) PG_GETARG_POINTER(0);
if (in == NULL)
PG_RETURN_CSTRING (NULL);
...and...
CREATE OR REPLACE FUNCTION uniqueidentifier_in(cstring)
returns uniqueidentifier
as 'MODULE_PATHNAME'
language 'c';
It should use PG_ARGISNULL(0), no?
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
signature.asc
Description: Digital signature
Re: [BUGS] BUG #5722: vacuum full does not update last_vacuum statistics
On Mon, Oct 25, 2010 at 11:03:07AM -0400, Tom Lane wrote: > Perhaps. The new implementation of VACUUM FULL is really more like a > CLUSTER, or one of the rewriting variants of ALTER TABLE. Should all > of those operations result in an update of last_vacuum? From an > implementation standpoint it's difficult to say that only some of them > should, because all of them result in a table that has no immediate > need for vacuuming. The only argument I can see for having only VACUUM > FULL update the timestamp is that it's called VACUUM and the others > aren't. Which is an argument, but not a terribly impressive one IMO. I agree it's an unimpressive argument; perhaps it's worth considering that last_vacuum doesn't really indicate how much a particular table needs vacuuming, either. Without the update/delete statistics telling you how much updating and deleting has happened since the last vacuum, there's really no way of guessing how vacuum-needy something might be based only on available statistics. last_vacuum is just a nice way of verifying that [auto]vacuum happens on the table sometimes, and influencing an administrator's WAGs about what needs vacuuming. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #5700: double-quoting column names
On Fri, Oct 08, 2010 at 12:20:35PM +, Piergiorgio Buongiovanni wrote:
> recently we experienced a strange behaviour with double quoting of column
> names in UPDATE statements.
>
> If you define a table as follows:
>
> create table erc.TestTable ( Name varchar );
>
> and then execute the following statement:
>
> INSERT INTO erc.TestTable( "Name" ) VALUES ('Test');
>
> you obtain the following error:
>
> ERROR: column "Name" of relation "TestTable" does not exist
> LINE 1: INSERT INTO erc.TestTable( "Name" ) VALUES ('Test');
The problem is you didn't double-quote the field name when you created the
table, so the column name was created in lowercase. From the documentation:
"Quoting an identifier also makes it case-sensitive, whereas unquoted names
are always folded to lower case." [1] So your CREATE TABLE statement created a
table called "erc.testtable" with a column called "name", and when you tried
to insert into a column called "Name", it failed.
I wonder, though, if you've shown us exactly what you did or not; in my
systems, the table name in the error message would all be lowercase. In any
event, as a rule, if you're going to quote your identifiers once, you need to
quote them all the time. For that reason, many people choose to stick with all
lowercase table and column names.
[1] http://www.postgresql.org/docs/9.0/interactive/sql-syntax-lexical.html
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
signature.asc
Description: Digital signature
Re: [BUGS] BUG #5698: pg_dump (8.3.11) does not consider constrains
On Fri, Oct 08, 2010 at 11:46:31AM +, Johannes Meidert wrote: > pg_dump dumps tables in the worng order for constraints (table a refrences > key of table b, but table a is dumped first). As a consequence an import > fails, because the required foreign key (in table b) is missing when table a > is imported. > Work around: import twice. > Is this fixed in version 9.0? Could you give details of exactly what pg_dump commands you used? By default pg_dump dumps tables and data without any constraints first, and then adds constraints in a valid order. If, however, you do something like dump the schema first, and then dump data into that schema, there's little pg_dump can do to avoid problems such as you describe. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #5618: restore won't work with files transferred with NFS
On Fri, Aug 13, 2010 at 02:01:02PM +, Pierre wrote: > > The following bug has been logged online: > > Bug reference: 5618 > Logged by: Pierre > Email address: pma...@neuf.fr > PostgreSQL version: 8.4.4 > Operating system: Linux > Description:restore won't work with files transferred with NFS > Details: > > Computer A running > Ubuntu 9.10, > On computer A, using pgAdmin3: > Backup database x into saveddb.backup This isn't nearly enough information to provide you any help at all. You haven't told us what you tried, what happend, or what you expected to happen. Please see http://www.postgresql.org/docs/current/static/bug-reporting.html -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #5573: How can i add field inbetween in the table while creating
On Tue, Jul 27, 2010 at 07:34:56AM +, Vimi wrote: > If i have already crreated one table and i wan to add one more field into > table but its ibetween imean if i have 4 fields are already created and if i > want to add one more field aat 2nd index then how can i do in postgre. i > tried in Navicat but no luck. You can't change column order without dropping and recreating the columns, recreating the table, or something similar. Sorry. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #5513: High availability with Postgres
On Sun, Jun 20, 2010 at 04:42:51PM +, Elior wrote: > My company looking for some solution for High availability with Postgres. > > Our optional solution is as follows : > Two DB servers will be using a common external storage (with raid). Both > servers are going to use the same DB files on the storage (as > active/passive) > > Now I'm trying to understand how Postgres can work with this configuration. > I.e : > > DB_server1 crashed, so we want to start DB_server2 using same files. > Is it possible ? It's possible, but it's not a bug; you'd be better served addressing your question to pgsql-gene...@postgresql.org. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
On Thu, Jun 03, 2010 at 06:04:16PM +0200, Hartmut Goebel wrote: > If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed > starting (something like "Database version mismatch"). So I downgraded > to 8.3, pg_dump'ed there, upgraded and pg_restore'd. pg_dump will complain if its version doesn't match the server version, but that's neither a bug nor, in this case, a bad thing. You have pg_dump's -i option which will squelch this message and allow pg_dump to continue. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] ERROR: failed to build any 3-way joins
On Sun, May 23, 2010 at 2:11 PM, Jehan-Guillaume (ioguix) de Rorthais wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > A user reported us the following bug under phpPgAdmin with 9.0beta1, but it > seems it comes from backend. > > Here is how to reproduce the bug: > > > > postgres=# SELECT version(); > version > - > -- > PostgreSQL 9.0beta1 on i686-pc-linux-gnu, compiled by GCC gcc (Debian > 4.4.3-2) 4.4.3, 32-bit > (1 row) > > postgres=# SELECT rolname FROM pg_catalog.pg_roles AS r, pg_auth_members AS m > WHERE r.oid=m.roleid > AND member IN ( > SELECT oid FROM pg_catalog.pg_roles > WHERE rolname='postgres') > ORDER BY rolname; > ERROR: failed to build any 3-way joins > < Just a guess, but I'd bet this was fixed by the very recent commit to fix this: http://archives.postgresql.org/pgsql-hackers/2010-05/msg01203.php -- Joshua Tolley / eggyknap End Point Corporation -- 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] psql or pgbouncer bug?
On Sat, May 22, 2010 at 5:56 PM, Tom Molesworth wrote: > Surely this is normal, expected behaviour - exactly the same as you'd get > from the mysql commandline client, for example? > Note that I'm not the original submitter - so I could be missing the point > entirely here! If you were missing it, you weren't the only one :) I misplaced some of the rest of this thread, and realize now that the question I was asking was already answered. - Josh -- 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] psql or pgbouncer bug?
2010/5/22 Tom Molesworth : > Hi Jakub, > > On 21/05/10 16:19, Jakub Ouhrabka wrote: >> >> can anyone tell me how this could happen, please? >> >> database=# begin; update table set col = 100; >> server closed the connection unexpectedly >> This probably means the server terminated abnormally >> before or while processing the request. >> The connection to the server was lost. Attempting reset: Succeeded. >> UPDATE 153 >> database=# ROLLBACK ; >> WARNING: there is no transaction in progress >> ROLLBACK > Seems to be trivially easy to reproduce by connecting via psql, then killing > that connection before issuing the 'begin; update' sequence (against > postgres directly, no pgbouncer needed). If anything, it's an issue with > psql settings? Maybe it should stop on connection drop rather than > attempting reconnect and continuing with further statements. Does PostgreSQL log anything more detailed? What if you update some other table similarly? It looks like some sort of data corruption on the table you're updating. -- Joshua Tolley / eggyknap End Point Corporation -- 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 #5393: Installer sets superuser password if passwords don't match
I accidentally rejected this message while moderating -bugs, so I'm forwarding it to the list to atone for myself. Apologies to all involved... - Forwarded message from pgsql-bugs-ow...@postgresql.org - Content-Description: Original message From: Rens Admiraal Date: Fri, 26 Mar 2010 20:00:27 GMT To: pgsql-bugs@postgresql.org Subject: BUG #5393: Installer sets superuser password if passwords don't match The following bug has been logged online: Bug reference: 5393 Logged by: Rens Admiraal Email address: r...@rensnel.nl PostgreSQL version: 8.4 Operating system: Windows Description:Installer sets superuser password if passwords don't match Details: I just installed PostgreSQL 8.4 on windows 7 64 bit using the oneclick installer. I didn't read the installation steps as normal :-) So I tried to set a username + password in the step where the superuser password is asked. Offcourse I got the error "Passwords don't match", I read the screen again, and thought "A nice, if no users excists, it will be created", and clicked next without filling anything. This also didn't work, and I could only get it to work using the username I filled in the first password field initially... I would expect the installation not to create a user at all at wrong input! So it might be better to check the values in the passwords fields first, and create the user if the passwords are equal... Greetz, Rens - End forwarded message - signature.asc Description: Digital signature
Re: [BUGS] Facing problem with pg_dump
On Tue, Mar 16, 2010 at 10:16:36AM +0530, venu gopal wrote: >Hi, >I have a problem with pg_dump. >This command is working when I run in command prompt. >pg_dump -i -h 127.0.0.1 -p 5433 -U postgres -F c -b -v -t log_term -t >log_admin_m -t log_admin_s -f C:\Backup_TFGRSLog_2010-03-13131631.dat >infoinfo >After release my asp.net application pg_dump is not able to take backup. >Is there any permission I need to give for this? >Please help me. What behavior, exactly, are you seeing? Do you get any error messages? What does your application try to do with pg_dump? There's not much detail here to allow us to help you out. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] pg_dump -d
On Tue, Mar 02, 2010 at 11:09:49AM +, Vincent Maury wrote: > Hi, > > it seems pg_dump doesn't like -d option although it accepts --inserts. Same > with -D and --column-inserts. > I'm using pg_dump 8.4.1 on Ubuntu 9.10. I hope this is useful for you. > Thank you very much, > > Vincent pg_dump's options changed between 8.3 and 8.4, in order to help prevent potentially catastrophic slowdowns when people mistook the -d and -D options to mean "Connect to this database" rather than as equivalents of --inserts and --column-inserts. See the documentation for more details: http://www.postgresql.org/docs/8.4/interactive/app-pgdump.html http://www.postgresql.org/docs/8.4/interactive/release-8-4.html -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #5357: PGAdmin: SQL Query Editor does not (always) open files
On Tue, Mar 02, 2010 at 10:08:55AM +, Julien wrote: > Description:PGAdmin: SQL Query Editor does not (always) open files A better place for pgadmin problems is the pgadmin-support list: http://www.pgadmin.org/support/list.php -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #5330: No CREATE SYNONYM command
On Wed, Feb 17, 2010 at 05:41:45AM +, zhuge wrote: > I want to port from Oracle to PostgreS. But Postgres has no the command, > CREATE SYNONYM, > which exists in Oracle. I have read the information, > http://archives.postgresql.org/pgsql-patches/2006-03/msg00085.php, and > download the file. However, I DO NOT know how to use the create synonym > command in Postgres. How can I to use that command? Please help me ! PostgreSQL doesn't support Oracle's concept of synonyms. The message you read is from a patch that eventually was rejected. How you might replicate Oracle's synonyms in PostgreSQL depends on your specific use case. You might consider emailing pgsql-general with details about what precisely you use synonyms for, to get help on your porting project. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #5231: SELECT DISTINCT poorly implemented vs SELECT ... GROUP BY
On Thu, Dec 03, 2009 at 03:56:05PM +, Thomas Hamilton wrote: > > The following bug has been logged online: > > Bug reference: 5231 > Logged by: Thomas Hamilton > Email address: thomashamilto...@yahoo.com > PostgreSQL version: 8.3.8 > Operating system: Ubuntu 4.2.4 > Description:SELECT DISTINCT poorly implemented vs SELECT ... GROUP > BY > Details: > > SELECT DISTINCT does a Sort followed by Unique. > > SELECT ... GROUP BY, which is logically equivalent, performs a > HashAggregate. > > When run against a large dataset with a small number of distinct results > HashAggregate is an order of magnitude more efficient! > > Since the spec does not require DISTINCT to return sorted results, I don't > believe Sort ... Unique will ever be more efficient than HashAggregate. > > Therefore, in order to maximize performance, DISTINCT should always be > implemented as HashAggregate. In 8.4 and above, SELECT DISTINCT can use HashAggregates rather than Sort/Unique -- though I'm not sure it always does. Anyway, an upgrade should handle this for you. However, this isn't really a bug, it's a feature, so don't expect to see it in an 8.3.x version. -- Josh / eggyknap signature.asc Description: Digital signature
Re: [BUGS] BUG #5087: Submitted bug reports not showing up in a timely manner (or at all)
On Tue, Sep 29, 2009 at 10:33:09PM +0200, Magnus Hagander wrote: > > To pick a recent case, bug #5085 was submitted by an IRC user (at my > > suggestion) at 2009-09-28 22:12 +, or a bit over 22 hours ago as I write I am a -bugs moderator, and don't see that I ever got a notice that I needed to approve #5085. I did get one for 5804 and 5806, FWIW. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #4920: need case-insensitive searches
On Tue, Jul 14, 2009 at 01:28:30PM +, Michael Gould wrote: > I can see why people use case sensitive searches but it would be nice if > there was either a setup option in the init program or a encoding and locale > that would allow for case insenstive searches without having to use a > non-standard Ilike search. In out database for example, we have no text > fields that need a case sensitive index or search. In 8.4, the citext module provides you a case-insensitive data type. In earlier versions, you might store uppper(text_field) in the database instead of or in addition to the original text_field value. http://www.postgresql.org/docs/current/static/citext.html -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #4916: wish: more statistical functions (median, percentiles etc)
On Sat, Jul 11, 2009 at 02:12:22AM +0100, Richard Neill wrote: > Thanks for your reply. Sadly, I haven't the time (or expertise) to write > this myself. However, the feature would be really useful to have. I'd > certainly be willing to make a £200 payment or donation in return. That's very nice of you to make the offer. Pending someone taking you up on it, you might consider your ability to write the functions in some procedural language. They would probably be easier to write, and you'd only have to make them handle data types you're planning to use them with. For instance, there's an example of PL/Perl versions available embedded in the code here: http://tr.im/rPDA -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] BUG #4916: wish: more statistical functions (median, percentiles etc)
On Fri, Jul 10, 2009 at 11:37:46PM +, Richard Neill wrote: > In addition to the existing aggregate functions (avg, stddev etc), it would > be nice if postgres could return further information. For example, the > quartiles, percentiles, and median. > > [mode would also be useful, as an explicit function, though we can get it > easily enough using count(1) order by count desc]. > > According to google, this has been a wish since at least year 2000 for > various people, but doesn't seem to be implemented. That's because no one has yet taken the time. However, patches are welcome, if you'd like it enough to implement it. It's on my list of things that might be interesting to write, for example, but there are other things higher up on that list. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [BUGS] RPostgreSQL
On Wed, Feb 25, 2009 at 08:11:02PM +0100, David Seres wrote: >Hello! >I encountered a problem trying to install the RPostgreSQL package for R. I >get an error message whenever I try to load the package, namely that it >doesn't find the reference number 108 in the LIBPQ.dll. What does this >problem mean? >Greetings, >David Seres That's something you'll have to take up with whoever developed RPostgreSQL; most likely the version of libpq that your RPostgreSQL binary wants differs from the one on your system. For what it's worth, I've used RDbiPgSQL a fair bit (though never on Windows) and found it quite satisfactory. - Josh / eggyknap signature.asc Description: Digital signature
Re: [BUGS] Behavior of identically-named savepoints
On Tue, Feb 03, 2009 at 11:31:31AM -0700, Joshua Tolley wrote: > Unless, of course, > I'm missing something. Yep, I was missing something. I didn't realize ROLLBACK TO SAVEPOINT didn't destroy the newer savepoint like RELEASE SAVEPOINT does. Adding RELEASE SAVEPOINT calls to my test script makes it work as I'd expect. Sorry for the noise. - Josh / eggyknap signature.asc Description: Digital signature
[BUGS] Behavior of identically-named savepoints
The SAVEPOINT documentation says that a new savepoint created with the same name as an existing savepoint masks but does not destroy the old savepoint, and rolling back to the savepoint will then make the old savepoint available for RELEASE SAVEPOINT and ROLLBACK TO SAVEPOINT calls. 8.3.5 and my 8.4devel (built a few days ago) don't follow this behavior, as demonstrated with the attached script. Unless, of course, I'm missing something. - Josh / eggyknap CREATE TEMPORARY TABLE test (id INTEGER); BEGIN; INSERT INTO test (id) VALUES (1); SAVEPOINT svpt; INSERT INTO test (id) VALUES (2); SAVEPOINT svpt; INSERT INTO test (id) VALUES (3); SAVEPOINT svpt; INSERT INTO test (id) VALUES (4); SAVEPOINT svpt; INSERT INTO test (id) VALUES (5); SELECT * FROM test; SELECT 'Should show values 1..5'; ROLLBACK TO SAVEPOINT svpt; SELECT * FROM test; SELECT 'Should show values 1..4'; ROLLBACK TO SAVEPOINT svpt; SELECT * FROM test; SELECT 'Per docs, should show values 1..3, but it doesn''t'; COMMIT; SELECT * FROM test; SELECT 'Per docs, should show values 1..3, but it doesn''t'; signature.asc Description: Digital signature
Re: [BUGS] BUG #4601: Data saving and opening problem
On Mon, Jan 05, 2009 at 07:25:56AM +, V KUMAR wrote: > we are experiencing the following error intermittenly in saving and opening > the data. > > While saving: > > Database error: Error in saving the FMB MAP(Tippan). An I/O error > occured while sending to the backend. > > > While opening: > > Database error: Error opening FMB Map of 2808060345. An I/O > error occured while sending to the backend. > > > If we delete the record '2808060345', it shows error in another record and > goes on. The database was working perfectly earlier. Does this error come from PostgreSQL, or rather from some application that uses PostgreSQL? I ask because it isn't an error message I'm familiar with (not that I'm an expert :). If it's from another application, we'll need some data directly from PostgreSQL (e.g. logs) to determine 1) whether the problem is really PostgreSQL's fault, and 2) if (1) is true, what to do about it. - Josh / eggyknap signature.asc Description: Digital signature
Re: [BUGS] BUG #4482: Segfault error 4
On Thu, Oct 16, 2008 at 10:33 AM, manish singh <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 4482 > Logged by: manish singh > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3 > Operating system: Centos 64bit > Description:Segfault error 4 > Details: > > Database Postgressql 8.3.3 is on clustering and replication and is patched > by pgcluster 1.9.rc5.patch > now this time this below error getting. > > we are running this setup from last 1 year having no error, this error meet > us this month OCT 2008 > > kernel: postgres[4474]: segfault at 2b21b5f92004 rip 00536e10 > rsp 780ec3c0 error 4 > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > If you're using pgcluster you'd do better reporting this to the pgcluster mailing lists - Josh / eggyknap -- 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] Incorrect "invalid AM/PM string" error from to_timestamp
On Fri, Sep 26, 2008 at 8:11 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Brendan Jurd" <[EMAIL PROTECTED]> writes: >> I have some thoughts on this and other issues surrounding AM/PM, but >> perhaps they are better reserved for a separate thread. Might I >> suggest we apply Alex's bugfix and hold off on the message changes >> pending further discussion? > > Agreed on separating the message issue. What I wanted to know was > whether there are similar bugs elsewhere in to_timestamp, or whether > you're pretty sure this is the only occurrence of the coding pattern? > I've always found it helpful to think "where else did we make this > same mistake" after identifying a bug. > >regards, tom lane > I guess we know this already, but for the sake of trying to appear involved, I've confirmed this fixes the problem as I was seeing it. +1 for the message being a bit more specific, though it's a definite improvement as is. - Josh PS> My apologies for sending this directly to Tom instead of to the list the first time I sent it. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Incorrect "invalid AM/PM string" error from to_timestamp
I'm running this on 8.4devel built from CVS HEAD as of 9:44 AM Moutain
Daylight time today, on a 32-bit Ubuntu 7.04 box. This is a completely
new database.
[EMAIL PROTECTED]:~/devel/raybo$ psql raybo -f test.sql
CREATE TABLE
INSERT 0 1
INSERT 0 1
psql:test.sql:21: ERROR: invalid AM/PM string
psql:test.sql:22: ERROR: invalid AM/PM string
The script in question is below:
CREATE TABLE ft (
id1 numeric(13,0),
am1 numeric(13,2),
am1 numeric(13,2),
ct timestamp without time zone
);
-- -- The commands below come from a dataset I was loading. While
trying to reduce the problem to a small test case, I found that
various combinations of
-- -- the available columns showed the error, and others did not. The
commands below are one set that don't display the error.
-- INSERT INTO ft (am1, am2, ct) VALUES (45749.25, 45749.25,
to_timestamp('21-SEP-08 03.26.04.378954 AM', 'DD-MON-YY HH.MI.SS.US
AM'));
-- INSERT INTO ft (am1, am2, ct) VALUES (60, 60,
to_timestamp('21-SEP-08 08.15.42.950620 PM', 'DD-MON-YY HH.MI.SS.US
AM'));
-- INSERT INTO ft (am1, am2, ct) VALUES (46.17,46.17,
to_timestamp('21-SEP-08 08.15.42.950620 PM', 'DD-MON-YY HH.MI.SS.US
AM'));
-- INSERT INTO ft (am1, am2, ct) VALUES (61.55,61.55,
to_timestamp('21-SEP-08 03.26.04.350738 AM', 'DD-MON-YY HH.MI.SS.US
AM'));
-- -- This set of commands shows the error. Note that running these
statements in a different order, or inserting other commands into the
statements, or other
-- -- such modifications may very well prevent the error from occurring.
INSERT INTO ft (id1, am1, ct) VALUES (6924257, 45749.25,
to_timestamp('21-SEP-08 03.26.04.378954 AM', 'DD-MON-YY HH.MI.SS.US
AM'));
INSERT INTO ft (id1, am1, ct) VALUES (6924611, 60,
to_timestamp('21-SEP-08 08.15.42.950620 PM', 'DD-MON-YY HH.MI.SS.US
AM'));
INSERT INTO ft (id1, am1, ct) VALUES (6924612, 46.17,
to_timestamp('21-SEP-08 08.15.42.950620 PM', 'DD-MON-YY HH.MI.SS.US
AM'));
INSERT INTO ft (id1, am1, ct) VALUES (6924254, 61.55,
to_timestamp('21-SEP-08 03.26.04.350738 AM', 'DD-MON-YY HH.MI.SS.US
AM'));
-- Josh Tolley / eggyknap
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
