Could someone explain to me what I'm missing here. Given the following 3
queries:
mqsql01.automation select count(asp_id) from asps where asp_id9 and
asp_id not in (select asp_id from dasp where asp_id1);
count
---
84
(1 row)
mqsql01.automation select count(asp_id) from asps
Alan Nilsson anils...@apple.com writes:
Could someone explain to me what I'm missing here.
Probably there are some NULLs in dasp.asp_id. NOT IN cannot succeed
when there are any nulls in the sub-select result: per SQL spec, the
outcome of such a test can only be FALSE or NULL. If that isn't
that was indeed the case. Did not think to look at that, thanks much for the
kick :)
alan
On May 7, 2013, at 7:30 PM, Tom Lane wrote:
Alan Nilsson anils...@apple.com writes:
Could someone explain to me what I'm missing here.
Probably there are some NULLs in dasp.asp_id. NOT IN cannot
Thanks for the explanation.
On Mon, May 6, 2013 at 8:43 PM, Jasen Betts ja...@xnet.co.nz wrote:
On 2013-05-06, Tim Uckun timuc...@gmail.com wrote:
--047d7b2e4ea07402b004dc034a3b
Content-Type: text/plain; charset=UTF-8
Say I have a select like this.
SELECT * FROM table where field
Hi, Davis.
I guess that the database was restarted by [pg_ctl restart -m fast] but
there was a continuous request from remote servers.
(1)
Does this prove or strongly indicate that somebody did a [pg_ctl_restart]
?
Yes. It seems that someone did [pg_ctl restart -m fast].
When the option
On 05/05/13 15:06, Tom Lane wrote:
Steve Rogerson steve...@yewtc.demon.co.uk writes:
I'm seeing a problem with the query planner not doing what's expected, and I
think it is because we are using composite fields. Here is a stripped down
example.
I tested this example in HEAD and 9.0.x and
I am running python scripts to read tag-formated files and put the data
into tables.
Sometimes a script (I am running several of them in parallel on a server)
just hangs. That happened now again and when I checked I saw this:
SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
Johann Spies wrote:
I am running python scripts to read tag-formated files and put the data into
tables.
Sometimes a script (I am running several of them in parallel on a server)
just hangs. That happened
now again and when I checked I saw this:
SELECT
Postgres 9.2 was happily replicating until I upgraded the server from CentOS
6.3 to 6.4. Log error shows
2013-05-06 23:51:35 EDT [19421]: [206-1] user=,db=,remote= LOG: archive
command failed with exit code 14
2013-05-06 23:51:35 EDT [19421]: [207-1] user=,db=,remote= DETAIL: The failed
John DeSoi de...@pgedit.com writes:
Foiled again by SELinux permissions:
type=AVC msg=audit(1367932037.676:10325): avc: denied { search } for
pid=2567 comm=rsync name=pgsql dev=dm-0 ino=664822
scontext=unconfined_u:system_r:rsync_t:s0
tcontext=system_u:object_r:postgresql_db_t:s0
log_line_prefix = '%m %a %u %c %v %x '
# %m Time stamp with milliseconds
# %a Application name
# %u User name
# %c emits a quasi-unique Session ID,
# consisting of two 4-byte hexadecimal numbers (without leading zeros)
separated by a dot.
# The numbers are the Process
11 matches
Mail list logo
