On 05/28/2011 02:26 AM, Mathew Samuel wrote:
That system where this was seen was using pgsql-8.2.6 on RHEL4.
Upgrade. A workaround is in newer versions of 8.2 .
--
Craig Ringer
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.po
On Thu, Jun 2, 2011 at 2:52 PM, Andres Freund wrote:
> Wow. I don't think I ever made so many stupid mistakes when doing a two line
> change. I abviously wasn't really awake that evening. As evidenced excessively
> in that thread ;)
I think I once found two bugs in a one-line patch...
--
Robert
The following bug has been logged online:
Bug reference: 6049
Logged by: Dylan Adams
Email address: dad...@bybaxter.com
PostgreSQL version: 8.4.4
Operating system: Linux (Fedora 12)
Description:Can't load dumped view with VALUES and ORDER BY
Details:
If you create a
Robert Haas writes:
> On Fri, May 27, 2011 at 2:26 PM, Mathew Samuel
> wrote:
>> 2011-03-28 10:44:42 UTC3932PANIC: cannot abort transaction 1827110275, it
>> was already committed
>>
>> Not sure if this is a known bug (or if it is a bug at all or something I can
>> address using different confi
On Thursday, June 02, 2011 07:31:33 PM Robert Haas wrote:
> On Wed, Jun 1, 2011 at 1:15 PM, Robert Haas wrote:
> > 2011/5/31 Andres Freund :
> >> On Tuesday, May 31, 2011 03:27:22 Alvaro Herrera wrote:
> >>> Excerpts from Andres Freund's message of lun may 30 20:47:49 -0400 2011:
> >>> > On Tuesda
On Thu, Jun 2, 2011 at 11:21 AM, Artiom Makarov
wrote:
> 2011/6/2 Alexey Klyukin :
>
>> What would you expect to happen for TRUNCATE .. CASCADE?
>>
>> One thing I find potentially surprising is that TRUNCATE CASCADE doesn't
>> follow the semantics of 'ON DELETE' clause for the foreign key, i.e. i
On Wed, Jun 1, 2011 at 1:15 PM, Robert Haas wrote:
> 2011/5/31 Andres Freund :
>> On Tuesday, May 31, 2011 03:27:22 Alvaro Herrera wrote:
>>> Excerpts from Andres Freund's message of lun may 30 20:47:49 -0400 2011:
>>> > On Tuesday, May 31, 2011 02:35:58 AM Andres Freund wrote:
>>> > > On Tuesday,
On Fri, May 27, 2011 at 2:26 PM, Mathew Samuel
wrote:
> I see the following error as found in pg.log:
> UTC4115FATAL: the database system is in recovery mode
>
> Actually that message was logged repeatedly for about 4 hours according to
> the logs (I don't have access to the system itself, just t
On Wed, May 25, 2011 at 7:29 AM, Susanne Ebrecht
wrote:
> I think we should fix the documentation here.
Patch?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your sub
On Jun 2, 2011, at 6:21 PM, Artiom Makarov wrote:
> 2011/6/2 Alexey Klyukin :
>
>> What would you expect to happen for TRUNCATE .. CASCADE?
>>
>> One thing I find potentially surprising is that TRUNCATE CASCADE doesn't
>> follow the semantics of 'ON DELETE' clause for the foreign key, i.e. it
2011/6/2 Alexey Klyukin :
> What would you expect to happen for TRUNCATE .. CASCADE?
>
> One thing I find potentially surprising is that TRUNCATE CASCADE doesn't
> follow the semantics of 'ON DELETE' clause for the foreign key, i.e. it would
> truncate the dependent table even with ON DELETE RES
On 02/06/2011 14:09, Peter Eisentraut wrote:
On ons, 2011-05-11 at 14:58 -0400, Tom Lane wrote:
Marc Cousin writes:
I've been starting to work on a 'what's new in 9.1' like i did last
year, and am faced with what I feel is a bug, while building a demo case
for collation.
Here it is:
SELE
On Jun 2, 2011, at 2:23 PM, Artiom Makarov wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6048
> Logged by: Artiom Makarov
> Email address: artiom.maka...@gmail.com
> PostgreSQL version: 9.04
> Operating system: 2.6.32-30-server #59-Ubuntu SMP Tue M
"" writes:
> 1). although i kown that, "the system will convert **now** to a timestamp as
> soon as the constant is parsed",
> i think this is a bug.
Sorry, it's not a bug, and we're not going to change it.
> but, what about "prepare p1 as select 'today'::timestamp"??
> today() is not a builtin
On ons, 2011-05-11 at 14:58 -0400, Tom Lane wrote:
> Marc Cousin writes:
> > I've been starting to work on a 'what's new in 9.1' like i did last
> > year, and am faced with what I feel is a bug, while building a demo case
> > for collation.
>
> > Here it is:
>
> > SELECT * from (values ('llegar'
The following bug has been logged online:
Bug reference: 6048
Logged by: Artiom Makarov
Email address: artiom.maka...@gmail.com
PostgreSQL version: 9.04
Operating system: 2.6.32-30-server #59-Ubuntu SMP Tue Mar 1 22:46:09 UTC
2011 x86_64 GNU/Linux
Description:TRUNCATE
On 02/06/11 10:53, wcting...@163.com wrote:
> but, what about "prepare p1 as select 'today'::timestamp"??
> today() is not a builtin function, we can't change it to "select
> today()::timestamp";
The keyword-to-timestamp conversions are ugly historical hacks.
Use the SQL-standard current_date, cu
The following bug has been logged online:
Bug reference: 6047
Logged by:
Email address: wcting...@163.com
PostgreSQL version: 9.0.4
Operating system: WinXP 32bit
Description:prepare p1 as select 'now'::timestamp; then "execute p1"
many times, they return the same tim
18 matches
Mail list logo
