The following bug has been logged online:
Bug reference: 5459
Logged by: Mason Hale
Email address: ma...@onespot.com
PostgreSQL version: 8.3.8
Operating system: Redhat EL 5.1-64 bit
Description:Unable to cancel query while in send()
Details:
ISSUE: unable to cancel
>
>
> >> If the sysadmin had left the recovery.conf and removed the trigger file,
> >> pg_standby in restore_command would have restored all WAL files required
> >> for recovery, and recovery would advance well.
> >
> > That may be true, but it's certainly seems unfortunate that we don't
> > handle
again,
Mason
On Fri, Jan 29, 2010 at 10:02 AM, Fujii Masao wrote:
> On Fri, Jan 29, 2010 at 11:49 PM, Mason Hale wrote:
> > While I did not remove the trigger file, I did rename recovery.conf to
> > recovery.conf.old.
> > That file contained the recovery_command configurat
> On Fri, Jan 29, 2010 at 12:03 AM, Mason Hale wrote:
> > Of course the best solution is to avoid this issue entirely. Something as
> > easy to miss as file permissions should not cause data corruption,
> > especially in the process meant to fail over from a crashing primar
on of the trigger file.
Of course the best solution is to avoid this issue entirely. Something as
easy to miss as file permissions should not cause data corruption,
especially in the process meant to fail over from a crashing primary
database.
thanks,
Mason Hale
http://www.onespot.com
direct +1 800
Hello --
We are using PostgreSQL 8.3.8 with a Warm Standy (PITR) setup.
Recently we experienced a failure on our primary database server and
when we attempted to fail over to the standby server it would not come
up.
This configuration has been tested previously (we've successfully
transferred fro
Hi everyone --
Sorry to revisit a dead horse, but I wanted to clear up some misinformation
--
On Dec 31, 2007 5:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> This could be the kernel's fault, but I'm w
Hello Tom --
a thousand thanks for taking the time to walk through those files.
This could be the kernel's fault, but I'm wondering whether the
> RAID controller is going south. Offhand it seems like the controller
> would be the only place that would be likely to explain both the
> bogus-data an
On Dec 31, 2007 12:51 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> > If it is some mysterious hardware or kernel error -- any suggestions for
> how
> > I should go about narrowing that down?
>
> The first thing
>
> Something else interesting about that: the apparent interloper page
> contains just a single WAL record, which appears to be a shutdown
> checkpoint bearing the timestamp "Thu Dec 27 2007, 16:55:01 EST".
> Not sure if Mason can correlate that with any recent activity...
>
Nothing jumps to mind
Tom, I'll send these to you privately.
Mason
On Dec 31, 2007 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> Can you show us all the triggers on this table?
>
> > Here they are:
>
> > Triggers:
On Dec 31, 2007 9:48 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> I think you misread Mason's post of 20:23 GMT-6 where he says the
> >> created_at values are the *same*, not different. Mason's previ
>
>
> I think you misread Mason's post of 20:23 GMT-6 where he says the
> created_at values are the *same*, not different. Mason's previous bug
> report 3724 also had duplicate rows with matching created_at values.
>
Yes, to confirm, the created_at values are the same. The *only* values that
are d
>
>
> Can you show us all the triggers on this table?
Here they are:
Triggers:
entry_correct_published_at_trigger BEFORE INSERT OR UPDATE ON entry FOR
EACH ROW EXECUTE PROCEDURE correct_published_at()
entry_feed_page_trigger BEFORE INSERT OR UPDATE ON entry FOR EACH ROW
EXECUTE PROCEDURE
ive server
processes
This seems related to the entry table -- so I wonder if it is related to
this problem?
On Dec 30, 2007 8:23 PM, Mason Hale <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 30, 2007 12:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > "Mason Hal
On Dec 30, 2007 12:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> > Given my experience, the reliability of unique indexes is becoming
> somewhat
> > suspect. Please help. ;-)
>
> Well, as in the previous r
Hello --
I noticed recently some errors in my postgres log like the following:
ERROR: could not open segment 9 of relation 1663/16830/1384385 (target
block 776929292): No such file or directory
These are occurring at a rate of 1 every 2-3 days. But that rate has been
increasing.
After Googling
> >> 2. Can you check that there are still 1 (rather than 0) copies of the
> >> rows in the 8.2.5 DB?
>
> > Yes, we have 1 of each row (I kept the most recently updated version of
> > each):
>
> Ah, I forgot that the rows were obviously not identical because of the
> differing updated_at values.
>
On Nov 6, 2007 1:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> For that matter, do you still see dups if you prevent use of the index
> >> in the 8.2.5 query? Maybe it's that index that is corrupt.
&
On Nov 6, 2007 11:16 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> > However running the same query on the original 8.2.4 database returns
> zero
> > rows:
>
> > prod_1=> select page_id, count(*) from topic
The following bug has been logged online:
Bug reference: 3724
Logged by: Mason Hale
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Redhat Linux (kernel: Linux 2.6.18-8.1.15.el5PAE)
Description:Duplicate values added to table despite
s is not a bug.Unfortunately the INTERSECT ALL as spec'd and implemented doesn't quite give me what I need. So back to the drawing board for me...best regards,Mason
On 11/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Mason Hale" <[EMAIL PROTECTED]> writes:> The query below should
The following bug has been logged online:
Bug reference: 2739
Logged by: Mason Hale
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: GNU/Linux 2.6.9-42.0.3.ELsmp
Description:INTERSECT ALL not working
Details:
'INTERSECT ALL'
23 matches
Mail list logo
