Hi,
Configured postgres 9 streaming replication and changed parameter in
postgresql.conf & pg_hba.conf file
Problem is wal sender & receiver process not started , is there any way to
check process please suggest.
172.21.132.1 ( primary )
172.18.221.211 ( standby )
pg_hba.conf (primary & st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Khadtare, Sharad wrote:
> Hi,
>
> Configured postgres 9 streaming replication and changed parameter in
> postgresql.conf & pg_hba.conf file
>
> Problem is wal sender & receiver process not started , is there any way
> to check process please sugges
On Tue, Jan 25, 2011 at 5:01 PM, Khadtare, Sharad
wrote:
> Configured postgres 9 streaming replication and changed parameter in
> postgresql.conf & pg_hba.conf file
>
> Problem is wal sender & receiver process not started , is there any way to
> check process please suggest.
What log messages did
El 25/01/2011 2:18, Vijayakumar escribió:
The following bug has been logged online:
Bug reference: 5847
Logged by: Vijayakumar
Email address: mails4vijayaku...@gmail.com
PostgreSQL version: 8.2
Operating system: windows
Description:pg_restore: [archiver (db)] COPY fa
On Tue, Jan 25, 2011 at 8:59 PM, Khadtare, Sharad
wrote:
> Pls find below logfile of standby and recovery.conf in standby data directory.
>
> bash-3.2$ cat logfile
> LOG: database system was interrupted while in recovery at log time
> 2011-01-25 05:28:35 EST
> HINT: If this has occurred more th
Hi Tushar,
Thx for immediate response.
I verified with ps commmand and there is no process running on host.
Regards,
Sharad K
-Original Message-
From: tushar [mailto:tushar.ah...@enterprisedb.com]
Sent: Tuesday, January 25, 2011 3:36 PM
To: Khadtare, Sharad
Cc: pgsql-bugs@postgresql.
Hi,
Pls find below logfile of standby and recovery.conf in standby data directory.
bash-3.2$ cat logfile
LOG: database system was interrupted while in recovery at log time 2011-01-25
05:28:35 EST
HINT: If this has occurred more than once some data might be corrupted and you
might need to choo
Hi,
Problem solved after removing trigger entry from recovery.conf file
Thx for help
Regards,
Sharad K
-Original Message-
From: Fujii Masao [mailto:masao.fu...@gmail.com]
Sent: Tuesday, January 25, 2011 5:55 PM
To: Khadtare, Sharad
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] pos
On Mon, Jan 24, 2011 at 1:47 PM, Kevin Grittner
wrote:
> "Murray S. Kucherawy" wrote:
>> From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
>
>>> What do you think would make this more clear?
>
>> So maybe something like this after the paragraph you cited would
>> help:
>>
>> "Note that af
Robert Haas wrote:
> I think this patch would only be adding to the confusion. When
> PQgetResult() is called, we read enough data from the connection
> to create and return one result object. It's true that this
> doesn't necessarily detect an EOF, but IIUC calling PQgetResult()
> again is ju
On Tue, Jan 25, 2011 at 10:54 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> I think this patch would only be adding to the confusion. When
>> PQgetResult() is called, we read enough data from the connection
>> to create and return one result object. It's true that this
>> doesn't necessaril
Note: I have this running now on a test box. If someone responds in the
next couple hours, I can run whatever diagnostics you want on it.
Otherwise I'll kill it off and start over with debug logging turned on.
Version: 9.0.1
Platform: Solaris 10u8 / ZFS over DAS 7-drive array
Severity: Serious
Re
Excerpts from Kasia Tuszynska's message of lun ene 24 16:48:21 -0300 2011:
> Basic issue:
> In the documentation Postgres states that it's identifiers (table, column
> names etc)are case insensitive and thus it stores everything in lower case.
> To preserve case of a identifier, the name needs to
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Tuesday, January 25, 2011 7:33 AM
> To: Kevin Grittner
> Cc: Murray S. Kucherawy; Tom Lane; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>
> I think the
The following bug has been logged online:
Bug reference: 5848
Logged by:
Email address: c...@net2business.com
PostgreSQL version: 8.1.22
Operating system: Centos 5.5
Description:Between operator issue
Details:
Statement 'A between B and C' always false if B is grea
Josh Berkus writes:
> Note: I have this running now on a test box. If someone responds in the
> next couple hours, I can run whatever diagnostics you want on it.
> Otherwise I'll kill it off and start over with debug logging turned on.
trace_sort would be interesting.
re
c...@net2business.com wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5848
> Logged by:
> Email address: c...@net2business.com
> PostgreSQL version: 8.1.22
> Operating system: Centos 5.5
> Description:Between operator issue
> Details:
>
> St
"" wrote:
> Statement 'A between B and C' always false if B is greater than C,
> even if A falls between them.
I'm pretty sure that's required by the standard, and doing otherwise
could break code which counts on standard semantics.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
On 1/25/11 1:21 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Note: I have this running now on a test box. If someone responds in the
>> next couple hours, I can run whatever diagnostics you want on it.
>> Otherwise I'll kill it off and start over with debug logging turned on.
>
> trace_sort woul
> trace_sort would be interesting.
This is it so far:
LOG: begin index sort: unique = f, workMem = 1048576, randomAccess = f
STATEMENT: create index "write_log_accounttime_idx" on write_log
(account_id, event_time);
LOG: switching to external sort with 3745 tapes: CPU 9.06s/6.65u sec
elapsed
On 1/25/11 1:21 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Note: I have this running now on a test box. If someone responds in the
>> next couple hours, I can run whatever diagnostics you want on it.
>> Otherwise I'll kill it off and start over with debug logging turned on.
>
> trace_sort woul
Josh Berkus writes:
> LOG: finished writing run 1 to tape 0: CPU 33.39s/149.02u sec elapsed
> 190.11 sec
> LOG: finished writing run 2 to tape 1: CPU 62.72s/371.06u sec elapsed
> 443.16 sec
> LOG: finished writing run 3 to tape 2: CPU 91.04s/599.43u sec elapsed
> 701.37 sec
> LOG: finished
>> If it's going to take 3 minutes each to write each of 3745 tapes, that
>> means completing in around 9 days.
>
> Your logic has nothing to do with what is actually happening. Could we
> have a little bit more patience to see what happens next?
OK, I'll let it run overnight and give you the t
Josh Berkus writes:
> OK, either tape sort is broken or trace_sort is. The larger my
> maint_work_mem, the MORE tapes it wants to use:
Yeah, that's right. More tapes = better, or at least that was the
conclusion we came to some years ago. It doesn't necessarily use all
those tapes --- it's hop
Josh Berkus writes:
> Well, for the straight test on event_time, the rows in the table should
> have been more-or-less physically already in order. This table is
> most-insert, and event_time mostly corresponds to current server time.
That would result in a very long initial run (probably all or
25 matches
Mail list logo
