Hi Valentine,
On Tuesday, May 22, 2012 11:36:23 PM val...@gmail.com wrote:
> 2012-05-22 21:20:27.868 CEST,,,23804,,4fbbe69e.5cfc,129,,2012-05-22
> 21:18:54 CEST,1/0,0,LOG,0,"4 KnownAssignedXids (num=4 tail=0 head=916)
> [0]=3674726497 [1]=3674727041 [2]=3674727042 [3]=3674727128 ","xlog
>
On 22 May 2012 18:49, Craig Ringer wrote:
> When you shut down the 9.1.3 cluster did you make absolutely certain there
> were no postgres.exe processes lurking around when you tested? Given the
> incredible thouroughness of your report I imagine you did, but it's worth
> checking, as a lingering `
2012/5/22 Robert Haas :
> On Tue, May 22, 2012 at 3:55 PM, Tom Lane wrote:
>> Robert Haas writes:
deik3qfhu265n6=> with hello as (select 'hello' as name)
deik3qfhu265n6-> , bye as (select 'bye' as name)
deik3qfhu265n6-> select * from hello UNION ALL select * from bye;
ERROR:
On Wed, May 23, 2012 at 12:14 PM, Tom Lane wrote:
> Maxim Boguk writes:
> > if anytextcat() and textanycat() are marked volatile,
> > why the database allows create index on supposedly to be volatile
> > expression:
> > create index test_val_special on test((val || ''));
>
> CREATE INDEX inlines
Maxim Boguk writes:
> if anytextcat() and textanycat() are marked volatile,
> why the database allows create index on supposedly to be volatile
> expression:
> create index test_val_special on test((val || ''));
CREATE INDEX inlines anytextcat (which is just a SQL function) before
making the vola
Hi,
Thank you very much for answer.
Explicit casting resolved an issue.
Just single question:
if anytextcat() and textanycat() are marked volatile,
why the database allows create index on supposedly to be volatile
expression:
create index test_val_special on test((val || ''));
?
P
On Wed, May 2
maxim.bo...@gmail.com writes:
> I managed create simple self-contained test case for 6658.
This works fine in HEAD. The reason it doesn't work fine in 9.1 (or
9.0) is that in those branches, anytextcat() and textanycat() are marked
volatile, for reasons that were good at the time but were superse
The following bug has been logged on the website:
Bug reference: 6662
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.1.3
Operating system: Linux
Description:
I managed create simple self-contained test case for 6658.
create table
Oh, that is not good, I am getting the same error after rebuilding
hot-standby from master.
2012-05-23 02:08:36.960 CEST,,,21080,,4fbc2a84.5258,1,,2012-05-23 02:08:36
CEST,,0,LOG,0,"database system was interrupted while in recovery at log
time 2012-05-22 21:33:49 CEST",,"If this has occurred
Merlin Moncure writes:
> On Tue, May 22, 2012 at 4:08 PM, Tom Lane wrote:
>> heapgetpage() seems like the most reasonable place to me, as there we'll
>> only be making the check once per page not once per tuple.
> ok. this fixes the issue:
Well, actually it needs to be a bit earlier than that o
On Tue, May 22, 2012 at 4:08 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Basically, $subject says it all. It's pretty easy to reproduce:
>> delete all the records from a large table and execute any sequentially
>> scanning query before autocvacuum comes around and cleans the table
>> up; the
The following bug has been logged on the website:
Bug reference: 6661
Logged by: Valentine Gogichashvili
Email address: val...@gmail.com
PostgreSQL version: 9.0.7
Operating system: Linux version 2.6.32-5-amd64 (Debian 2.6.32-41sque
Description:
Hello,
today when tryi
Merlin Moncure writes:
> Basically, $subject says it all. It's pretty easy to reproduce:
> delete all the records from a large table and execute any sequentially
> scanning query before autocvacuum comes around and cleans the table
> up; the query will be uncancellable. This can result in fairly
On Mon, May 21, 2012 at 6:45 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6653
> Logged by: Sebastian K.
> Email address: axw...@ipa.fhg.de
> PostgreSQL version: 9.0.7
> Operating system: Windows 7 i386
> Description:
>
> I want to set up
On Sun, May 20, 2012 at 1:53 PM, Paragon Corporation wrote:
> Okay understood. We had planned to do something along this line of having a
> where condition for the extension or putting the custom spatial_ref_sys in a
> separate table but hand't decided which way to go. So that will take care of
>
On Fri, May 18, 2012 at 5:09 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6650
> Logged by: Andrzej Krawiec
> Email address: a.kraw...@focustelecom.pl
> PostgreSQL version: 8.4.11
> Operating system: CentOS 6.0 - 2.6.32-220.13.1.el6.x86_64
On Thu, May 17, 2012 at 5:43 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6647
> Logged by: Subramanian
> Email address: subu@gmail.com
> PostgreSQL version: 9.1.3
> Operating system: Windows XP
> Description:
>
> Hello there. We in ou
On Thu, May 17, 2012 at 7:07 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6648
> Logged by: wp
> Email address: erhami...@o2.pl
> PostgreSQL version: 9.1.3
> Operating system: Windows 7 Professional (Fujitsu)
> Description:
>
> What a mess
On Tue, May 22, 2012 at 3:55 PM, Tom Lane wrote:
> Robert Haas writes:
>>> deik3qfhu265n6=> with hello as (select 'hello' as name)
>>> deik3qfhu265n6-> , bye as (select 'bye' as name)
>>> deik3qfhu265n6-> select * from hello UNION ALL select * from bye;
>>> ERROR: failed to find conversion funct
Robert Haas writes:
>> deik3qfhu265n6=> with hello as (select 'hello' as name)
>> deik3qfhu265n6-> , bye as (select 'bye' as name)
>> deik3qfhu265n6-> select * from hello UNION ALL select * from bye;
>> ERROR: failed to find conversion function from unknown to text
> I think it should return a c
On Sun, May 13, 2012 at 10:46 PM, Thangalin wrote:
> Hi,
>
> REPLICATE
>
> 0. Create a new database (superdatabase)
> 1. Create a new schema (superschema)
> 2. Add the unaccent extension to the schema:
> CREATE EXTENSION unaccent;
> 3. Create a wrapper for unaccent that exposes an IMMUTABLE interf
On Tue, May 22, 2012 at 3:46 PM, Robert Haas wrote:
> On Mon, May 14, 2012 at 11:08 AM, wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 6637
>> Logged by: David Chuet
>> Email address: dch...@odotech.com
>> PostgreSQL version: 9.0.7
>> Operatin
On Mon, May 14, 2012 at 11:08 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6637
> Logged by: David Chuet
> Email address: dch...@odotech.com
> PostgreSQL version: 9.0.7
> Operating system: Windows 7 x64
> Description:
>
> Using Postgresql
On Thu, May 3, 2012 at 9:01 PM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6626
> Logged by: Will Leinweber
> Email address: w...@heroku.com
> PostgreSQL version: 9.1.3
> Operating system: ubuntu 10.04
> Description:
>
> This was surprising
On Thu, May 3, 2012 at 6:46 PM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6625
> Logged by: Milen
> Email address: milen_laza...@yahoo.com
> PostgreSQL version: 8.3.0
> Operating system: windows xp
> Description:
>
> i can't complete the in
Basically, $subject says it all. It's pretty easy to reproduce:
delete all the records from a large table and execute any sequentially
scanning query before autocvacuum comes around and cleans the table
up; the query will be uncancellable. This can result in fairly
pathological behavior in i/o co
Chaitany Kulkarni writes:
> I didn't understand when user have defined schema names explicitly in
> definition of the objects and most database developers insist on writing
> schema names explicitly, why pg_dump is not outputting it as it is.
The short answer to that is that the internal represe
Thanks for your reply.
I know that pg_dump is not intended to provide SQL script to be working in
many other DBMS. But even if I have to dump all functions/views (tables and
other objects are not changed a lot like functions/views due to changes in
business rules or behaviour) from a certain schema
shreeseva...@gmail.com writes:
> Many times I have to dump all objects from a schema (single schema holding
> only functions and views) in plain text format. It is found that pg_dump
> includes a set search_path statement at the beginning and drops all
> occurrences of the schema name (to which dum
The following bug has been logged on the website:
Bug reference: 6659
Logged by: Junho Kim
Email address: junho1@lge.com
PostgreSQL version: 9.0.4
Operating system: Windows XP 32bit ServicePack 3
Description:
I run postgresql-9.0.4-1-windows.exe.
But package occur
The following bug has been logged on the website:
Bug reference: 6660
Logged by: C P Kulkarni
Email address: shreeseva...@gmail.com
PostgreSQL version: 9.1.3
Operating system: Fedora 16
Description:
Many times I have to dump all objects from a schema (single schema ho
31 matches
Mail list logo