Suresh <[EMAIL PROTECTED]> writes:
> What is the time qualification check ?
HeapTupleSatisfiesVisibility(). See
src/include/utils/tqual.h
src/backend/utils/time/tqual.c
and if none of this is making any sense maybe you need to start here:
http://developer.postgresql.org/pgdocs/postgres/mvcc.html
Hello,
What do the following lines mean :
/* Tuple failed time qual, but maybe caller wants to see it anyway. */
if (keep_buf)
*userbuf = buffer;
else
{
ReleaseBuffer(buffer);
*userbuf = InvalidBuffer;
}
What is th
On Thu, Mar 6, 2008 at 6:35 PM, Bernd Helmle <[EMAIL PROTECTED]> wrote:
> --On Donnerstag, März 06, 2008 17:03:10 -0500 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> >
> > Where are on updatable views?
> >
>
> I really want to have this one ready for 8.4, but i have nothing appliable
> at the mome
On Thu, 6 Mar 2008, Tom Lane wrote:
What about the other idea of just having committers wait for the next
walwriter-cycle flush before reporting commit?
I haven't considered that too much yet; it may very well be superior to
anything I was thinking of. The only point I was trying to make tod
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have an idea for this TODO item:
> > ...
> > When we get the termination signal, why can't we just set a global
> > boolean, do a query cancel, and in the setjmp() code block check the
> > global and exit --- at that stage we know we
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have an idea for this TODO item:
> ...
> When we get the termination signal, why can't we just set a global
> boolean, do a query cancel, and in the setjmp() code block check the
> global and exit --- at that stage we know we have released all locks and
I have an idea for this TODO item:
* Allow administrators to safely terminate individual sessions either
via an SQL function or SIGTERM
Lock table corruption following SIGTERM of an individual backend
has been reported in 8.0. A possible cause was fi
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
>
> > Added to TODO:
> >
> > o Have \d show foreign keys that reference a table's primary key
> >
> > http://archives.postgresql.org/pgsql-hackers/2007-04/msg00424.php
>
> We have a patch for this:
>
> http://ar
Greg Smith <[EMAIL PROTECTED]> writes:
> I actually have a paper design for something that builds a little model
> for how likely it is another commit will be coming soon that essentially
> turns this into something that can be tuned automatically, better than any
> person can do it. No idea if
On Thu, 6 Mar 2008, Bruce Momjian wrote:
Should we remove these now that we have async commit?
#commit_delay = 0 # range 0-10, in
microseconds
#commit_siblings = 5# range 1-1000
They seem unfixable.
commit_delay offers a small but
Bruce Momjian wrote:
> Tom Lane wrote:
> Added to TODO:
>
> o Have \d show foreign keys that reference a table's primary key
>
> http://archives.postgresql.org/pgsql-hackers/2007-04/msg00424.php
We have a patch for this:
http://archives.postgresql.org/pgsql-patches/2008-03/ms
Jim Nasby wrote:
> On Apr 10, 2007, at 9:48 AM, Stephen Frost wrote:
> > Referenced by:
> > "loc_base_clin_loc_base_id_fkey" FOREIGN KEY (loc_base_id) BY
> > wdm_networx.loc_base_clin(loc_base_id)
> > /|
> > \/|\
> >
Tom Lane wrote:
> psql's \d command tells you about outgoing foreign key constraints
> (ie, ones referencing another table from this one). It doesn't tell
> you about incoming ones (ie, ones where another table references this
> one). ISTM it'd be a good idea if it did, as "are there any incoming
--On Donnerstag, März 06, 2008 17:03:10 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Where are on updatable views?
I really want to have this one ready for 8.4, but i have nothing appliable
at the moment. Considering the amount of rework that needs to be done, i
hope i can provide an up
Should we remove these now that we have async commit?
#commit_delay = 0 # range 0-10, in
microseconds
#commit_siblings = 5# range 1-1000
They seem unfixable.
--
Heikki, are you going to submit this for 8.4?
---
Heikki Linnakangas wrote:
> Hi all,
>
> I'd like to see the indexam API changes needed by the bitmap indexam to
> be committed soon. Has anyone looked at the proposed API i
Heikki, are you going to revise this for 8.4?
---
Heikki Linnakangas wrote:
> I've brought the GIT patch up-to-date with CVS head. The latest version
> can be found at http://community.enterprisedb.com/git/
>
> I also rera
Where are on updatable views?
---
Bernd Helmle wrote:
> --On Freitag, September 01, 2006 11:41:16 -0400 Tom Lane
> <[EMAIL PROTECTED]> wrote:
>
> >
> > So in other words, views on serial columns don't work? I don't think
On Mon, Feb 25, 2008 at 04:45:43AM +0100, Florian G. Pflug wrote:
> dblink in 8.3 blocks without any possibility of interrupting it while
> waiting for an answer from the remote server. Here is a strace
> [pid 27607] rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
> [pid 27607] sendto(56, "Q\0\0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 3 Mar 2008 20:40:02 -0500 (EST)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
As a closing note on this from my side. When I ran the restore with 90
connections (as a stress test) it only took 20 minutes longer than the
24 connections.
Joshua D. D
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I'm glad we got away with a single "marked" array. I was afraid we would
> need to consult the unused/redirected/dead arrays separately.
Yeah, I was worried about that too. The fundamental reason why it's
okay seems to be that redirects can only
Tom Lane wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
On Wed, Mar 5, 2008 at 9:29 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
[ thinks some more... ] I guess we could use a flag array dimensioned
MaxHeapTuplesPerPage to mark already-processed tuples, so that you
wouldn't need to search the
Teodor Sigaev wrote:
So - is this a bug, feature, "feature"?
It's definitely a bug:
select count(*), query from queries group by query;
count | query
---+--
3 | 'tender'
4 | 'tender'
4 | 'tender'
(3 rows)
Will fix it soon.
Ah, smashing.
--
Richard Huxton
Ar
Richard Huxton <[EMAIL PROTECTED]> writes:
> => CREATE OR REPLACE FUNCTION func_b() RETURNS SETOF int AS $$
> SELECT id FROM table_a;
> $$ LANGUAGE sql SET search_path = alpha;
> ERROR: relation "table_a" does not exist
Hmmm, I'll bet the validator forgets to apply the parameter modifica
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On Wed, Mar 5, 2008 at 9:29 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> [ thinks some more... ] I guess we could use a flag array dimensioned
>> MaxHeapTuplesPerPage to mark already-processed tuples, so that you
>> wouldn't need to search the existing
Added to TODO:
o Prevent escape string warnings when object names have
backslashes
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00227.php
---
Gregory Stark wrote:
>
> If you hit tab
=> SELECT * FROM util.queries WHERE qid IN (195,248, 257, 332,
401,409,519,557,736,749,869,879,926) ORDER BY qid;
qid |words| query
-+-+--
195 | can & of & tenders | 'tender' (3 clauses)
248 | tender & the & this | 'tender' (3 clauses)
257 | h
Added to TODO:
* Prevent malicious functions from being executed with the permissions
of unsuspecting users
Index functions are safe, so VACUUM and ANALYZE are safe too.
Triggers, CHECK and DEFAULT expressions, and rules are still
vulnerable.
=> SHOW search_path;
search_path
-
beta
(1 row)
=> CREATE OR REPLACE FUNCTION func_b() RETURNS SETOF int AS $$
SELECT id FROM table_a;
$$ LANGUAGE sql SET search_path = alpha;
ERROR: relation "table_a" does not exist
CONTEXT: SQL function "func_b"
=> \d table_a
Did not fi
Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Sun, 20 Jan 2008, Tom Lane wrote:
> >> I think the main problem is the qualifying clause up front in a place
> >> of prominence. Here's a V3 try
>
> > That one looks good to me. These are small details but better to get it
> > righ
> No, it's still on the TODO. Gevik has also been looking a bit
> at it (I think - at least he's indicated that he is), and he
> recently got some new parser code to look at to see if we can
> use to fix it.
>
I have the new parser code. Next week I have some time reserved to look at
it.
--
Further tsquery comparison fun:
=> SELECT q.qid, q.query, count(*) FROM doc.documents d, util.queries q
WHERE d.words @@ q.query AND (q.query::text=$$'tender'$$) GROUP BY
q.qid, q.query ;
qid | query | count
-+--+---
195 | 'tender' | 374
248 | 'tender' | 374
257 | 't
I'm not sure what value a tsquery has if it's composed from stopwords
only, but it doesn't seem to be null or equal to itself.
That strikes me as ... unintuitive, although I'm happy to be re-educated
on this.
I think it's because CompareTSQ (tsquery_op.c, line 142) doesn't have a
case to han
On Wed, Mar 5, 2008 at 9:29 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>
> [ thinks some more... ] I guess we could use a flag array dimensioned
> MaxHeapTuplesPerPage to mark already-processed tuples, so that you
> wouldn't need to search the existing arrays but just index into the flag
> arra
No, it's still on the TODO. Gevik has also been looking a bit at it (I
think - at least he's indicated that he is), and he recently got some nwe
parser code to look at to see if we can use to fix it.
//Magnus
On Wed, Mar 05, 2008 at 10:23:28PM -0500, Bruce Momjian wrote:
>
> Has this been addre
35 matches
Mail list logo
