"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 9/6/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
>> Ah, as I understand it you can't actually do the pruning then because the
>> executor holds references to source tuple on the page. In other words you
>> can never "get the vacuum lock" there be
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. Othe
"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
"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
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
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='exclus
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.
Hm
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
> >
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 pu
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
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 me
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 transactio
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 modifica
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 = '
[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
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
"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 c
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 shoul
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
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
"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 w
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, u
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:
> 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 quick&dirty
debugging functions I had in the same source tree.
>
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.
Some
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
cas
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?
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
> mul
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 we
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 re
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 P
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
32 matches
Mail list logo
