The attached patch fixes the following warnings in src/backend/libpq
auth.c:496: warning: passing argument 2 of 'gss_release_cred' from
incompatible pointer type
pqcomm.c:182: warning: passing argument 2 of 'gss_delete_sec_context' from
incompatible pointer type
pqcomm.c:185: warning: passing
Florian G. Pflug wrote:
1) 2PC was broken in V3. I added code that skips
LOCKTYPE_VIRTUALTRANSACTION
locks when writing the locks to the 2PC state file, but I didn't
add the same exception to the code that reassigns the locks to
a dummy PGROC afterwards. So the locks weren't released at
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Here is an updated patch, following the discussion.
The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
I've been working through this, and found a couple items that seem like
judgment calls:
* Is there a good
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
1) 2PC was broken in V3. I added code that skips
LOCKTYPE_VIRTUALTRANSACTION
locks when writing the locks to the 2PC state file, but I didn't
add the same exception to the code that reassigns the locks to
a dummy PGROC afterwards. So the locks
I wrote:
I have a few more things in mind I'm planning to look into:
- I'm not convinced that there's enough sanity checking in the input
functions. I think you can send queries into the server using the binary
protocol that you couldn't produce otherwise. For example, queries with
multiple
Kris Jurka [EMAIL PROTECTED] writes:
Parts of the GSS API want the object while others want pointers to the
object and it looks like this code got it backwards. I haven't tested
these changes, but they look right to me.
Wouldn't the code fail entirely if it was wrong in that way?
Heikki, I see some strange changes in your patch, not related to tsearch at all:
contrib/pageinspect/pageinspect.sql.in
contrib/pageinspect/rawpage.c
The usage of the QueryItem struct was very confusing. It was used for
both operators and operands. For operators, val was a single character
I fixed this by making the left-field a uint32. There's no reason to
arbitrarily limit it to 16-bits, and it won't increase the disk/memory
footprint either now that QueryOperator and QueryOperand are separate
structs.
...
I added check_stack_depth() call to all recursive functions I found.
Teodor Sigaev wrote:
Heikki, I see some strange changes in your patch, not related to tsearch
at all:
contrib/pageinspect/pageinspect.sql.in
contrib/pageinspect/rawpage.c
Oh, sorry about that. Just ignore them, they are some quickdirty
debugging functions I had in the same source tree.
The
Ok. Probably easiest to do that by changing the palloc to palloc0 in
parse_tsquery.
and change sizeof to sizeof(QueryItem)
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
Teodor Sigaev wrote:
Ok. Probably easiest to do that by changing the palloc to palloc0 in
parse_tsquery.
and change sizeof to sizeof(QueryItem)
Do you mean the sizeofs in the memcpys in parse_tsquery? You can't
change them. The source structs are allocated in
pushOperand/pushOperator, using
Florian G. Pflug [EMAIL PROTECTED] writes:
However, none of these are very strong reasons - certainly weaker than
doing what ensures to cause the least confusion. I'm therefore
starting to think that we should remove transaction, and keep the name
virtualtransaction for the VXID. That will
On Wed, 5 Sep 2007, Tom Lane wrote:
Kris Jurka [EMAIL PROTECTED] writes:
Parts of the GSS API want the object while others want pointers to the
object and it looks like this code got it backwards. I haven't tested
these changes, but they look right to me.
Wouldn't the code fail entirely
Heikki Linnakangas wrote:
Teodor Sigaev wrote:
Ok. Probably easiest to do that by changing the palloc to palloc0 in
parse_tsquery.
and change sizeof to sizeof(QueryItem)
Do you mean the sizeofs in the memcpys in parse_tsquery? You can't
Oops, I meant pallocs in push* function. palloc0 in
Pavan Deolasee wrote:
together. In the SELECT path, we conditionally try for exclusive lock. If
the exclusive lock is also cleanup lock, we prune and defrag the page.
As the patch stands, during index fetch we try to prune only the chain
originating at that tuple. I am wondering if we should
Florian G. Pflug [EMAIL PROTECTED] writes:
Here is an updated patch, following the discussion.
The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
(I seems I still can't get attachments through to this list)
Applied with revisions --- mostly cosmetic, but there were a couple
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Here is an updated patch, following the discussion.
The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
(I seems I still can't get attachments through to this list)
Applied with revisions --- mostly cosmetic, but
[EMAIL PROTECTED] (Florian G. Pflug) writes:
Chris Browne wrote:
Similarly, does it seem likely that Slony-I users would need to worry
about this?
No.. it should have zero negative effects for Slony-I. In fact, it will
be an advantage in some cases I think. I remember something about
Magnus Hagander wrote:
Andrew Dunstan wrote:
I would like to add an argument to pg_regress that allows us to set some
config options for the temp install. Specifically right now I am
interested in setting the following:
log_line_prefix = '[%c] '
log_statement = 'all'
log_connections =
Bruce Momjian [EMAIL PROTECTED] writes:
I am thinking we are best just doing the index chain we already have to
read.
If you are modifying the table (like with UPDATE) it makes sense to be
more aggressive and do the whole page because you know there are
probably other table modifications,
On Wednesday 05 September 2007 12:56, Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
However, none of these are very strong reasons - certainly weaker than
doing what ensures to cause the least confusion. I'm therefore
starting to think that we should remove transaction, and
Robert Treat [EMAIL PROTECTED] writes:
ISTM that by removing the transaction column, there is no way to see the XID
for relations thats have been updated (which by definition will have locks on
them). Am I mis-reading the docs, or have we lost that functionality?
Huh? What do you mean
Robert Treat wrote:
On Wednesday 05 September 2007 12:56, Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
However, none of these are very strong reasons - certainly weaker than
doing what ensures to cause the least confusion. I'm therefore
starting to think that we should remove
Florian G. Pflug wrote:
So, in essence, you get the old pg_locks format back by doing
select l1.*, l2.transactionid as transaction from pg_locks l1,
pg_locks l2
where l1.vxid = l2.vxid and l2.locktype = 'transaction'
and l2.mode='exclusive' and l2.granted=true.
Hm.. Maybe we should put
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am thinking we are best just doing the index chain we already have to
read.
If you are modifying the table (like with UPDATE) it makes sense to be
more aggressive and do the whole page because you know there are
probably
Andrew Dunstan wrote:
Florian G. Pflug wrote:
So, in essence, you get the old pg_locks format back by doing
select l1.*, l2.transactionid as transaction from pg_locks l1,
pg_locks l2
where l1.vxid = l2.vxid and l2.locktype = 'transaction'
and l2.mode='exclusive' and l2.granted=true.
Andrew Dunstan [EMAIL PROTECTED] writes:
Florian G. Pflug wrote:
So, in essence, you get the old pg_locks format back by doing
select l1.*, l2.transactionid as transaction from pg_locks l1,
pg_locks l2
where l1.vxid = l2.vxid and l2.locktype = 'transaction'
and l2.mode='exclusive' and
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Uh, why would any of this code at all execute during a pure lookup?
No idea. It seems an index lookup tries to prune a heap chain, and he
was asking if it should look at other chains on the page; I said not.
Whether the index lookup
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am thinking we are best just doing the index chain we already have to
read.
If you are modifying the table (like with UPDATE) it makes sense to be
more aggressive and do the whole page
Tom Lane [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Uh, why would any of this code at all execute during a pure lookup?
No idea. It seems an index lookup tries to prune a heap chain, and he
was asking if it should look at other chains on the page; I
On 9/6/07, Gregory Stark [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
ISTM the only time we should be doing HOT cleanup work is when we are
trying to insert a new tuple on that page --- and maybe even only when
we try and it doesn't fit straight off. Otherwise you're
31 matches
Mail list logo
