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,
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 argumen
Bruce Momjian 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 broadcast)---
TIP 2: Don't '
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
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 obje
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:
http://archives.postgresql.org/pgsql-hackers/2006-05/msg
Is this a TODO?
---
Tom Lane wrote:
> Josh Berkus 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 acceptable as-
Marko Kreen wrote:
> On 5/28/06, Martijn van Oosterhout 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
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,
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
> >>
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
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. Incidental
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
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: expec
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 C21
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
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 s
> > > 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) Chan
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 y
> >>> 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
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
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 sv
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 l
> > 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 *t
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
"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,
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
"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, co
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" ;
Sent: Monday, May 29, 2006 11:51 PM
"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 nai
"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 analy
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 h
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 qu
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 que
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 que
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 mus
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 po
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 plpyt
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 i
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:
http://can
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 withany existing or waiting lock request, or if the pr
> > 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 res
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_du
44 matches
Mail list logo
