[BUGS] Help needed in Solving the problem in pg_restore

Respected sir, I am new Postgres Sql and I am using this database with Java Technology. I am executing the below statements in command prompt and they are executing fine but when I am executing it through my java program it is also working fine but it is not coming. It is continuously execu

Re: [BUGS] setseed accepts bad seeds

Kris Jurka <[EMAIL PROTECTED]> writes: > On Mon, 10 Mar 2008, Tom Lane wrote: >> I'd be inclined to leave the mapping alone and just insert a warning >> (or hard error) for inputs outside the range -1 to 1. > Here's a patch that errors out for out of range values. Applied, thanks.

[BUGS] BUG #4022: DST Time Zone Bug related to: select now() at time zone 'EST'

The following bug has been logged online: Bug reference: 4022 Logged by: Username_PalmTreesNSand Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Windows Vista Description:DST Time Zone Bug related to: select now() at time zone 'EST' Detail

Re: [BUGS] [PATCH] Don't bail with legitimate -N/-B options

FYI, the restriction that -B must be larger than -N will be removed in 8.4. --- Andreas Kling wrote: > Greetings, > > Starting PostgreSQL 8.3.0 with the default options used by Gentoo Linux > (-N 40 -B 80) causes it to bai

Re: [BUGS] BUG #4022: DST Time Zone Bug related to: select now() at time zone 'EST'

"Username_PalmTreesNSand" <[EMAIL PROTECTED]> writes: > I have recently noticed a problem since the Daylight savings time change > (past 1-2 days). > The following query returns the time from an hour ago (I'm in EST, but I > need to be able to handle other time zones): > select now() at time

Re: [BUGS] BUG #4020: RFE: have way to log autovacuum activity

Joseph S wrote: > Alvaro Herrera wrote: > >> Yeah, we have a configurable autovacuum log on 8.3. >> > Sorry, I looked but didn't see it. #log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and # their durations, > 0 logs only # actions runn

Re: [BUGS] BUG #4020: RFE: have way to log autovacuum activity

Alvaro Herrera wrote: Yeah, we have a configurable autovacuum log on 8.3. Sorry, I looked but didn't see 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] Rulese Bug: Instead of reporting incorrect insert count.

According to the documentation at Rules and Command Status when creating rules, the resulting command status from the rules executed is dependent upon the rules that were added. According to the documentation: "If there is any uncond

Re: [BUGS] Rulese Bug: Instead of reporting incorrect insert count.

"Shawn Chasse" <[EMAIL PROTECTED]> writes: > According to the documentation: > "If there is any unconditional INSTEAD rule for the query, then the > original query will not be executed at all. In this case, the server > will return the command status for the last query that was inserted by > an I

[BUGS] BUG #4023: The transaction control does not work for sequences

The following bug has been logged online: Bug reference: 4023 Logged by: Giovani Murilo Dantas Correa Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.0 and 8.1.9 Operating system: Linux 2.6.X (Slackware and Fedora) Description:The transaction control does not

Re: [BUGS] BUG #4023: The transaction control does not work for sequences

"Giovani Murilo Dantas Correa" <[EMAIL PROTECTED]> writes: > Description:The transaction control does not work for sequences This is not a bug. It is an intentional and very clearly documented behavior. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsq

Re: [BUGS] LISTEN/NOTIFY race condition?

Hello, I've figured out the LISTEN / NOTIFY race condition I had previously encountered. It is not trivial, so I'll try to give as much details as possible to describe what is going on. Here is a description of the two Postgres functions involved in the race condition: void CommitTransaction()

Re: [BUGS] LISTEN/NOTIFY race condition?

Laurent Birtz <[EMAIL PROTECTED]> writes: > The command backend begins a transaction, then the event backend begins a > transaction for LISTEN. The event backend updates the pg_listener table > in mutual exclusion, but it releases the mutex before the transaction is > commited. The command thread d

Re: [BUGS] LISTEN/NOTIFY race condition?

In Async_Listen(): change 'heap_close(lRel, ExclusiveLock);' for 'heap_close(lRel, NoLock);'. This solution is pretty ugly, though, because we allow people to execute LISTEN/UNLISTEN in transaction blocks, which means that the ExclusiveLock could be held for quite some time. Not on

[BUGS] BUG #4024: xpath() results lose namespace mappings

The following bug has been logged online: Bug reference: 4024 Logged by: Matt Magoffin Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.0 Operating system: OS X 10.5, Windows XP Description:xpath() results lose namespace mappings Details: I was trying to ext