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
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
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
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
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
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
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
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 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 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 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
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 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
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 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 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 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 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
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
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
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
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
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
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
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
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 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
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
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 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 `
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
>
31 matches
Mail list logo
