On Wednesday 23 May 2007 1:04 pm, George Pavlov wrote:
> Hoping to resurrect this thread. I am seeing more and more of
> this as the database gets more usage and it really messes up
> query log analysis.
>
>
> A quick summary: When I posted this was getting corrupted
> query log entries. I still am
On Friday 01 June 2007 3:09 pm, George Pavlov wrote:
> On 5/29/2007 10:19 AM, Ed L. wrote:
> > On Wednesday 23 May 2007 1:04 pm, George Pavlov wrote:
> > FWIW, I've also been seeing this sort of query log
> > corruption for as long as I can remember, 7.1 through 8.2,
>
On Friday 01 June 2007 3:36 pm, Tom Lane wrote:
> "George Pavlov" <[EMAIL PROTECTED]> writes:
> > On 5/29/2007 10:19 AM, Ed L. wrote:
> >> FWIW, I've also been seeing this sort of query log
> >> corruption for as long as I can remember, 7.1 throu
On Friday 01 June 2007 3:36 pm, Tom Lane wrote:
> What *exactly* is the logging setup you guys use, and have you
> tried alternatives?
redirect_stderr = on# Enable capturing of stderr into log
log_directory = '/users/.../logs' # Directory where log files are
written
On Friday 08 June 2007 10:30 am, George Pavlov wrote:
>
> It is very hard to tease these apart because now that I look
> at it closely it is a total mess; there are multiple
> interruptions and interruptions inside of interruptions...
> The interruption can happen anywhere, including the leading
>
We're seeing some unexpected behavior in one particular 64-bit
Pgsql 8.1.2 running on HP-UX 11.23 and Itanium 2, built
with --enable-thread-safety. We think we are seeing concurrent
select-for-updates of the same rows by multiple concurrent
backends, contrary to our understanding of select-fo
I ran a simple select-for-update test on 8.1.2 and was curious as
to why the semantics are what they are. Specifically, when you
have multiple select-for-update-limit queries on the same rows,
why are rows selected by the blocked query before knowing if
some of those rows will be removed/elimi
On Monday 06 August 2007 1:22 pm, you wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > We're seeing some unexpected behavior in one particular
> > 64-bit Pgsql 8.1.2 running on HP-UX 11.23 and Itanium 2,
> > built with --enable-thread-safety. We thi
On Monday 06 August 2007 2:11 pm, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > On Monday 06 August 2007 1:22 pm, you wrote:
> >> You really ought to be using something newer than 8.1.2.
> >
> > Perhaps. But we have yet to find a way
What are the concerns with using oid as the column for a primary
key declaration for use in trigger-based replication?
TIA,
Ed
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
I'm preparing a fairly large 7.4.6 DB for trigger-based
replication. I'm looking for ways to minimize my impact on the
existing schema & data and uptime. This replication solution
requires every table to have a primary key. Rather than adding
a new key column and index for the pkey, it's ap
On Tuesday 21 August 2007 1:22 pm, Robin Helgelin wrote:
>
> Yes, this is where I'm too new to postgresql, how do I tell
> the database which user is logged in to the webapp? A session
> parameter? There will be connection pooling, but if I know how
> to solve the previous question I don't think it
On Tuesday 21 August 2007 1:42 pm, Ed L. wrote:
> Then you could
> store the user ID in an update_session_id column and tablelog
> would help track of the history.
s/user ID/session ID/g;
Ed
---(end of broadcast)---
TIP 6: explain analyz
On Tuesday 21 August 2007 1:45 pm, Scott Marlowe wrote:
> If you have a large db in 7.4.6, you should do two things.
>
> 1: Update to 7.4.19 or whatever the latest flavor of 7.4 is,
> right now. There are a few known data eating bugs in 7.4.6.
Sounds like good advice from a strictly technical vie
On Tuesday 21 August 2007 11:40 pm, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > Are there
> > are any known or obvious gotchas associated with
> > transforming a unique index on a non null column into a
> > primary key via this sql?
> &
I have a question about view management...
I often have need for views that reference views that reference
views, and so on. When I need to make a small update to one of
the views, I am faced with having to drop and recreate all
dependent views even if the driving change just adds another
co
On Friday 16 November 2007 1:57 pm, Ed L. wrote:
> I have a question about view management...
>
> I often have need for views that reference views that
> reference views, and so on. When I need to make a small
> update to one of the views, I am faced with having to drop and
On Friday 16 November 2007 2:09 pm, Merlin Moncure wrote:
> you have to rig a build system. if you have a lot of views
> (which is good), and keeping them up to date is a pain, you
> have to automate their creation. simplest way to do that is to
> rig a build system around sql scripts. when you c
On Friday 16 November 2007 2:48 pm, Scott Marlowe wrote:
> On Nov 16, 2007 3:43 PM, Ed L. <[EMAIL PROTECTED]> wrote:
> > That looks about as ugly as can be. Ugh. What it appears
> > to boil down to is that views become unusable unless you are
> > willing to invest th
Thanks, Justin.
On Friday 16 November 2007 4:38 pm, Justin Pasher wrote:
> We have a system that has quite a few views to access some of
> the data (although we purposely tried to avoid views that
> pulled from other view due to some performance issues), but
> when we had all of the view interdepe
We need some advice on how to handle some large table autovacuum
issues. One of our 8.1.2 autovacuums is launching a DB-wide
vacuum on our 270GB database to prevent xid wrap-around, but is
getting hung-up and/or bogged down for hours on a 40gb table and
taking the server performance down with
On Friday 04 January 2008 6:21 pm, Scott Marlowe wrote:
>
> Have you tried adjusting the
>
> #vacuum_cost_delay = 0 # 0-1000 milliseconds
> #vacuum_cost_page_hit = 1 # 0-1 credits
> #vacuum_cost_page_miss = 10 # 0-1 credits
> #vacuum_cost_page_dirt
On Friday 04 January 2008 6:21 pm, Scott Marlowe wrote:
> On Jan 4, 2008 6:38 PM, Ed L. <[EMAIL PROTECTED]> wrote:
> > We need some advice on how to handle some large table
> > autovacuum issues. One of our 8.1.2
>
> First of all, update your 8.1 install to 8.1.10. Fa
I've been looking at unique indices in a PostgreSQL 8.3.x cluster. Some
unique indices clearly have a corresponding row in pg_constraint, while
other unique indices appear to have no corresponding row in
pg_constraint at all.
Why is this? What determines if a unique index will also have a
We're seeing gobs of these via dmesg in PostgreSQL 8.3.3 on
ia64-unknown-linux-gnu, compiled by GCC gcc (GCC) 3.4.6 20060404
(Red Hat 3.4.6-8), kernel 2.6.9-55.EL:
postmaster(13144): floating-point assist fault at ip
403a9382, isr 0408
It appears to be an Itanium-specific
On Thursday 08/07/08 @ 5:43 pm MDT, I received this from "Ed L."
<[EMAIL PROTECTED]>:
> We're seeing gobs of these via dmesg in PostgreSQL 8.3.3 on
> ia64-unknown-linux-gnu, compiled by GCC gcc (GCC) 3.4.6
> 20060404 (Red Hat 3.4.6-8), kernel 2.6.9-55.EL:
>
&g
On Thursday 08/07/08 @ 5:46 pm MDT, I received this from "Ed L."
> > postmaster(13144): floating-point assist fault at ip
> > 403a9382, isr 0408
>
> These are coming lately exclusively from the writer process...
Actually, the machine has been up f
Need some help.
My PostgreSQL 8.3.6 and now 8.3.9 postmaster is hanging.
No idea why, been running like a top for a year.
Can't do "select version()", even hung after system reboot.
SIGINT/QUIT/TERM have no effect, only SIGKILL can stop it.
This is Linux 2.6.18-92.1.22.el5 SMP x86_64
Here's
On Saturday 27 February 2010 @ 22:18, Greg Smith wrote:
> Ed L. wrote:
> > 2010-02-27 20:11:10.426 CST [23134]LOG: database system
> > was not properly shut down; automatic recovery in progress
> > 2010-02-27 20:11:10.497 CST [23134]LOG: record with
> > zero le
On Monday 01 March 2010 @ 15:41, Ed Loehr (LoehrTech.com) wrote:
> "Ed L." writes:
> > (gdb) bt
> > #0 0x00346f8c43a0 in __read_nocancel () from
> > /lib64/libc.so.6 #1 0x00346f86c747 in
> > _IO_new_file_underflow () from /lib64/li
On Monday 01 March 2010 @ 15:46, Ed L. wrote:
> On Monday 01 March 2010 @ 15:41, Ed Loehr (LoehrTech.com) wrote:
> > "Ed L." writes:
> > > (gdb) bt
> > > #0 0x00346f8c43a0 in __read_nocancel () from
> > > /lib64/libc.so.6 #1 0x00346f86c747
On Monday 01 March 2010 @ 15:59, Ed L. wrote:
> > This just happened again ~24 hours after full reload from
> > backup. Arrrgh.
> >
> > Backtrace looks the same again, same file, same
> > __read_nocancel(). $PGDATA/global/pg_auth looks fine to me,
> > permis
On Monday 01 March 2010 @ 16:03, Ed L. wrote:
> On Monday 01 March 2010 @ 15:59, Ed L. wrote:
> > > This just happened again ~24 hours after full reload from
> > > backup. Arrrgh.
> > >
> > > Backtrace looks the same again, same file, same
> > >
On Monday 01 March 2010 @ 16:57, Tom Lane wrote:>
> Now that I look more closely at those line numbers, it looks
> like the thing thinks it is processing an include file. Are
> there any @ signs in your global/pg_auth file?
Yes, indeed, there are many. My user names are "u...@host" form,
and
On Monday 01 March 2010 @ 17:15, Tom Lane wrote:
> "Ed L." writes:
> > On Monday 01 March 2010 @ 16:57, Tom Lane wrote:>
> >
> >> Now that I look more closely at those line numbers, it
> >> looks like the thing thinks it is processing an include
&g
On Monday 01 March 2010 @ 16:49, Tom Lane wrote:
>
> Oh, for some reason I thought it was sitting idle. That
> sounds more like an infinite loop. Try reattaching to the
> postmaster, confirm the stack trace, and then see how many
> times you can do "fin" before it doesn't return control.
>
On Monday 01 March 2010 @ 17:18, Tom Lane wrote:
> "Ed L." writes:
> > On Monday 01 March 2010 @ 17:15, Tom Lane wrote:
> >> u...@host shouldn't be a problem, but if there were an @ by
> >> itself or starting a token, it might possibly cause
> >&g
On Monday 01 March 2010 @ 17:23, Ed L. wrote:
> On Monday 01 March 2010 @ 17:18, Tom Lane wrote:
> > "Ed L." writes:
> > > On Monday 01 March 2010 @ 17:15, Tom Lane wrote:
> > >> u...@host shouldn't be a problem, but if there were an @
> > >&g
On Monday 01 March 2010 @ 17:25, Ed L. wrote:
> On Monday 01 March 2010 @ 17:23, Ed L. wrote:
> > On Monday 01 March 2010 @ 17:18, Tom Lane wrote:
> > > "Ed L." writes:
> > > > On Monday 01 March 2010 @ 17:15, Tom Lane wrote:
> > > >>
On Monday 01 March 2010 @ 17:26, Tom Lane wrote:
> "Ed L." writes:
> > On Monday 01 March 2010 @ 17:18, Tom Lane wrote:
> >> "Ed L." writes:
> >>> There is one, looks like a typo got in. How do I fix it?
> >>
&
On Monday 01 March 2010 @ 17:36, Ed L. wrote:
> On Monday 01 March 2010 @ 17:26, Tom Lane wrote:
> > "Ed L." writes:
> > > On Monday 01 March 2010 @ 17:18, Tom Lane wrote:
> > >> "Ed L." writes:
> > >>> There is one, looks like a
On Monday 01 March 2010 @ 17:58, Tom Lane wrote:
> "Ed L." writes:
> > Killed the stuck postmaster with sigkill, edited the file,
> > restarted postmaster, and it re-wrote the file with the
> > bogus entry. I don't have any superuser sessions open. Is
>
On Monday 01 March 2010 @ 17:57, Tom Lane wrote:
> "Ed L." writes:
> >> Correction. Here's the line:
> >> "@" "" "" "agent_group"
> >
> > It is the first line in the pg_auth file.
>
> BTW, there seem
On Monday 01 March 2010 @ 18:29, Tom Lane wrote:
> "Ed L." writes:
> > That did the trick. Thank you very much, Sensei.
>
> I'd still like to know about platform etc. I see that we
> shouldn't be allowing a username to trigger @-file expansion,
>
I've been tracking the performance of our DB query statements
across a number of fairly high-volume pg clusters for several
years (combined 2700 tps, ~1.3TB). Last year, we started
migrating off HP-UX IA64 servers running pg 8.1.x onto Linux
quadcore x86_64 Blade servers running pg 8.3.x while
I'm attempting to measure database query performance across a
large number of high-volume clusters. I'd like to share a
couple of ideas and hear what other ideas folks know of for this
problem. I suppose there are existing solutions, I just haven't
found them.
The idea here is to systematic
On Tuesday March 22 2005 9:36, Vivek Khera wrote:
> While poking through the logs for these errors, I'm finding a
> *lot* of broken pipe/unexpected EOF errors for this server but
> for connections from other hosts as well, running reports.
> those hosts still have the 7.4 client libraries.
You mi
On Monday March 21 2005 4:30, Ed L. wrote:
> I'm attempting to measure database query performance across a
> large number of high-volume clusters
Let me try rephrasing this: Is anyone systematically measuring
query execution times across multiple clusters to identify
performanc
On Tuesday March 22 2005 1:32, Qingqing Zhou wrote:
>
> Sorry, forget to mention this project:
> http://pqa.projects.postgresql.org/example.html
Ah, that's interesting. I overlooked that post earlier since I
wasn't CC'd. Thanks!
Ed
---(end of broadcast)---
On Thursday March 24 2005 7:07, [EMAIL PROTECTED] wrote:
> Thank you for registering!
>
> http://www.sys-con.com/linux/readerschoice2004
Curiously, I see PostgreSQL is not even on the ballot I see at
the site above for Best Linux Database ... could be a browser
config issue, but I do see the oth
This is for PostgreSQL 7.4.6 on hppa2.0w-hp-hpux11.00, compiled
by GCC 3.2.2. I'm seeing the following 2 errors:
ERROR: missing chunk number 0 for toast value 19319495
ERROR: unexpected chunk number 4 (expected 0) for toast value
19319495
It is always the same toast value. The table has 1.
On Wednesday April 27 2005 3:55 pm, Tom Lane wrote:
> > ERROR: Âmissing chunk number 0 for toast value 19319495
> > ERROR: Âunexpected chunk number 4 (expected 0) for toast
> > value 19319495
>
> Have you tried REINDEXing the toast table in question?
Not yet. Any way to repair it without blocking
On Wednesday April 27 2005 4:40 pm, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > On Wednesday April 27 2005 3:55 pm, Tom Lane wrote:
> >> Have you tried REINDEXing the toast table in question?
> >
> > Not yet. Any way to repair it withou
On Wednesday April 27 2005 6:11 pm, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > Does this shed any light? pg_toast_6221538 is the relevant
> > toast table...
> >
> > $ psql -c "set enable_indexscan=off; select chunk_seq,
> > l
If I store images as blobs in pgsql, will they be loaded into the
db shared memory cache as they are retrieved?
What are the tradeoffs of storing images as bytea vs blobs?
Thanks.
Ed
---(end of broadcast)---
TIP 3: if posting/reading through Usen
On Wednesday May 18 2005 2:10 pm, Ed L. wrote:
> What are the tradeoffs of storing images as bytea vs blobs?
Actually, I see you can't store/retrieve blobs remotely, which is
a non-starter. So the remaining choices seem to be bytea vs.
storing only metadata and keeping the images e
On Wednesday May 18 2005 2:40 pm, Joshua D. Drake wrote:
> Ed L. wrote:
> > On Wednesday May 18 2005 2:10 pm, Ed L. wrote:
> >>What are the tradeoffs of storing images as bytea vs blobs?
> >
> > Actually, I see you can't store/retrieve blobs remotely,
> >
On Wednesday May 18 2005 2:57 pm, Joshua D. Drake wrote:
> > What api/language are you using? Is this possible to do
> > through DBI? If you don't use lo_import/lo_export, how do
> > you insert/retrieve images? Pointers to docs are welcomed!
>
> I have done it via PHP and I can definately insert
Someone flipped a breaker switch, and evidently triggered
corruption in one of our major clusters:
$ cat server_log.Mon
postmaster successfully started
2005-06-06 14:31:11.950 [20124] LOG: database system was interrupted being in
recovery at 2005-06-06 14:29:01 EDT
This probably mean
On Monday June 6 2005 2:16 pm, Ed L. wrote:
> Someone flipped a breaker switch, and evidently triggered
> corruption in one of our major clusters:
BTW, this is a 7.3.4 cluster ...
Ed
---(end of broadcast)---
TIP 9: the planner will ignor
On Monday June 6 2005 3:17 pm, Scott Marlowe wrote:
> On Mon, 2005-06-06 at 15:16, Ed L. wrote:
> > Someone flipped a breaker switch, and evidently triggered
> > corruption in one of our major clusters:
>
> OK, if postgresql is running on hardware that doe NOT lie
> about
On Monday June 6 2005 3:29 pm, Ed L. wrote:
> On Monday June 6 2005 3:17 pm, Scott Marlowe wrote:
> > On Mon, 2005-06-06 at 15:16, Ed L. wrote:
> > > Someone flipped a breaker switch, and evidently triggered
> > > corruption in one of our major clusters:
> >
&g
On Monday June 6 2005 11:15 pm, Tom Lane wrote:
> It's possible that you are one minor release short of having
> dodged this problem, as I see in the 7.3.5 CVS log
>
> * src/backend/storage/buffer/bufmgr.c (REL7_3_STABLE): Force
> zero_damaged_pages to be effectively ON during recovery
On Monday June 6 2005 11:15 pm, Tom Lane wrote:
> This doesn't really address the question of how the page
> header got clobbered in the first place, though. Did you by
> any chance make a dump to see what data was in there?
I couldn't start the postmaster at all with that data in the
cluster, s
I have an HP ia64 11.23 server with 16gb of
RAM running 6 pgsql clusters. I'm seeing this old error when attempting to
restart a legacy 7.3.4 cluster after a power outage:
./postmaster successfully
startedIpcMemoryCreate: shmget(key=9099001, size=110002176, 03600) fail
IpcMemoryCreate:
shmget(key=9099001, size=110002176, 03600) failed: Not enough
space
This error usually means that PostgreSQL's
request for a sharedmemory segment exceeded available memory or swap
space.To reduce the request size (currently 110002176 bytes),
reducePostg
On Tuesday June 21 2005 12:49 pm, Bruce Momjian wrote:
> I have received very few replies to my suggestion that we
> implement E'' for escaped strings, so eventually, after a few
> major releases, we can have '' treat backslashes literally
> like the SQL standard requires.
>
> I assume this is beca
On Wednesday June 22 2005 2:16 am, Gregory Youngblood wrote:
> I am looking for some information about clustering and
> replication options for postgresql.
Gregory,
FWIW, I've used Slony 1.0.5 for 10-15 db cluster migrations,
usually from 7.3.4 clusters on one box to 7.4.6 clusters on
another (
I have a 7.4.6 db running on itanium hpux 11.23. It appears a
vacuum ran out of disk space,
2005-07-20 13:47:43 [6161] ERROR: DBI::do failed for SQL
[VACUUM VERBOSE] to database clincomm: DBI error: PANIC:
could not write to file
"/users/postgresql-7.4.6/data/pg_xlog/xlogtemp.6178": No
On Wednesday July 20 2005 1:13 pm, Ed L. wrote:
> I have a 7.4.6 db running on itanium hpux 11.23. It appears a
> vacuum ran out of disk space,
Oh, and of course, we created extra diskspace before
restarting...
Ed
>
> 2005-07-20 13:47:43 [6161] ERROR: DBI::do failed for S
On Wednesday July 20 2005 1:19 pm, Ed L. wrote:
> On Wednesday July 20 2005 1:13 pm, Ed L. wrote:
> > I have a 7.4.6 db running on itanium hpux 11.23. It appears
> > a vacuum ran out of disk space:
> > 2005-07-20 13:47:43 [6161] ERROR: DBI::do failed for SQL
> > [
Our inserts and updates on an older 7.3.4 cluster are very slow
(0.3s-0.9s) for any/all tables, new and old. I know an upgrade
may be in order, but I have a number of other 7.3.4 legacy
clusters, and I'd really like to understand the cause and if an
upgrade is going to solve this problem (dow
Can someone help find (or create) a client/server compatibility
matrix that shows which client versions are compatible with
which server versions? For example,
server: 7.1.2 7.2.1 7.2.2 7.2.3 ...
client
==
7.1.2 YesNo NoNo ...
7.2.1 No
7.2.2 No
7.2.3
I have two identical servers giving abysmal INSERT performance in
pgsql 7.3.4, 7.4.8, and 8.1devel under no load or I/O contention
at all (no dumps, no vacuums, no apps, etc). Any suggested
investigations appreciated...
Metric: I'm measuring average insert speed on the following
table with
On Wednesday August 10 2005 6:03 pm, Michael Fuhr wrote:
> On Wed, Aug 10, 2005 at 05:02:46PM -0600, Ed L. wrote:
> > I have two identical servers giving abysmal INSERT
> > performance in pgsql 7.3.4, 7.4.8, and 8.1devel under no
> > load or I/O contention at all (no dumps, no
On Thursday August 11 2005 12:36 pm, Ed L. wrote:
> On Wednesday August 10 2005 6:03 pm, Michael Fuhr wrote:
> > On Wed, Aug 10, 2005 at 05:02:46PM -0600, Ed L. wrote:
> > > I have two identical servers giving abysmal INSERT
> > > performance in pgsql 7.3.4, 7.4.8, and 8
On Thursday August 11 2005 1:37 pm, Michael Fuhr wrote:
> Have you done any client-side tests that eliminate Perl? I'd
> suggest writing a little C program so you can measure libpq's
> performance without the extra layers of Perl and DBI/DBD::Pg.
> Test both local (Unix socket) and network (IPv4
On Thursday August 11 2005 6:20 pm, Michael Fuhr wrote:
> On Thu, Aug 11, 2005 at 03:29:29PM -0600, Ed L. wrote:
> > Michael, you nailed it again. My libpq test C program
> > delivered between 2400 QPS and 5000 QPS vs ~10 QPS for
> > DBI/DBD::Pg on this box.
> >
>
On Friday August 12 2005 5:27 pm, Michael Fuhr wrote:
> On Fri, Aug 12, 2005 at 05:20:49PM -0600, Ed L. wrote:
> > Well, just as I thought I had this one pinned, my test
> > results have become wildly inconsistent, eroding all
> > confidence in my prior conclusions ab
On Friday August 12 2005 6:11 pm, Michael Fuhr wrote:
> Has anything changed on the system since the results were
> consistently slow? New hardware, new versions of anything,
> reboot, etc.? Did you do any profiling when DBD::Pg was
> consistently slow to see where the bottleneck was?
All good q
On Friday August 12 2005 6:29 pm, Michael Fuhr wrote:
> I meant profiling of DBD::Pg, as Greg Sabino Mullane
> suggested. Here's his message in case you missed it:
No, I didn't miss that, and will do that as a next step. Thanks,
Michael.
Ed
---(end of broadcast)---
I have an 8.1.4 autovac process running on HP-UX 11.23 IA64 and
repeatedly failing with the following error:
ERROR: failed to re-find parent key in "audit_idx1"
Will a reindex or drop index make this problem go away?
Is there anything I can do to help identify the underlying issue?
(
On Monday October 23 2006 4:03 pm, Ed L. wrote:
> I have an 8.1.4 autovac process running on HP-UX 11.23 IA64
> and repeatedly failing with the following error:
>
> ERROR: failed to re-find parent key in "audit_idx1"
>
> Will a reindex or drop index make this
We're taking some politically expensive downtime to drop an index
on a very large, heavily used table because to do it while live
blocks too many users for too long, requiring tens of seconds or
more on a system doing 200 transactions/second. That's due to
the fact that nearly every user inter
Can I kill -SIGINT autovac in 8.1.2 without taking down all the
other backends?
Thanks,
Ed
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
One of our 8.1.2 postmasters on HPUX 11.23 ia64 just received a
SIGKILL signal from unknown origins. After reviewing all
command history files for the DBA and root, I do not believe
anyone manually sent it, and we have no scripts etc that would
do that, at least that we can find or imagine.
On Wednesday November 8 2006 11:31 am, novnov wrote:
> Yes, I've already pretty much decided to use lowercase for all
> namestyles, I mentioned that in the first post. Using
> lowercase invokes a set of other issues, which I'm asking for
> options on...namely, conventions like org_id, and emp_org_i
We are having locking issues in 8.1.2 on HP 11.23 ia64. I'm
trying to better understand how to conclusively identify who is
waiting on who and why.
We have a series of "select for updates" on our 'sessions' table.
One of those queries is stuck waiting for a "transactionid"
locktype ShareLoc
I have a few questions on pgsql locking terms and such...
I created the following view to make viewing the locks
a little easier:
-- CREATE OR REPLACE VIEW locksview AS
-- SELECT l.*, r.*, a.*, now() - a.query_start as query_age,
--substring(replace(current_query, '\n', ' '), 1, 30) as
I have an 8.1.2 autovac which appears to be hanging/blocking
every few days or so, but we're don't understand what's causing
it. I wasn't able to catch a backtrace before we killed it. I
do not see autovac locks in the pg_locks view.
Will running 8.1.5 buy me anything in terms of being able t
On Tuesday November 14 2006 12:49 pm, Jim C. Nasby wrote:
> On Tue, Nov 14, 2006 at 11:20:30AM -0700, Ed L. wrote:
> > I have an 8.1.2 autovac which appears to be hanging/blocking
> > every few days or so, but we're don't understand what's
> > causing it. I was
On Tuesday November 14 2006 12:56 pm, Jim C. Nasby wrote:
> You don't have the vacuum cost delay settings set unreasonably
> high, do you?
On Tuesday November 14 2006 12:56 pm, you wrote:
> You don't have the vacuum cost delay settings set unreasonably
> high, do you?
I'm not sure. Here's what we
Does autovac maintain its state/counters across restats as to who
need to be vacuumed/analyzed? Or does killing autovac cause it
to reset the counters for the vacuum/analyze threshholds?
TIA.
Ed
---(end of broadcast)---
TIP 1: if posting/reading
On Tuesday November 14 2006 1:02 pm, Ed L. wrote:
> On Tuesday November 14 2006 12:56 pm, Jim C. Nasby wrote:
> > You don't have the vacuum cost delay settings set
> > unreasonably high, do you?
>
> On Tuesday November 14 2006 12:56 pm, you wrote:
> > You don'
On Tuesday November 14 2006 11:51 pm, Matthew T. O'Connor wrote:
> Ed L. wrote:
> > Does autovac maintain its state/counters across restats as
> > to who need to be vacuumed/analyzed? Or does killing
> > autovac cause it to reset the counters for the
> > vacuum/ana
On Wednesday November 15 2006 6:30 am, Alvaro Herrera wrote:
>
> > The table in
> > question appears to be the pathological case for vacuum:
> > very large with lots of frequent UPDATEs. It's essentially
> > a log table.
>
> A big log table where the log entries are being updated?
> Certainly so
On Wednesday November 15 2006 4:18 pm, Morris Goldstein wrote:
> If I'm vacuuming every day (or two), and not running anywhere
> near 1 billion transactions a day, why am I running into
> transaction id wraparound problems?
> Is this just complaining that template0 and template1 haven't
> been vac
On Thursday November 16 2006 3:33 am, Richard Huxton wrote:
> Ed L. wrote:
> > One idea would be to partition the table some how such that
> > the chunks getting vacuumed are much smaller and thus not
> > such an impact. On the app side, I suppose we could break
> > the
I wonder if anyone might help me generate a SQL query that peers
into pg_locks, pg_stat_activity, etc and tells in plain language
exactly *who* each backend is blocked *on* while awaiting
lock(s).
Here's what I'm looking at now:
SELECT date_trunc('second', now()) as now, a.client_addr as ip,
On Thursday January 18 2007 6:07 am, Bill Moran wrote:
> Right. It doesn't _look_ that way from the graph, but that's
> because I only graph total DB size. I expect if I graphed
> data and index size separately, it would be evident.
pg_total_relation_size() might give you what you want there.
>
1 - 100 of 281 matches
Mail list logo
