Tom Lane wrote:
Bruce Momjian wrote:
OK, makes sense. Could we give them a command to archive it before they
shut down? That would make sense.
Not if the idea is to be certain you got everything ... I think what we
have to do is document a manual procedure for archiving the last XLOG
file.
What B
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> I'm not sure how different it is from vacuum full, though the main idea
> is that instead of locking the table you instead work in smaller pieces
> and don't block anything other than other updates.
We don't have any support for locking sections of a ta
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> I would think it wouldn't be hard to change the protocol/code so that
> the response from providing an invalid user is the same as providing a
> valid one.
How would you do that? The response for a valid user will (a) include
the same salt on repeated
On Wed, Apr 20, 2005 at 08:10:23PM -0400, Paul Tillotson wrote:
> Jim C. Nasby wrote:
>
> >I talked to a few people on IRC about this and they didn't think I was
> >nuts, so maybe this is something practical...
> >
> >In a nutshell, my idea is to use the normal transactional/XID code to
> >relocat
On Thu, Apr 21, 2005 at 12:13:50AM -0400, Tom Lane wrote:
> It's worth pointing out also that adding a per-user-entry random salt
> to the password protocol is not some kind of penalty-free magic bullet.
> In particular it implies information leakage: I can tell from the
> password challenge (or la
On Wed, Apr 20, 2005 at 07:33:54PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > In a nutshell, my idea is to use the normal transactional/XID code to
> > relocate tuples in the heap. Think of doing an UPDATE field=field if you
> > could tell update what page to put the ne
On Wed, Apr 20, 2005 at 09:58:31PM -0400, Stephen Frost wrote:
> * Greg Stark ([EMAIL PROTECTED]) wrote:
> > Stephen Frost <[EMAIL PROTECTED]> writes:
> > > I have some hopes that pointing out the rather large problem with the
> > > md5 authentication mechanism in pg_hba.conf will lead them to disc
Paul Tillotson <[EMAIL PROTECTED]> writes:
> Of course, someone is asking to be 0wn3d if they set up PHPBB to connect
> as superuser. However, given the amount of work done to prevent
> foot-shooting in other areas (e.g., server refuses to run as root), it
> seems inconsistent that using md5 as
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Is this totally rad bitmap index support going in? :D Does it require
> new index types or does it work with existing ones, etc?
Works with the existing ones. It's the same idea that's been discussed
several times, eg
http://archives.postgre
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I guess I was recalling this part of the earlier thread:
> http://archives.postgresql.org/pgsql-hackers/2004-07/msg01088.php
Mmm. The question really is whether PreallocXlogFiles does anything
useful at all anymore. It once would allocate multiple segme
[snip]
The issue pointed out back then was that lots of hosts would have usernames
with the same name, namely "postgres". So a distributed attack would be able
to use a dictionary attack if it were targeting just the "postgres" user on
many hosts.
That was deemed not a threat model worth worrying a
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> [bugtraq removed - I don't think this belongs there, at least at this stage]
Sure.
> /etc/shadow is supposedly only readable by root (or things that are
> setuid root). If you have root you already own the box. Yet we store
> passwords there hashed
Hi Tom,
I hate to slow you down when you're coding, but it'd be cool if you
could explain to me (and other interested parties) what's going on here :)
Is this totally rad bitmap index support going in? :D Does it require
new index types or does it work with existing ones, etc?
Chris
Tom Lane w
* Tom Lane ([EMAIL PROTECTED]) wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Simply put, MD5 is no longer strong enough for protecting secrets. It's
> > just too easy to brute-force. SHA1 is ok for now, but it's days are
> > numbered as well. I think it would be good to alter SHA1 (or som
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > The md5 hash which is generated for and stored in pg_shadow does not
> > use a random salt but instead uses the username which can generally be
> > determined ahead of time (especially for the 'postgres' sup
Chris,
> Well the pg_advisor views in pgfoundry.org are supposed to provide this.
> I'll probably ask Fabien to give me commits on it so i can put stuff
> in that :)
If someone is still working on pg_advisor, suggest that they check out our
work in newsysviews. I think it'll speed things up
* Greg Stark ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > I have some hopes that pointing out the rather large problem with the
> > md5 authentication mechanism in pg_hba.conf will lead them to discourage
> > it's use and thus reduce the occourances of the salt being m
Any further thoughts on this?
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
I presume they have to drop the default, then drop the sequence to get
rid of it.
Hmm. Right at the moment I don't think you *can* get rid of it, short
of dropping the column altogether.
regression=
What other tools do we need? If we're talking an interactive analysis tool
ala pg_suggest, isn't that being worked on as an *add-in*? I don't see
any place for this in the core ...
It is something need, either in core or out. Is it done enough to
remove the item?
Well the pg_advisor vie
Tom Lane wrote:
> Lessee ... we'll include a complete password hash table in a root kit,
> which will be used at a point where we've already managed to read
> pg_shadow but are somehow still lacking the ability to do anything else
> we could want to the database ... nope, not very compelling.
You
Jim C. Nasby wrote:
I talked to a few people on IRC about this and they didn't think I was
nuts, so maybe this is something practical...
In a nutshell, my idea is to use the normal transactional/XID code to
relocate tuples in the heap. Think of doing an UPDATE field=field if you
could tell update w
On Wed, 20 Apr 2005, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > On Wed, 20 Apr 2005, Tom Lane wrote:
> >> What?
>
> > The discussion Simon is refering to came up during the 8.0 beta IIRC. The
> > problem was that we were not allocating xlogs quickly enough under
> > heavy workl
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Wed, 20 Apr 2005, Tom Lane wrote:
>> What?
> The discussion Simon is refering to came up during the 8.0 beta IIRC. The
> problem was that we were not allocating xlogs quickly enough under
> heavy workloads and there was some discussion about the bgwrit
On Wed, 20 Apr 2005, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > 2. PreallocXlogFiles to run from a separate process to make it
> > effective, as discussed last year.
>
> What?
The discussion Simon is refering to came up during the 8.0 beta IIRC. The
problem was that we were not
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> In a nutshell, my idea is to use the normal transactional/XID code to
> relocate tuples in the heap. Think of doing an UPDATE field=field if you
> could tell update what page to put the new tuple on. Using this
> mechanism, you can move tuples from the e
Simon Riggs <[EMAIL PROTECTED]> writes:
> 2. PreallocXlogFiles to run from a separate process to make it
> effective, as discussed last year.
What?
> The most natural place to put it
> would be the Archiver, though that is only present when archive_command
> is set.
If there's any use to this, w
> OK, makes sense. Could we give them a command to archive it before they
> shut down? That would make sense.
Not if the idea is to be certain you got everything ... I think what we
have to do is document a manual procedure for archiving the last XLOG
file.
But really my question is "what's the
Tom Lane wrote:
Bruce Momjian writes:
That's what I told him. I think his concern about pre-computed hashes
is the only real issue, and give 'postgres' is usually the super-user, I
can see someone pre-computing md5 postgres hashes and doing quick
comparisons, perhaps as a root kit so you don'
Bruce Momjian wrote:
>>BTW, one could also ask exactly what threat model Stephen is concerned
>>about. ISTM anyone who can obtain the contents of pg_shadow has
>>*already* broken your database security.
> That's what I told him. I think his concern about pre-computed hashes
> is the only real
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> However, this still begs the question of why we are bothering.
> >> I disagree with the goal in this particular case anyhow: I do not
> >> think it's necessary, safe, nor sane for a shutdown to try to archive
> >> the last XLOG segme
Bruce Momjian writes:
> Tom Lane wrote:
>> However, this still begs the question of why we are bothering.
>> I disagree with the goal in this particular case anyhow: I do not
>> think it's necessary, safe, nor sane for a shutdown to try to archive
>> the last XLOG segment. Even if we fixed the xl
Bruce Momjian writes:
> That's what I told him. I think his concern about pre-computed hashes
> is the only real issue, and give 'postgres' is usually the super-user, I
> can see someone pre-computing md5 postgres hashes and doing quick
> comparisons, perhaps as a root kit so you don't have to do
Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Simply put, MD5 is no longer strong enough for protecting secrets. It's
> > just too easy to brute-force. SHA1 is ok for now, but it's days are
> > numbered as well. I think it would be good to alter SHA1 (or something
> > stronger) a
On Wed, Apr 20, 2005 at 06:03:18PM -0400, Tom Lane wrote:
> Well, I have no particular problem with offering SHA1 as an alternative
> hash method for those who find MD5 too weak ... but I still question the
> value of putting any random salt in the table. AFAICS you would have to
> send that salt
I talked to a few people on IRC about this and they didn't think I was
nuts, so maybe this is something practical...
In a nutshell, my idea is to use the normal transactional/XID code to
relocate tuples in the heap. Think of doing an UPDATE field=field if you
could tell update what page to put the
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Simply put, MD5 is no longer strong enough for protecting secrets. It's
> just too easy to brute-force. SHA1 is ok for now, but it's days are
> numbered as well. I think it would be good to alter SHA1 (or something
> stronger) as an alternative to MD5, a
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Treating shutdown checkpoint markers as xlog switches is possible but
> > gives problems since archive_command is a SUSET variable. On replay we
> > wouldn't necessarily know whether a shutdown checkpoint was treated as
> > an xlog switc
On Wed, 2005-04-20 at 15:51 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > AFAICS this is the only case of unconditionally acquiring all 3 locks.
>
> You just lost me ... I think the above is certainly a bad idea from a
> concurrency standpoint, and very possibly a deadlock r
On Wed, 2005-04-20 at 15:59 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Treating shutdown checkpoint markers as xlog switches is possible but
> > gives problems since archive_command is a SUSET variable. On replay we
> > wouldn't necessarily know whether a shutdown checkpoi
Should any of these be added to TODO?
---
Simon Riggs wrote:
> A range of WAL/PITR items still need work. I'm fairly sure I won't be
> doing any of these in time for 8.1, so feel free to have a go.
>
> 1. PITR archive recov
On Wed, Apr 20, 2005 at 05:03:18PM -0400, Tom Lane wrote:
> > This would allow for the pregeneration of the entire md5
> > keyspace using that 'salt' and then quick breakage of the hash once
> > it's retrieved by the attacker.
>
> Considering the size of the possible keyspace, this is pretty
Stephen Frost <[EMAIL PROTECTED]> writes:
> The md5 hash which is generated for and stored in pg_shadow does not
> use a random salt but instead uses the username which can generally be
> determined ahead of time (especially for the 'postgres' superuser
> account).
So?
The fact that we en
Stephen Frost <[EMAIL PROTECTED]> writes:
> I have some hopes that pointing out the rather large problem with the
> md5 authentication mechanism in pg_hba.conf will lead them to discourage
> it's use and thus reduce the occourances of the salt being made
> available to the user giving more weight
A range of WAL/PITR items still need work. I'm fairly sure I won't be
doing any of these in time for 8.1, so feel free to have a go.
1. PITR archive recovery could do more to overlap recovery of files, so
that recovery overall is faster. This is already possible by designing
your archive command t
Greetings,
There appears to be some deficiencies in both the documentation of the
'md5' authentication methology (in pg_hba.conf) and in the md5 hash
generation which is stored in pg_shadow.
The md5 hash which is generated for and stored in pg_shadow does not
use a random salt but inste
Simon Riggs <[EMAIL PROTECTED]> writes:
> Treating shutdown checkpoint markers as xlog switches is possible but
> gives problems since archive_command is a SUSET variable. On replay we
> wouldn't necessarily know whether a shutdown checkpoint was treated as
> an xlog switch when it was written, so
Simon Riggs <[EMAIL PROTECTED]> writes:
> AFAICS this is the only case of unconditionally acquiring all 3 locks.
You just lost me ... I think the above is certainly a bad idea from a
concurrency standpoint, and very possibly a deadlock risk.
In any case you are thinking about it the wrong way. I
* David F. Skoll ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > The md5 hash which is generated for and stored in pg_shadow does not
> > use a random salt but instead uses the username which can generally be
> > determined ahead of time (especially for the 'postgres' superuser
> > ac
Stephen Frost wrote:
> The md5 hash which is generated for and stored in pg_shadow does not
> use a random salt but instead uses the username which can generally be
> determined ahead of time (especially for the 'postgres' superuser
> account).
I noted that this was a problem back in Augu
Josh Berkus wrote:
> Bruce,
>
> > > Good god - how old was that email? 2002???
> >
> > Yep, and been in my mailbox since then, waiting for me to process it
> > into a TODO entry.
>
> > > > * Add tool to query pg_stat_* tables and report indexes that aren't
> > > > needed or tables that might
Josh Berkus writes:
> Folks,
>
> At OSDL we're seeing a wierd performance crash on 8.1cvs. What's wierd
> about
> it is that it doesn't happen all the time -- about 1 out of 4 test runs.
> What it looks like happens sometimes is that performance drops dramatically
> at the first checkpo
On Wed, Apr 20, 2005 at 11:09:19AM -0700, Josh Berkus wrote:
> At OSDL we're seeing a wierd performance crash on 8.1cvs. What's wierd
> about
> it is that it doesn't happen all the time -- about 1 out of 4 test runs.
> What it looks like happens sometimes is that performance drops dramatic
Folks,
At OSDL we're seeing a wierd performance crash on 8.1cvs. What's wierd about
it is that it doesn't happen all the time -- about 1 out of 4 test runs.
What it looks like happens sometimes is that performance drops dramatically
at the first checkpoint, and never comes back. But there
On Mon, 2005-04-18 at 23:20 +0100, Simon Riggs wrote:
> My plan would be to write a special xlog record for xlog switching. This
> would be a special processing instruction, rather than a data/redo
> instructions. This would be implemented as another xlog info value on
> the xlog_redo resource mana
Bruce,
> > Good god - how old was that email? 2002???
>
> Yep, and been in my mailbox since then, waiting for me to process it
> into a TODO entry.
> > > * Add tool to query pg_stat_* tables and report indexes that
> > > aren't
> > > needed or tables that might need indexes
pg_stat_user_ind
On Wed, 20 Apr 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Is there a reason (other then it hasn't been implemented yet?) that the
following couldn't work?
SELECT id,count(id) AS cnt
FROM table
WHERE id IN ( 1,2,3,4,5)
GROUP BY id
HAVING cnt = 2;
It's contra
On Wed, Apr 20, 2005 at 12:30:08 +0800,
"Ilya A. Kovalenko" <[EMAIL PROTECTED]> wrote:
> GS> I see a use case for of generating addresses based on a sequence or some
> GS> primary key from the database.
>
> GS> Something like
>
> GS> CREATE SEQUENCE hosts_ip_seq MAXVALUE 65536;
> GS> ALTER TABL
I'm a little confused by the conclusions
Josh Berkus wrote:
Bruce,
FYI, I did a presentation on the porting of PostgreSQL to Win32 on
Saturday:
Good thing, too, you're doing this preso for OSCON.
http://candle.pha.pa.us/main/writings/pgsql/win32_port.pdf
It has few diagrams be
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> If not, is this a TODO perhaps?
> Maybe. It's been discussed before IIRC. Doing the referential actions
> might get tricky, and you'd often want to index so that finding the
> individual array elements isn't expensive.
Checking PK deletions efficientl
> -Original Message-
> From: Jim C. Nasby [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 19, 2005 5:56 PM
> To: Christopher Browne
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] argtype_inherit() is dead code
>
> [...]
> On Sun, Apr 17, 2005 at 07:01:41PM -0400, Christopher
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Is there a reason (other then it hasn't been implemented yet?) that the
> following couldn't work?
>SELECT id,count(id) AS cnt
> FROM table
> WHERE id IN ( 1,2,3,4,5)
> GROUP BY id
>HAVING cnt = 2;
It's contrary to the SQL spec, f
On Wed, 20 Apr 2005, Christopher Kings-Lynne wrote:
> Hi,
>
> Can you put a foreign key constraint on an array column that says that
> each element of the array must match a primary key?
Not currently, because foreign keys are between directly comparable
things.
> If not, is this a TODO perhaps?
Is there a reason (other then it hasn't been implemented yet?) that the
following couldn't work?
SELECT id,count(id) AS cnt
FROM table
WHERE id IN ( 1,2,3,4,5)
GROUP BY id
HAVING cnt = 2;
instead of:
SELECT id,count(id) AS cnt
FROM table
WHERE id IN ( 1,2,3,4,5)
GROUP BY id
On Wed, 2005-04-20 at 09:28 +0200, Klaus Naumann wrote:
>
> > Actually, me too. Never saw the need for the Oracle command myself.
>
> It actually has. If you want to move your redo logs to a new disk, you
> create a new redo log file and then issue a ALTER SYSTEM SWITCH LOGFILE;
> to switch to th
It is also recommended when creating new standby control files, when
Oracle can't
automatically expand the data file capacity on a standby like it does
with
a live database. Nothing like seeing the 'Didn't restore from
sufficiently old
backup' message when Oracle is confused (which seems to
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
Good god - how old was that email? 2002???
Yep, and been in my mailbox since then, waiting for me to process it
into a TODO entry.
Exciting what one can find wiping the floor of the mailbox :-)
Regards,
Andreas
---(end of
> Hi,
>
> Can you put a foreign key constraint on an array column that says that
> each element of the array must match a primary key?
>
> If not, is this a TODO perhaps?
>
> Chris
>
Hello,
Using array values for foreign key is very special. I not sure, so all
people need it. More interest
Hi Simon,
Actually, me too. Never saw the need for the Oracle command myself.
It actually has. If you want to move your redo logs to a new disk, you
create a new redo log file and then issue a ALTER SYSTEM SWITCH LOGFILE;
to switch to the new logfile. Then you can remove the "old" one
(speaking jus
68 matches
Mail list logo
