> I need to check the scalability of a machine with postgresql and Im doing it
> with pgbench but Im getting values with a variation of a 40% with the same
> pgbench call...
You might be looking at the effect of the kernel buffer cache. Try run
pgbench several times with same settings. An
On Tue, 26 Jun 2001 17:11:47 -0400 (EDT), you wrote:
>I started thinking about Tom's idea to implement functions as table
>source.
>
>To me, it seems that a very few changes are necessary:
>a) parser must be changed to allow functioncall to be a table_ref
>(easy)
>
>b) when a Query node is genera
I need to check the scalability of a machine with postgresql and Im doing it
with pgbench but Im getting values with a variation of a 40% with the same
pgbench call...
Just the same variation if I restart posgresql or overwrite the db...
So just wondering if theres an
Bruce Momjian <[EMAIL PROTECTED]> writes:
> > My take on the matter is that we shouldn't invest any more effort in
> > crypt-based solutions (here crypt means specifically crypt(3), it's
> > not a generic term). The future is double encryption using MD5 ---
> > or s/MD5/more-modern-hash-algorith
Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> > > > > > For the same reason I don't see any value in the idea of adding
> > > > > > crypt-based double encryption to clients. We don't really want to
> > > > > > support that over the long run, so wh
Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > For the same reason I don't see any value in the idea of adding
> > > > crypt-based double encryption to clients. We don't really want to
> > > > support that over the long run, so why put effort into it?
> > >
> > > The only reason to add doubl
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The only reason to add double-crypt is so we can continue to use
> /etc/passwd entries on systems that use crypt() in /etc/passwd.
In the long run, though, we want to drop crypt(3) usage entirely.
It's just too much of a pain in the neck to depend on th
Jim and Bruce wrote:
> [ a lot of stuff ]
What this discussion seems to come down to is whether we should take a
backward step in one area of security (security against wire-sniffing)
to take a forward step in another (not storing plaintext passwords).
It seems largely a matter of local condition
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> In my understanding the deadlock check is performed every time the
> backend aquires lock. Once the it aquires, it kill the timer. However,
> under heavy transactions such as pgbench generates, chances are that
> the checking fires, and it tries to aquire
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> It appeared that the deadlock checking timer seems to be the source of
> the problem. With the default settings, it checks deadlocks every 1
> second PER backend.
I don't believe it. setitimer with it_interval = 0 should produce one
interrupt, no more.
> Tatsuo Ishii wrote:
> >
> > > > Tatsuo Ishii <[EMAIL PROTECTED]> writes
> > > > >>> How can I check it?
> > > > >>
> > > > >> The 'stuck' message should at least give you a code location...
> > > >
> > > > > FATAL: s_lock(0x2ac2d016) at spin.c:158, stuck spinlock. Aborting.
> > > >
> > > > Hmm,
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes
> > >>> How can I check it?
> > >>
> > >> The 'stuck' message should at least give you a code location...
> >
> > > FATAL: s_lock(0x2ac2d016) at spin.c:158, stuck spinlock. Aborting.
> >
> > Hmm, that's SpinAcquire, so it's one of the predefined spinl
12 matches
Mail list logo
