Please try to change you cuttent working directory to a place you have
Write-Access before pg_upgrade
As in cd \temp or cd %Home%
Harald
Am 12.10.2010 um 01:09 schrieb Chris English :
> In my attempts I changed all pg_hba.conf (8.4 & 9.0) to trusted, turned off
> firewall,
> followed instruc
On Mon, Oct 11, 2010 at 7:09 PM, Chris English wrote:
> In my attempts I changed all pg_hba.conf (8.4 & 9.0) to trusted, turned off
> firewall,
> followed instructions to shut down db(s) and ran cmd.exe as postgres:
>
> C:\WINDOWS\system32>pg_upgrade.exe -p 5432 -P 5433 -d "c:/program
> files/post
"Andreas Karlsson" writes:
> I was looking at the code to see how one would improve indexing of the inet
> types and saw an inconsistency between the compressed format
> (gbt_inet_compress) and how network_cmp_internal works. The btree_gist
> module ignores the netmask.
Well, actually the btree_g
> Date: Mon, 11 Oct 2010 16:15:52 -0700> From: pie...@hogranch.com> To:
> sgl...@hotmail.com> CC: pgsql-bugs@postgresql.org> Subject: Re: [BUGS]
> pg_dumpall -> by hand without --binary-upgrade or BUG #5690: pg_upgrade
> fails> > On 10/11/10 4:09 PM, Chris English wrote:> >> >
> C:\WINDOWS\sys
On 10/11/10 4:09 PM, Chris English wrote:
C:\WINDOWS\system32>pg_dumpall.exe --port 5433 username--"postgres"
--schema-onl
y >"c:/windows/system32/pg_upgrade_dump_all.sql"
Access is denied.
why are you writing the .sql output to the windows system32 directory?!?!?
thats a TERRIBLE place t
In my attempts I changed all pg_hba.conf (8.4 & 9.0) to trusted, turned off
firewall,followed instructions to shut down db(s) and ran cmd.exe as postgres:
C:\WINDOWS\system32>pg_upgrade.exe -p 5432 -P 5433 -d "c:/program
files/postgresql/8.4/data" -D "c:/program files/postgresql/9.0/data" -b
"
I wrote:
> Hmm ... that seems to be a GIN index message ... and a bit of looking at
> the GIN code says that its xlog replay logic is many bricks shy of a
> load. I think SR is exposing a pre-existing problem here.
Actually, it's been broken since 8.2 :-(. I've applied a patch.
The following bug has been logged online:
Bug reference: 5705
Logged by: Andreas Karlsson
Email address: andr...@proxel.se
PostgreSQL version: 9.1
Operating system: Linux
Description:btree_gist: Index on inet changes query result
Details:
Hi,
I was looking at the c
The following bug has been logged online:
Bug reference: 5704
Logged by: Igor
Email address: o...@ukr.net
PostgreSQL version: 8.1
Operating system: CentOs 5
Description:not correct restrictions plperlu
Details:
rights of functions on plperlu
lower than the user pos
[Please keep the mailing list CC'd]
On Mon, Oct 11, 2010 at 8:40 PM, wrote:
>
>> On Mon, Oct 11, 2010 at 2:23 AM, Craig Ringer
>> wrote:
>> > On 10/08/2010 07:53 PM, Johannes Meidert wrote:
>> >>
>> >> The following bug has been logged online:
>> >>
>> >> Bug reference: 5699
>> >> Logged b
"Evgeniy" writes:
> Standby server dies after some minutes with FATAL message:
> 2010-10-11 19:12:17.129 MSD [13864/0]: [5-1] user=,db= LOG: consistent
> recovery state reached at E/A5DCD3A8
> 2010-10-11 19:12:17.139 MSD [13864/0]: [6-1] user=,db= FATAL: bad buffer
> id: 0
> 2010-10-11 19:12:17
The following bug has been logged online:
Bug reference: 5703
Logged by: Evgeniy
Email address: efr...@efreet.ru
PostgreSQL version: 9.0.1
Operating system: linux
Description:Streaming replication: FATAL: bad buffer id: 0
Details:
SR doesn't work for me:
Standby s
On 11.10.2010 04:25, Tom Lane wrote:
It's true for scalar input datatypes, though.
I had been wary of this idea because I didn't see any suitably cheap
place to insert the necessary processing, but after some reflection
and rejiggering of eval_const_expression's responsibilities, it's
done.
On Mon, Sep 27, 2010 at 4:34 AM, Itagaki Takahiro
wrote:
> On Mon, Sep 27, 2010 at 2:36 PM, Alexey Bashtanov
> wrote:
>> hstore: null value is treated as empty string by avals function
>>
>> # select avals('gfds'=>null) = array[null], avals('gfds'=>null) =
>> array[''], version();
>> ?column? |
> 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
On Mon, Oct 11, 2010 at 2:23 AM, Craig Ringer
wrote:
> On 10/08/2010 07:53 PM, Johannes Meidert wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 5699
>> Logged by: Johannes Meidert
>> Email address: johannes.meid...@rohde-schwarz.com
>> PostgreSQL vers
16 matches
Mail list logo
