get a base backup.
Brian Wipf
<[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to
On 3-Dec-07, at 3:51 PM, A.M. wrote:
On Dec 3, 2007, at 4:16 PM, Brian Wipf wrote:
We have a dual 3.0 GHz Intel Dual-core Xserve, running Mac OS X
10.5.1 Leopard Server and PostgreSQL 8.2.5. When we disconnect
several clients at a time (30+) in production, the CPU goes through
the roof
ce may be when I'm killing pgbench.
I'm not sure if this is a bug with PostgreSQL or OS X 10.5.1. Any
suggestions on what I can do to narrow down the problem further would
be greatly appreciated.
Brian Wipf
ClickSpace Interactive Inc.
<[EMAIL PROTECTED]>
--
d
which can be shut down periodically for taking base backups.
Brian Wipf
<[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 6: explain analyze is your friend
On 29-Oct-07, at 11:06 PM, Tom Lane wrote:
Brian Wipf <[EMAIL PROTECTED]> writes:
The process I use that leads to the warnings is simple:
I use pg_controldata to determine the current checkpoint WAL location
of the standby server. I ensure I have this WAL file and all newer
WALs. I
ortant that this even works. If anyone could shed any
insight though, I would appreciate the feedback.
Brian Wipf
<[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscri
I have a test PG 8.2.5 installation that has been left idle with no
connections to it whatsoever for the last 24 hours plus. WALs are
being archived exactly 5 minutes apart, even though archive_timeout
is set to 60. Is this the expected behavior for a database with no
changes?
Brian
---
On 18-Oct-07, at 3:15 PM, Brian Wipf wrote:
The offset is the last 6 hex digits of the checkpoint location
value. The offset contains leading zeros to make it 6 digits if its
actual value is less than 6 digits. Therefore, the digits between
the slash and the last 6 digits are the log
On 17-Oct-07, at 12:01 AM, Brian Wipf wrote:
I'm working on a script that takes backups in intervals from our
warm PITR stand by server (both servers running PG 8.2.5). The
documentation advises "running pg_controldata on the standby server
to inspect the control file and det
digits after the slash would be the log segment. What is the rule
for determining the log segment from pg_controldata's output?
Thanks for the help!
Brian Wipf
ClickSpace Interactive Inc.
<[EMAIL PROTECTED]>
---(end of broadcast)---
T
difficult to maintain when things go
wrong.
Brian Wipf
ClickSpace Interactive Inc.
<[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PR
doing the requested copy. I
fixed the bug now. Thanks for your input Tom.
Brian Wipf
ClickSpace Interactive Inc.
<[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choo
On 3-Oct-07, at 12:46 PM, Richard Huxton wrote:
Tom Lane wrote:
Brian Wipf <[EMAIL PROTECTED]> writes:
PG tried to enforce the same LC_COLLATE and LC_CTYPE. On OS X,
the value of en_US.utf8 didn't exist, so I created a soft link
to en_US.UTF-8 in the /usr/share/locale/ direct
y-I worked better
for us, but it is more difficult to maintain than PG's PITR and a
warm standby is sufficient for us. It would be nice to be able to use
the read-only warm stand-by PITR at some point as well, although with
the different locale orderings, I suppose this wouldn't be po
play
will not update these indexes. The recommended workaround is to
manually REINDEX each such index after completing a recovery operation"
Is it possible there are issues with btree indexes being maintained
properly as well? Any other ideas?
Brian Wipf
Clickspace Int
ot sure if this should be listed as another caveat on the PITR
recovery page but in the very least I wanted to post to the list so
that others attempting to archive and recover compressed WALs may be
aware of a potential issue.
Brian Wipf
<[EMAIL PROTECTED]>
---
On 16-May-07, at 4:05 PM, PFC wrote:
This makes queries hard to optimize. Consider the table (user_id,
item_id) meaning user selected this item as favourite.
If you want to know which users did select both items 1 and 2, you
have to do a self-join, something like :
SELECT... FROM favourite
ERENCES foo_table' | grep 'Table ' | cut -
d '"' -f 2
should do the trick.
Brian Wipf
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
if it recurs, I'll rebuild the primary
key index. Perhaps the category_product_visible_pkey index was/is
corrupted in some way.
Brian Wipf
<[EMAIL PROTECTED]>
The exact error was:
select process_pending_changes(); FAILED!!! Message: ERROR: duplicate
key violates unique constraint "
On 12-Dec-06, at 4:30 PM, Tom Lane wrote:
"Brendan O'Shea" <[EMAIL PROTECTED]> writes:
We have discovered a situation where the statement_timeout is not =
honored for broken connections. If a connection is in the process
of =
returning results to the client and the connection is severed (for
On 4-Dec-06, at 1:43 AM, Albe Laurenz wrote:
lsof on the client machine (192.168.0.52) shows no connections on
port 49333, so it doesn't appear to be a simple matter of killing the
client connection. If I have to, I can reboot the client machine, but
this seems like overkill and I'm not cer
On 2-Dec-06, at 6:27 AM, Martijn van Oosterhout wrote:
On Fri, Dec 01, 2006 at 08:26:53PM -0700, Brian Wipf wrote:
Now I know the cause at least. If anyone has an idea on how to kill a
similar hung connection without rebooting the server, I would
appreciate any suggestions.
I'm unsure
on without rebooting the server, I would
appreciate any suggestions.
Thanks,
Brian Wipf
<[EMAIL PROTECTED]>
On 1-Dec-06, at 6:30 PM, Brian Wipf wrote:
Based on the backend_start time in pg_stat_activity, I was able to
find the problem query in our logs. The query is a simple one, but
error
occurred, but the server still shows the hung non-sigint-able
connection.
On 1-Dec-06, at 5:54 PM, Brian Wipf wrote:
Sorry, I forgot to mention this is on PostgreSQL 8.1.5. The server
is SUSE Linux 10.1, the client is OS X Server 10.4.8.
On 1-Dec-06, at 5:42 PM, Brian Wipf wrote:
I
Sorry, I forgot to mention this is on PostgreSQL 8.1.5. The server is
SUSE Linux 10.1, the client is OS X Server 10.4.8.
On 1-Dec-06, at 5:42 PM, Brian Wipf wrote:
I have a connection that I am unable to kill with a sigint.
ps auxww for the process in question:
postgres 3578 0.3 3.6
ooting the client?
Brian Wipf
<[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to
26 matches
Mail list logo
