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
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,
>
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 @ 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: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: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: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: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: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 @ 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: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: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 @ 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 @ 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 @ 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: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 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
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
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
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
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
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 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
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
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
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
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
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 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
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 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?
> &
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 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: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
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
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/
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
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
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
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
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
>
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 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: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 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 Tuesday 01 May 2007 2:46 pm, Ed L. wrote:
> It is indeed a local connection using PGHOST=`hostname`. That
> name maps to one of the external NIC IPs, not to the normal
> 127.0.0.1 loopback address. For context, I've seen this a
> number of times over the past couple years,
On Tuesday 01 May 2007 2:23 pm, Tom Lane wrote:
> Well, it's going wrong here:
>
> socket(AF_INET, SOCK_STREAM, 0) .. = 4
> setsockopt(4, 0x6, TCP_NODELAY, 0x9fffe210, 4) ... = 0
> fcntl(4, F_SETFL, 65536) . = 0
> fcntl(4, F_SETFD, 1)
On Thursday 26 April 2007 9:42 am, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > After a reboot (and usually after an OS patch) on our HP-UX
> > 11.23 64-bit Itanium DB servers, our libpq/DBD::Pg libraries
> > cease to work. Instead, they give the
On Thursday 26 April 2007 8:50 am, Ed L. wrote:
> After a reboot (and usually after an OS patch) on our HP-UX
> 11.23 64-bit Itanium DB servers, our libpq/DBD::Pg libraries
> cease to work. Instead, they give the standard message you
> get when the DB cluster is not running. But we
After a reboot (and usually after an OS patch) on our HP-UX 11.23
64-bit Itanium DB servers, our libpq/DBD::Pg libraries cease to
work. Instead, they give the standard message you get when the
DB cluster is not running. But we *know* it is running and all
access paths are working. We have f
On Wednesday April 4 2007 5:37 pm, Bruce Momjian wrote:
> > Perhaps this could be added to the TODO list? I won't get
> > to it anytime soon.
>
> Yes. What should the TODO text be?
See if the attached patch is acceptable. If not, perhaps the
TODO text should be:
Enable end user to identify de
On Wednesday April 4 2007 5:02 pm, Alvaro Herrera wrote:
> > I guess if the bug were fixed, it'd be a non-issue.
>
> Sure, please submit a patch. It should not be too difficult.
Perhaps this could be added to the TODO list? I won't get to it
anytime soon.
Ed
---(end o
On Wednesday April 4 2007 4:48 pm, Alvaro Herrera wrote:
> > Yes, but how do identify what they are so that I know if I
> > want to DROP OWNED them?
>
> There's no way AFAICT, short of peeking the catalogs (or
> information_schema). Try pg_shdepend.
I guess if the bug were fixed, it'd be a non-is
On Wednesday April 4 2007 4:41 pm, Ed L. wrote:
> On Wednesday April 4 2007 4:39 pm, Ed L. wrote:
> > On Wednesday April 4 2007 4:35 pm, Alvaro Herrera wrote:
> > > Note that you can give the objects owned by that role to
> > > someone else with REASSIGN OWNED, and drop
On Wednesday April 4 2007 4:39 pm, Ed L. wrote:
> On Wednesday April 4 2007 4:35 pm, Alvaro Herrera wrote:
> > Note that you can give the objects owned by that role to
> > someone else with REASSIGN OWNED, and drop the objects with
> > DROP OWNED (note that they act differe
On Wednesday April 4 2007 4:35 pm, Alvaro Herrera wrote:
>
> Note that you can give the objects owned by that role to
> someone else with REASSIGN OWNED, and drop the objects with
> DROP OWNED (note that they act differently regarding grants;
> see the docs)
Yes, but how do identify what they are
This is pgsql 8.2.3:
% psql -c "drop role mygroup"
ERROR: role "mygroup" cannot be dropped because some objects
depend on it
DETAIL: 227 objects in this database
How do I identify what these dependent objects are?
I've removed all of the users from this group, turned up server
logging to deb
On Monday March 12 2007 4:08 pm, Martijn van Oosterhout wrote:
> On Mon, Mar 12, 2007 at 01:13:42PM -0600, Ed L. wrote:
> > Would I be correct in understanding that every pre-8.0
> > cluster must be restarted in order for the OS changes to
> > take affect?!?
>
>
On Monday March 12 2007 1:07 pm, Ed L. wrote:
> Does this mean that we need to restart these clusters in order
> to get the timezone updates from the OS? Are they cached in
> the postmaster?
Nevermind. I just found it via googling.
Would I be correct in understanding that every pre-8.
We have a 7.4.6 cluster which has been running on an HP B.11.00
box for quite sometime. The IT group applied daylight savings
patches to the OS, but the cluster is still showing the
incorrect timezone:
$ psql -c "select now()"
now
---
2
On Wednesday March 7 2007 3:13 am, Martijn van Oosterhout wrote:
> On Wed, Mar 07, 2007 at 02:29:08AM -0700, Ed L. wrote:
> > Perhaps my question was not clear enough. Let me rephrase:
> > Does the fix for this problem comes from a *fresh* DB
> > structure resulting from
On Wednesday February 7 2007 9:01 am, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > How do I fix this 7.4.6 issue short of initdb?
> > invalid page header in block 110 of relation "pg_statistic"
> > I looked at the block via pg_filedu
On Tuesday March 6 2007 11:52 pm, Peter Eisentraut wrote:
> Ed L. wrote:
> > Right. I'm asking if the fix for this problem is in the new
> > 8.1.8 software, or in the new DB structure resulting from
> > the initdb, or perhaps both.
>
> There is no new DB structur
On Tuesday March 6 2007 3:53 pm, Joshua D. Drake wrote:
>
> > Is restarting with 8.1.8 a known solution for this problem?
> > Or is an initdb required to fix it?
>
> You can update to 8.1.8 (if you are running 8.1.x) without an
> initdb.
Right. I'm asking if the fix for this problem is in the n
On Tuesday March 6 2007 12:20 pm, Peter Eisentraut wrote:
> Ed L. wrote:
> > I am seeing the following error in pgsql 8.1.2:
> >
> > ERROR: could not access status of transaction 3229475082
> > DETAIL: could not open file "pg_clog/0C07": No such file or
&g
I am seeing the following error in pgsql 8.1.2:
2007-03-05 10:00:51.106 PST [9834]DEBUG: vacuuming "pg_toast.pg_toast_1260"
2007-03-05 10:00:51.106 PST [9834]DEBUG: index "pg_toast_1260_index" now
contains 0 row versions in 1 pages
2007-03-05 10:00:51.106 PST [9834]DETAIL: 0 index
On Friday February 23 2007 3:06 pm, Ed L. wrote:
> > I've been periodically collecting the stats stored in
> > pg_statio_all_tables and pg_stat_database for ~30 different
> > clusters, and have noticed a curiosity... The table-level IO stats
> > appear to be typi
Oops, typo: I reversed the inequality. I've corrected it below.
On Friday February 23 2007 2:02 pm, Ed L. wrote:
> I've been periodically collecting the stats stored in
> pg_statio_all_tables and pg_stat_database for ~30 different
> clusters, and have noticed a curiosit
I've been periodically collecting the stats stored in
pg_statio_all_tables and pg_stat_database for ~30 different
clusters, and have noticed a curiosity.
I would have thought that for a given period, the change in
pg_stat_database.blks_read would be <= the sum of the changes in
pg_statio_user
On Wednesday February 7 2007 9:01 am, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > How do I fix this 7.4.6 issue short of initdb?
> > invalid page header in block 110 of relation "pg_statistic"
> > I looked at the block via pg_filedu
How do I fix this 7.4.6 issue short of initdb?
invalid page header in block 110 of relation "pg_statistic"
I looked at the block via pg_filedump (included below), and it
does not appear to me to be corrupted, so not sure what I would
zero out, if anything.
TIA.
Ed
***
From the FAQ:
1.14) Will PostgreSQL handle recent daylight saving time changes
in various countries?
PostgreSQL versions prior to 8.0 use the operating system's
timezone database for daylight saving information. All current
versions of PostgreSQL 8.0 and later contain up-
We have a large number (50+) of pre-8.2 clusters. How can I
best/most easily identify those indices most bloated and in need
of reindex/rebuilding?
Ed
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://ar
On Friday January 19 2007 2:11 am, Csaba Nagy wrote:
>
> > I afraid I don't see how any of the answers I saw discussed
> > fit a 24x7 operation. Reindex, drop index, vacuum full, ...
> > they all block production queries of one sort or another for
> > significant periods of time (minutes) on large
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.
>
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 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
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 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 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 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'
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 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
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
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
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
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
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
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.
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
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
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
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?
(
We'd like to attempt some log replay to simulate real loads, but
in 8.1.2, it appears the formal parameters are logged ('$')
instead of the actuals for prepared queries, e.g.:
EXECUTE [PREPARE: UPDATE sessions SET a_session = $1
WHERE id = $2]
Thoughts on making this a to-do item?
Ed
---
On Tuesday July 11 2006 3:16 pm, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > We are wondering if our swap space was too small, and when
> > the swap reservation failed, the OS was sending SIGINT??
>
> You'd have to check your OS documentati
On Tuesday July 11 2006 1:17 pm, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > We have 4 8.1.2 cluster running on an HP-UX 11.23 Itanium,
> > repeatedly dying with the following log message:
> >
> > 2006-07-11 12:52:27 EDT [21582]
We have 4 8.1.2 cluster running on an HP-UX 11.23 Itanium, repeatedly
dying with the following log message:
2006-07-11 12:52:27 EDT [21582]LOG: received fast shutdown request
2006-07-11 12:52:27 EDT [21591]LOG: shutting down
2006-07-11 12:52:27 EDT [21591]LOG: database system is shu
On Tuesday May 23 2006 4:55 pm, Jim C. Nasby wrote:
> Well, I did find one reason not to go ape with this: the
> number of pages analyzed scales with the number of buckets, so
> doubling the statistics target will roughly double the ANALYZE
> time for any table over 6000 pages (though the effect is
On Wednesday May 17 2006 1:26 pm, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > I'm trying to understand what happened here, and I have a
> > theory.
>
> The problem is the horrid misestimation of the selectivity of
> "nursestation_key
On Wednesday May 17 2006 11:44 am, Ed L. wrote:
> On Wednesday May 17 2006 10:37 am, Ed L. wrote:
> > Can someone help me understand why the 8.1.2 query below is
> > using a seq scan instead of an index scan? All relevant
> > columns appear to be indexed and all t
1 - 100 of 281 matches
Mail list logo
