Re: [HACKERS] Virus Emails
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > I seem to be getting virus emails that pretend to be one of your guys. eg. > I get them from T.Ishii and N.Conway, etc. Anyone out there on the list who > should perhaps scan their computer? :) One of the nastier aspects of the Klez virus is that it searches accessible files and webpages for email addresses. It doesn't just spam all the addresses it can find --- it spams each address with a false "From:" that's a found-nearby address. So mail-list archives are a gold mine for it: it can spam you with a false "From:" that you will probably recognize. However, even a trivial look at the detail mail headers (Received: etc) will convince you that the spam did not originate from the claimed "From:" address. If you care to post a few sets of complete headers, we can probably triangulate pretty quickly on the virus-infected loser who's originating these messages. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Question about LWLockAcquire's use of semaphores instead of spinlocks
"Robert E. Bruccoleri" <[EMAIL PROTECTED]> writes: > On SGI multiprocessor machines, I suspect that a spinlock > implementation of LWLockAcquire would give better performance than > using IPC semaphores. Is there any specific reason that a spinlock > could not be used in this context? Are you confusing LWLockAcquire with TAS spinlocks? If you're saying that we don't have an implementation of TAS for SGI hardware, then feel free to contribute one. If you are wanting to replace LWLocks with spinlocks, then you are sadly mistaken, IMHO. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Virus Emails
Hi guys, I seem to be getting virus emails that pretend to be one of your guys. eg. I get them from T.Ishii and N.Conway, etc. Anyone out there on the list who should perhaps scan their computer? :) Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Question about LWLockAcquire's use of semaphores instead of spinlocks
On SGI multiprocessor machines, I suspect that a spinlock implementation of LWLockAcquire would give better performance than using IPC semaphores. Is there any specific reason that a spinlock could not be used in this context? +-++ | Robert E. Bruccoleri, Ph.D. | email: [EMAIL PROTECTED]| | P.O. Box 314| URL: http://www.congen.com/~bruc | | Pennington, NJ 08534|| +-++ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] regd count(count(*)) in group by
Hi,
We have a query "select count(count(*)) from test group by
trunc(test_date)". This works fine with Oracle but when moving to postgres I
changed it to "select count(count(*)) from test group by date_trunc('day',
test_date)" but I get the following error
ERROR: Aggregate function calls may not be nested
Can some one help me...
Thanks
Yuva
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] regd count(count(*)) in group by
Try this:
SELECT count(*)
FROM (
SELECT count(*)
FROM test
GROUP BY date_trunc('day', test_date)
) as qry;
On Fri, 2002-07-26 at 16:03, Yuva Chandolu wrote:
> Hi,
>
> We have a query "select count(count(*)) from test group by
> trunc(test_date)". This works fine with Oracle but when moving to postgres I
> changed it to "select count(count(*)) from test group by date_trunc('day',
> test_date)" but I get the following error
>
> ERROR: Aggregate function calls may not be nested
>
> Can some one help me...
>
> Thanks
> Yuva
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Password sub-process ...
On Fri, 26 Jul 2002, Jan Wieck wrote: > What would be good is IMHO to have GRANT|REVOKE CONNECT which defaults > to REVOKE, so only superusers and the DB owner can connect, but that the > owner later can change it without the need to edit hba.conf. Oh, yes. Me too please. I think something close to this is coming with schemes - well at least my take on it indicates that. Rod -- "Open Source Software - Sometimes you get more than you paid for..." ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Password sub-process ...
Something to maybe add to the TODO list, if someone has the
time/inclination to work on it ...
The problem with the current auth system, as I see it, is that you can't
easily have seperate user lists and passwords per database ... its shared
across the system ...
The closest you can get is to have a database defined as 'password' in
pg_hba.conf, with an external password file from pg_shadow, which, for the
most part, is good ... but it doesn't lend itself well to a 'hands off'
server ...
Right now, with v7.2, we have two 'sub-processes' that start up for stats
collection ... has anyone thought about adding a 3rd as a password server?
Basically, it would be used to manage the pg_hba.conf file itself *while*
the server is/was live ...
For instance, CREATE DATABASE would need to get extended to have
something like "WITH AUTH '{trust|password|ident}' FROM ''" added to
it, which would add an appropriate line to pg_hba.conf ...
The database owner would have the ability to add users if (and only if)
the database was setup for 'password', and the password daemon would
automatically modify the password file(s) for that database ..
What would be even more cool ... to be able to do something like:
CREATE USER FROM WITH PASSWORD
which, if it didn't exist, would create a line in pg_hba.conf of:
host password
and create a password file with that person in it ...
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Password sub-process ...
On Fri, Jul 26, 2002 at 10:48:53 -0300, "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > > Something to maybe add to the TODO list, if someone has the > time/inclination to work on it ... > > The problem with the current auth system, as I see it, is that you can't > easily have seperate user lists and passwords per database ... its shared > across the system ... If you look at the 7.3 docs you will see that you will be able to restrict access to databases by user or group name. If you use group name and have one group per database you will be able to administer access pretty easily. If you have a lot of databases you can use group names matching database names and not have to touch your conf file when making new databases. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SET LOCAL again
Peter Eisentraut <[EMAIL PROTECTED]> writes: > As an alternative syntax I can suggest > SET name TO value [ ON COMMIT RESET ]; Ugh. Why can't we stick with SET LOCAL? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Password sub-process ...
On Fri, 2002-07-26 at 12:55, Marc G. Fournier wrote: > On Fri, 26 Jul 2002, Tom Lane wrote: > > > Rod Taylor <[EMAIL PROTECTED]> writes: > > > This still doesn't allow john on db1 to be a different user than john on > > > db2. To accomplish that (easily) we still need to install different > > > instances for each database. > > > > Some people think that cross-database user names are a feature, not > > a bug. I cannot see any way to change that without creating huge > > backward-compatibility headaches --- and it's not at all clear to > > me that it's a step forward, anyway. > > > > I think that it might be worth adding a CONNECT privilege at the > > database level; that together with Bruce's recent revisions to > > pg_hba.conf ought to be a pretty good improvement. > Also, I thnk I might have missed the point of the whole CONNECT privilege > thing ... if I have two ppl named joe on the system, each with different > passwords, how does the CONNECT know which one is the one that has access > to that database? Well.. right now we call one db1_joe and db2_joe. I meant adding the ability to lock some users to specific DBs -- and only exist there. Authentication would use destination DB as well as username. Where DB is null, the user is a global user. Usernames would still be unique per database. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Password sub-process ...
"Marc G. Fournier" wrote: > > Something to maybe add to the TODO list, if someone has the > time/inclination to work on it ... > > The problem with the current auth system, as I see it, is that you can't > easily have seperate user lists and passwords per database ... its shared > across the system ... I don't see a problem with that in general. Other databases (like Informix) do it even worse and you need a UNIX or NIS account where the password is held! What would be good is IMHO to have GRANT|REVOKE CONNECT which defaults to REVOKE, so only superusers and the DB owner can connect, but that the owner later can change it without the need to edit hba.conf. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
