Hi Team,
I am doing postgresql 9.1 replication , the Master database is on GNU/Linux
operation system , the Slave database is on Windows 32 bit system. But when I
copy the Master database from Linux to Windows , then I am unlucky to bringup
database on windows system.
Could you please let me
On Mon, Mar 12, 2012 at 5:31 AM, Nie, Guocong wrote:
> Hi Team,
>
> I am doing postgresql 9.1 replication , the Master database is on GNU/Linux
> operation system , the Slave database is on Windows 32 bit system. But
> when I copy the Master database from Linux to Windows , then I am unlucky to
Christopher Browne wrote:
> Nie, Guocong wrote:
>> Could you please let me know how can I replicate database from
>> Linux to Windows ?
>
> The built-in replication requires that you are using the same
> version of PostgreSQL on the same OS platform. That doesn't seem
> to be documented as cl
On Mon, Mar 5, 2012 at 6:52 AM, wrote:
> I found some unexpected behaviour when changing the schema search path in
> combination with plpgsql functions (may be true for other function types
> too, did not check). This occurs both in 9.1.2 (on Fedora, 64 bit) and 8.4.9
> (Centos 6, 32 bit). I crea
On Sun, Mar 4, 2012 at 11:22 PM, wrote:
> I got hit by that bug when explored reasons of one very slow production
> query again.
> And I lost a lot time trying reproduce the problem query on production
> server with explain analyze.
> Finally I found I need some workaround to get explain perform
Robert Haas writes:
> On Mon, Mar 5, 2012 at 6:52 AM, wrote:
>> I found some unexpected behaviour when changing the schema search path in
>> combination with plpgsql functions (may be true for other function types
>> too, did not check). This occurs both in 9.1.2 (on Fedora, 64 bit) and 8.4.9
>>
Robert Haas writes:
> ... I think that if there's an actual bug here, it's that
> EXPLAIN ANALYZE is skipping the formation of the actual output tuples,
> and therefore it's doing less work than an actual execution of the
> real query would. I am not sure whether it would be a good idea to
> chan
On Mon, Mar 12, 2012 at 11:16 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 5, 2012 at 6:52 AM, wrote:
>>> I found some unexpected behaviour when changing the schema search path in
>>> combination with plpgsql functions (may be true for other function types
>>> too, did not check). T
On Wed, Feb 22, 2012 at 6:04 PM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6484
> Logged by: Charlie Neo
> Email address: c...@accessdata.com
> PostgreSQL version: 9.0.6
> Operating system: Windows Server 2008 R2 Enterprise
> Description:
>
On Mon, Mar 5, 2012 at 11:44 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6520
> Logged by: André Luis Kuhn
> Email address: andrre1...@msn.com
> PostgreSQL version: 8.3.3
> Operating system: Windows XP
> Description:
>
> Após ter dado pro
On Sat, Mar 3, 2012 at 7:47 PM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6512
> Logged by: Stefano Baccianella
> Email address: stefano.bacciane...@gmail.com
> PostgreSQL version: 9.1.1
> Operating system: Windows 7 64bit
> Description:
>
On Mon, Mar 5, 2012 at 6:52 AM, wrote:
>
> set search_path to public;
>
> CREATE FUNCTION countusers()
> RETURNS INT
> AS $PROC$
> BEGIN
> RETURN count(*) FROM users;
> END
> $PROC$ LANGUAGE 'plpgsql' VOLATILE;
>
i think you can workaround your problem using EXECUTE:
CREATE FUNCTION countuse
On Mon, Mar 12, 2012 at 17:23, Tom Lane wrote:
> EXPLAIN ANALYZE *necessarily* does less work than the real query,
> because it doesn't transmit the results to the client (which is going
> to be a dominant cost in a lot of situations). I'm not sure whether
> running the I/O functions would provid
On Sun, 2012-03-11 at 11:20 -0700, Jeff Davis wrote:
> The problem seems to be in check_locale(), which just checks for a
> non-NULL return value from setlocale(). However, the manual for
> setlocale() says:
>
> If locale is "", each part of the locale that should be modified
> is set accordin
Tom Lane writes:
> Ah, nevermind --- I re-read the patch and realized that it was already
> doing exactly what I said. Committed, sorry for the noise.
Great, thank you, Tom!
--
Sergey Burladyan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscript
15 matches
Mail list logo
