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
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
>> 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:
> 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
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
"" 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
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
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
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
> -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
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
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
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
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 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
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
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 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.
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
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 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
-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
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
25 matches
Mail list logo
