Marko Kreen wrote:
On 5/28/06, Martijn van Oosterhout kleptog@svana.org wrote:
With -lpthread
lock.enabled 323s
lock.disabled 50s
lock.unlocked 36s
I forgot to test with -lpthread, my bad. Indeed by default
something less expensive that full locking is going on.
The crux of the
On Sat, May 27, 2006 at 11:52:40AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
How about the suggestion of using a sequential index scan like the
recent changes to VACUUM in the case that there are no regular index
quals?
Nonstarter (hint: the solution we
On Sun, May 28, 2006 at 09:12:34PM -0400, Tom Lane wrote:
But we're still avoiding the central issue: does it make sense to dump a
probin clause at all for plpython functions? If it's a compiled form of
prosrc then it probably doesn't belong in the dump.
That's why I initially thought pg_dump
While I don't think that making WITH a fully reserved word would
cause
any great damage, I'm unwilling to do it just to save a couple of
lines
of code.
I think we should go on and do promote WITH to a reserved keyword now
Oracle, MS-SQL, DB2, MySQL and Informix also have WITH reserved,
Hi,
Below is the
notesfrompostgresql-8.1.3/src/backend/storage/lmgr/README:
Lock acquisition (routines LockAcquire and ProcSleep) follows
these rules:
1. A lock request is granted immediately if it does not
conflict withany existing or waiting lock request, or if the process
Hannu Krosing wrote:
?hel kenal p?eval, P, 2006-05-28 kell 13:53, kirjutas Alvaro Herrera:
Hi,
I've been having the COPY FROM patch that was posted on pgsql-patches
some time ago (I think from Hannu Krossing),
Not by/from me :)
Patch was from Karel Zak:
ipig wrote:
Hi,
Below is the notes from postgresql-8.1.3/src/backend/storage/lmgr/README:
Lock acquisition (routines LockAcquire and ProcSleep) follows these rules:
1. A lock request is granted immediately if it does not conflict with
any existing or waiting lock request, or if the
PFC [EMAIL PROTECTED] writes:
If it were really expensive to derive bytecode from source text
then maybe it'd make sense to do what you're doing, but surely that's
not all that expensive. Everyone else manages to parse prosrc on the
fly and cache the result in memory; why isn't plpython doing
Alvaro Herrera [EMAIL PROTECTED] writes:
I've been taking a look at what's needed for the non-transactional part
of pg_class. If I've understood this correctly, we need a separate
catalog, which I've dubbed pg_ntclass (better ideas welcome), and a new
pointer in RelationData to hold a pointer
Hi,
Thanks for your reply.
I changed the format to plain text.
For the question, suppose that process p0 held the lock of object A, and
the wait queue for A is p1,p2,p3,, that process p1 is the first waiter in
the queue.
Since p1 is in the wait queue, the lock p1 requests
I have been experimenting with the exploit described in
http://www.postgresql.org/docs/techdocs.50 to see if our databases
are affected.
Server is 8.1.3, database encoding UTF8.
Client is a C program compiled and linked against libpq version 8.1.3
that uses UTF8 encoding.
I sent the following
ipig wrote:
Hi,
Thanks for your reply.
I changed the format to plain text.
For the question, suppose that process p0 held the lock of object A, and
the wait queue for A is p1,p2,p3,, that process p1 is the first waiter in
the queue.
Since p1 is in the wait queue, the
Alvaro Herrera wrote:
ipig wrote:
Hi,
Thanks for your reply.
I changed the format to plain text.
For the question, suppose that process p0 held the lock of object A,
and the wait queue for A is p1,p2,p3,, that process p1 is the first
waiter in the queue.
Hi,
an exception: if the process already holds locks on this same lockable
object that conflict with the request of any pending waiter, then the
process will be inserted in the wait queue just ahead of the first such
waiter.
From the exception, I got that the process must be added at the
ipig [EMAIL PROTECTED] writes:
That is to say, if p0 wants to lock A again, then p0 will be put before
p1, and p0 will be at the head of the queue. Why do we need to find the first
waiter which conflicts p0? I think that p0 must be added at the head of the
wait queue.
Your analysis is
Albe Laurenz [EMAIL PROTECTED] writes:
It seems to me that UTF-8 databases are safe.
IIRC we determined that using UTF8 *on both the client and server sides*
is safe. You can get burnt with combinations such as server_encoding =
UTF8 and client_encoding = SJIS (exposing PQescapeString's
Hi,
In your example, it seems that process B is the first such waiter( the
request of B conflicts AccessShareLock).
Best regards.
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: ipig [EMAIL PROTECTED]
Cc: Bruce Momjian pgman@candle.pha.pa.us;
ipig [EMAIL PROTECTED] writes:
In your example, it seems that process B is the first such waiter( the
request of B conflicts AccessShareLock).
No. Better go study
http://developer.postgresql.org/docs/postgres/explicit-locking.html#LOCKING-TABLES
After looking at the example again,
Hi everyone,
Having browsed the TODO list, one of the items that I would be interested
on working on is a debugger for stored procedures. Having searched on this
topic in the archives, I'm still short of some answers that would allow me
to come up with a complete proposal that I can use to start
Mark Cave-Ayland [EMAIL PROTECTED] writes:
The most important question to answer in my mind is how should the
debugger communicate with the server?
1) Use the existing FE/BE protocol to allow the user to control
the debugging session using stored procedures/pseudo-tables, e.g.
On Sun, 28 May 2006, Magnus Hagander wrote:
AFAICS, this is caused by the machine attempting to relay thousands and
thousands of spam emails (some quick checked showed a rate of about 1
spam / 5 seconds enytering the queue - and I know I deleted almost
20,000 from the queue)
And how exactly
AFAICS, this is caused by the machine attempting to relay thousands
and thousands of spam emails (some quick checked showed a rate of
about 1 spam / 5 seconds enytering the queue - and I know I deleted
almost 20,000 from the queue)
And how exactly would you like me to fix *that*?
On Mon, 29 May 2006, Magnus Hagander wrote:
The quick fix is, as I wrote in one of my earlier mails, to configure
svr1 not to tell svr4 to *retry delivery*, but to just junk the mail
right away. It'll still cause joe-job style problems, but it won't load
up the queue for days.
But, from my
The quick fix is, as I wrote in one of my earlier mails, to
configure
svr1 not to tell svr4 to *retry delivery*, but to just junk
the mail
right away. It'll still cause joe-job style problems, but it won't
load up the queue for days.
But, from my look at the queue on svr4, this is
On Mon, 29 May 2006, Magnus Hagander wrote:
The quick fix is, as I wrote in one of my earlier mails, to
configure
svr1 not to tell svr4 to *retry delivery*, but to just junk
the mail
right away. It'll still cause joe-job style problems, but it won't
load up the queue for days.
But, from
Tom Lane wrote:
Mark Cave-Ayland [EMAIL PROTECTED] writes:
... So basically yeah, what we need
is a debug subchannel in the FE/BE protocol. I'd suggest inventing
a single Debug message type (sendable in both directions) with the
contents being specified by a separate protocol definition. Or
The quick fix is, as I wrote in one of my earlier mails, to
configure
svr1 not to tell svr4 to *retry delivery*, but to just junk
the mail
right away. It'll still cause joe-job style problems, but
it won't
load up the queue for days.
But, from my look at the queue on svr4, this
On Mon, May 29, 2006 at 03:00:44PM -0300, Marc G. Fournier wrote:
Run something like:
mailq | grep Recipient address rejected
I thought that the above was supposed to be a perm error, not temp? Does
anyone know what I need to set in postfix on svr1 to change it to a perm?
Do you have
Run something like:
mailq | grep Recipient address rejected
I thought that the above was supposed to be a perm error,
not temp?
Does anyone know what I need to set in postfix on svr1 to
change it to
a perm?
Yes, htat's what I sent before :-)
c) Change svr1 parameters
Thomas Hallgren [EMAIL PROTECTED] writes:
I think this is a bad idea. PL/Java will use either shared memory or a
socket to attach and as you already mentioned, when using C, a gdb
will attach directly using the pid. I wouldn't be too surprised if
Perl, Python, and PHP all have a similar
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
I think this is a bad idea. PL/Java will use either shared memory or a
socket to attach and as you already mentioned, when using C, a gdb
will attach directly using the pid. I wouldn't be too surprised if
Perl, Python, and PHP all have a
Hi,
I am trying to compile libpq with vc8. I got errors in wchar.c
..\..\backend\utils\mb\wchar.c(99) : error C2054: expected '(' to follow
'inline'
..\..\backend\utils\mb\wchar.c(100) : error C2085: 'pg_euc_mblen' : not
in formal parameter list
..\..\backend\utils\mb\wchar.c(100) : error
Yes, I have a patch in the queue to fix it. Should be applied soon.
---
Yannick wrote:
Hi,
I am trying to compile libpq with vc8. I got errors in wchar.c
..\..\backend\utils\mb\wchar.c(99) : error C2054: expected
Is it just me or are the send/recv strangely asymmetric?
It seems like the recv function is designed to avoid copying so the type can
pick the data straight out of the data stream without passing through
intermediate representations.
But the send function forces the type to copy the data into a
Thomas Hallgren wrote:
Ideally, all pl's should use the same protocol. It should be language
agnostic and allow different regions of the code to origin from
different languages. That way, it would be possible to single step a
plpgsql function that in turn calls a function in pljava.
Le 28 mai 06 à 17:42, Tom Lane a écrit :
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
Tom Lane wrote:
Perhaps the swap space or ulimit setting on the box needs to be
raised?
What kind of ulimit did you think of ?
I'll try upping the data segment size.
Yeah, data segment size
Is there a TODO here?
---
Tom Lane wrote:
PFC [EMAIL PROTECTED] writes:
If it were really expensive to derive bytecode from source text
then maybe it'd make sense to do what you're doing, but surely that's
not all
Hm, thinking again, I guess Tom Lane is right
Surely the initialization code would have to be run anyway ... and if
the function does import a pile of modules, do you really want to cache
all that in its pg_proc entry? What happens if some of the modules get
updated later?
Besides,
Marko Kreen wrote:
On 5/28/06, Martijn van Oosterhout kleptog@svana.org wrote:
With -lpthread
lock.enabled 323s
lock.disabled 50s
lock.unlocked 36s
I forgot to test with -lpthread, my bad. Indeed by default
something less expensive that full locking is going on.
The
Is this a TODO?
---
Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
BTW, we're going to be testing this patch on Sun Niagara servers. What's
the outstanding bug with it? I don't quite follow.
It's not
A month ago, pg_resetxlog got an -f flag:
-fforce reset xlog to be done, if the control
file is corrupted, then try to restore it.
However, the patch had identifiable problems that are still not fixed:
Greg Stark [EMAIL PROTECTED] writes:
Is it just me or are the send/recv strangely asymmetric?
Not all that much: they both return a meaningful result. We cheated a
little bit by allowing the recv functions to modify the state of their
input argument, but they still deliver a valid result
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Sun, Apr 30, 2006 at 12:34:42PM -0400, Tom Lane wrote:
2. Run setRuleCheckAsUser during rule load rather than rule store.
#2 is a lot simpler, and would fix the problem for existing broken rules
whereas #1 would not, so I'm
Bruce Momjian pgman@candle.pha.pa.us writes:
Has this been completed?
No, still on the to-do list. IIRC that was about the time we got
diverted by fixing the encoding security issues...
regards, tom lane
---(end of
Tom Lane [EMAIL PROTECTED] writes:
Stark [EMAIL PROTECTED] writes:
Is it just me or are the send/recv strangely asymmetric?
Not all that much: they both return a meaningful result. We cheated a
little bit by allowing the recv functions to modify the state of their
input argument, but
Greg Stark [EMAIL PROTECTED] writes:
both return something seems like an odd axis to measure.
In one case it's given pointer to the entire message, picks out the piece it's
interested in and advances the cursor.
This is just a trivial optimization compared to being handed a bytea
input, which
46 matches
Mail list logo
