-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, May 01, 2008 at 11:02:17PM -0300, Ana Carolina Brito de Almeida wrote:
> Hi!
>
> I tried to use GDB with postgresql 8 and I didnt have success.
> Can you help me?
> So, I think that have something wrong (Failed to read a valid object file
[..
Hi!
I tried to use GDB with postgresql 8 and I didnt have success.
Can you help me?
I tried like as I did in postgresql 7.4
I run configure like this: ./configure --prefix=/usr/local/pgsql8
--enable-debug --enable-cassert --enable-depend
After, I run "make", "make install", "initdb"
After this, I
NTFS adjusts winter file times while in daylight savings
The only file times we should ever be interested in are surely epoch
times, which should be unaffected by time zones.
cheers
andrew
epoch, or at least non-timezone adjusted times, is the way every modern
FS stores file times, no on
I wrote:
> Another possible answer is to change the minimum to be just 64K always.
> I'm not certain that it's really sensible to tie the minimum work_mem to
> BLCKSZ --- I don't think we do anything where work_mem is controlling a
> pool of page buffers, do we?
I've committed this change in HEAD.
On Thu, May 01, 2008 at 06:33:07PM +0200, PFC wrote:
> But it's true that preventing multi-statements adds a layer of
> idiot-proofness... a rather thin layer...
As I already said in a previous remark in this thread, I don't really
like partial security solutions.
What the "no multi-state
"Thomas Mueller" <[EMAIL PROTECTED]> writes:
>> 1. Inexpensive to implement
> Disabling literals wouldn't be much harder to implement I believe, but
> I don't know the PostgreSQL internals.
You're ignoring the client-side costs of repairing broken applications.
(If it only broke applications tha
Thomas Mueller wrote:
Disabling literals is still the only way to actually protect from SQL
injection. Except Meredith's libdejector, which is even a bit better
as far as I see, but requires more work from the developer. I don't
count Microsoft LINQ (or Java Quaere) currently because that would
Greg Smith wrote:
On Wed, 30 Apr 2008, KaiGai Kohei wrote:
[1/4] sepostgresql-pgace-8.4devel-3-r739.patch
provides PGACE (PostgreSQL Access Control Extension) framework.
http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch
For those overwhelmed by sheer volum
Hi,
> disallow more than one SQL statement per PQexec.
I agree, it would help.
> 1. Inexpensive to implement
Disabling literals wouldn't be much harder to implement I believe, but
I don't know the PostgreSQL internals.
> 2. Unlikely to break most applications;
That's true.
> 3. Closes off
It's May 1st, which means it's time for our second 8.4 commit fest.
I took a quick look through my inbox and added some pending patches to
http://wiki.postgresql.org/wiki/CommitFest:May
but it's entirely likely there are still some missing from the queue.
Would authors of submitted patches please
Sure, modifying the WHERE clause is still possible, but the attacker is
a lot more limited in what he can do if he can't tack on a whole new
command.
I hacked into a site like that some day to show a guy that you shouldn't
trust magicquotes (especially when you switch hosting providers and
On Thu, 2008-05-01 at 00:26 +0100, Sam Mason wrote:
> On Wed, Apr 30, 2008 at 04:58:52PM +0100, Simon Riggs wrote:
> > That means we probably need to introduce new infrastructure in the tcop
> > or executor modules to handle queries-within-queries. This isn't
> > special-casing MERGE so much as in
On Thu, May 01, 2008 at 11:26:21AM -0400, Tom Lane wrote:
>
> 1. Inexpensive to implement;
> 2. Unlikely to break most applications;
> 3. Closes off a fairly large class of injection attacks.
>
> The cost/benefit ratio looks pretty good (unlike the idea that started
> this thread...)
That's a mu
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Andrew Sullivan" <[EMAIL PROTECTED]> writes:
>> The _principal_ trick with SQL injection is to fool the application
>> into somehow handing a ";" followed by an arbitrary SQL statement.
> They're the principal trick only because they're the most conveni
Andrew Chernow wrote:
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
I am confused about the below results. The backend is in EDT but it
is converting timestamps into EST ... excluding NOW(). Regardless
of the timezone provided, the backend is dishing out EST.
Try a date that
"Andrew Sullivan" <[EMAIL PROTECTED]> writes:
> The _principal_ trick with SQL injection is to fool the application
> into somehow handing a ";" followed by an arbitrary SQL statement.
> There are of course other things one can do, but most of them are
> constrained to abuse of statements your app
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
I am confused about the below results. The backend is in EDT but it is
converting timestamps into EST ... excluding NOW(). Regardless of the
timezone provided, the backend is dishing out EST.
Try a date that's actually during the ED
On Thu, May 01, 2008 at 09:53:41AM -0400, Andrew Chernow wrote:
> I am confused about the below results. The backend is in EDT but it is
> converting timestamps into EST ... excluding NOW(). Regardless of the
> timezone provided, the backend is dishing out EST.
First, this doesn't really belon
Andrew Chernow <[EMAIL PROTECTED]> writes:
> I am confused about the below results. The backend is in EDT but it is
> converting timestamps into EST ... excluding NOW(). Regardless of the
> timezone provided, the backend is dishing out EST.
Try a date that's actually during the EDT part of the
I am confused about the below results. The backend is in EDT but it is
converting timestamps into EST ... excluding NOW(). Regardless of the
timezone provided, the backend is dishing out EST.
[EMAIL PROTECTED] ~]# uname -a
2.6.9-67.0.4.EL #1 Sun Feb 3 06:53:29 EST 2008 i686 athlon i386 GNU/Li
On Wed, Apr 30, 2008 at 05:33:38PM -0400, Tom Lane wrote:
> you're at risk of some clients being secure and some not. I thought
> what we were discussing was a server-side GUC parameter that would
> disallow more than one SQL statement per PQexec.
That was certainly what I was intending, yes.
T
"Greg Smith" <[EMAIL PROTECTED]> writes:
> The approach taken here is to put all the "#ifdef" logic into the underlying
> ACE interface (see patch [2/4]), so that the caller doesn't have to care. If
> SELinux support is off then the calls turns into
>
> void x(y) {} or
> bool a(b) { return tr
22 matches
Mail list logo
