"Kevin Duffy" <[EMAIL PROTECTED]> writes:
> Can someone explain why the NULL ISINs in Security is causing
> so much grief? I do not get it.
NULL generally is taken as "unknown" in SQL comparisons. So if you have
any nulls in the output of the sub-select, what the upper select sees
is a situatio
On Wed, Oct 29, 2008 at 7:24 PM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
Oh, and to reply to myself and the original poster, you need to figure
out what's causing the pages to get damaged. IT's usually bad
hardware, then a buggy driver, then a buggy kernel / OS that can cause
it. Run lots of te
On Wed, Oct 29, 2008 at 6:36 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Scott Marlowe" <[EMAIL PROTECTED]> writes:
>> On Wed, Oct 29, 2008 at 4:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> If you can tolerate losing the data on that page, just zero out the
>>> entire 8K page. dd from /dev/zero i
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> On Wed, Oct 29, 2008 at 4:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> If you can tolerate losing the data on that page, just zero out the
>> entire 8K page. dd from /dev/zero is the usual tool.
> Would zero_damaged_pages work here? I know it's a sh
On Wed, Oct 29, 2008 at 4:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>> There is a way to 'correct' or blank the values somehow? I guess im going
>> to lose some data, iisnt...
>
> If you can tolerate losing the data on that page, just zero out the
> entire 8K page. dd
[EMAIL PROTECTED] writes:
> There is a way to 'correct' or blank the values somehow? I guess im going
> to lose some data, iisnt...
If you can tolerate losing the data on that page, just zero out the
entire 8K page. dd from /dev/zero is the usual tool.
regards, tom lane
Hi all. I've seen this searching in google. After a select on a table, i
got this:
ERROR: invalid page header in block 399 of relation "xxx"
I read about a tool called pg_filedump, and after some searchs about its
usage, i execute
pg_filedump $PG_DATA/base/xx/1234 (1234 is the oid of table xxx)
A
On Wednesday 29 October 2008 21:56:14 Kevin Duffy wrote:
>
> Gentlemen:
>
> Thanks so much for your assistance.
>
> This returns 512 rows.
> select * from tmp_index_member tim
> where tim.ISIN NOT IN
> (select ISIN from security sec
> where ISIN is NOT NULL and
>securitytype
Gentlemen:
Thanks so much for your assistance.
This returns 512 rows.
select * from tmp_index_member tim
where tim.ISIN NOT IN
(select ISIN from security sec
where ISIN is NOT NULL and
securitytypekey IS NOT NULL and securitytypekey NOT IN ( 5,27) )
Can someone explain why
On Wednesday 29 October 2008 18:39:42 Kevin Duffy wrote:
> Hello:
>
>
>
> I have a couple of queries that are giving me headaches.
>
> They are actually very simple, but I do not understand why
>
> I am not getting the expected results. Maybe I need new glasses.
>
> Please be kind.
>
>
Hello:
I have a couple of queries that are giving me headaches.
They are actually very simple, but I do not understand why
I am not getting the expected results. Maybe I need new glasses.
Please be kind.
The table definitions are below.
The table TMP_INDEX_MEMBER contains 21057 row
Here's one solution:
create temp sequence tsec;
create temp table ttab as select nextval('tsec'), * from (select * from
events where event_type='a' order by timestamp desc) as troz;
select ttab.*, ttab2.timestamp-ttab.timestamp from ttab join ttab as ttab2
on ttab2.nextval = ttab.nextval+1;
This
I'm relatively new to SQL, and am frequently running into the same problem,
How do I compare different rows in a result?
for example:
If I have a table of events consisting of a time stamp and the event type:
timestamp, event_type
12:00 a
12:10 b
12:20
13 matches
Mail list logo
