2010/1/8 Kevin Grittner :
> Nicolas Barbier wrote:
>
>> I assume here that PG's non-SI-compatible behavior of not always
>> rollbacking any transaction that writes to a non-last version will
>> be disabled in serializable mode.
>
> Can that currently happen
2010/1/8 Markus Wanner :
> SIREAD atop predicate locking serves detecting vulnerable edges (I hope
> I'm using that term correctly here) between newly inserted tuples and
> reads, right? I was trying to figure if it would make sense to use
> predicate locking (instead of table or row level locking
2010/1/7 Albe Laurenz :
> Nicolas Barbier wrote:
>
>> In such a pure implementation of predicate locking, the overlap
>> testing is be done using the algebraic properties of the conditions,
>> which is of course extremely difficult (if not impossible) to
>> implem
2010/1/7 Albe Laurenz :
> I don't know if such a thing would be easy to implement in
> PostgreSQL, but I had thought that the "standard" approach to
> implement predicate locking is like this:
>
> Whenever you touch (read) a data structure, you tag it with a lock
> that prevents anybody else from
2010/1/7 Markus Wanner :
> (It's interesting that with "database page" level granularity, he states
> that predicate locking would not be necessary. Instead any page can be
> locked at any time. For this to work, according to my reasoning, you'd
> have to know in advance on which page potentially
2009/12/31 Sergej Galkin :
> typedef struct moving_object
> {
> double x_high;
> double y_high;
> double x_low;
> double y_low;
> time_t mov_time;
> double x_plus;
> double y_plus;
> double x_minus;
> double y_minus;
> } moving_object;
[..]
> #define DatumGetM
[ Reviving this old thread because a recent one referred to it. ]
2009/5/7 Albe Laurenz :
> Kevin Grittner wrote:
>
>> > maybe I misunderstood something.
>> >
>> > Consider a function
>> > "makehighlander(personid integer) RETURNS void"
>> > defined like this:
>> >
>> > SELECT ishighlander INT
2009/12/31 Bruce Momjian :
> I must be missing something but I thought the only problem with our
> existing snapshot system was that you could see a row updated after your
> snapshot was created, and that the solution to that was to abort the
> transaction that would see the new row. Can you tell
2009/12/18 Florian Weimer :
> * Florian Pflug:
>
>> On 16.12.09 16:40 , Kevin Grittner wrote:
>>
>>> Nicolas Barbier wrote:
>>>
>>>> I am not sure whether the serialization failures that it may cause
>>>> are dependent on the p
[ Forgot the list, resending. ]
2009/12/16 Boszormenyi Zoltan :
> Robert Haas írta:
>
>> On Wed, Dec 16, 2009 at 1:25 PM, Robert Haas wrote:
>>
>>> On Wed, Dec 16, 2009 at 1:14 PM, Alvaro Herrera
>>> wrote:
>>>
So you'd have to disable HOT updates when true serializability was
active?
2009/12/16 Albe Laurenz :
> Quote:
> The problem [of phantom reads] was identified in (Eswaran et al., 1976),
> but the general purpose "predicate locking" solution suggested there
> has not been widely adopted because of the difficulty in testing mutual
> satisfiability of predicates.
>
>
2009/12/15 Tom Lane :
> to...@tuxteam.de writes:
>
>> (and as Andrew Dunstan pointed out off-list: I was wrong with my bold
>> assertion that one can squeeze infinitely many (arbitrary length)
>> strings between two given. This is not always the case).
>
> Really? If the string length is unbounde
2009/9/15 Michael Meskes :
> Looking at
> http://zlew.org/postgresql_static_check/scan-build-2009-09-14-1/report-3LPmKK.html#EndPath
> it tells me that the value stored to 'counter' is never used. However, the
> "counter++" is called inside a loop and thus will be read the next time the
> loop is
2009/8/23 Magnus Hagander :
> For another data point, Microsoft documentation says:
> "This POSIX function is deprecated beginning in Visual C++ 2005. Use
> the ISO C++ conformant _hypot instead."
>
> _hypot() has been there since Windows 95, so it shouldn't be a problem
> to use it - it just nee
2009/6/7 Markus Wanner :
> However, there's no special whitespace treatment. Nor anything remotely
> as clever as "nearby variable renaming". There's no such magic, the
> developer still needs to tell the tool what he wants.
If I understand correctly, "nearby variable renaming" refers to
changes
data from the view instead of from the main table, then we
> don't need this feature at the moment. Otherwise: Could anyone
> explain?
That is exactly what it means.
Nicolas
--
Nicolas Barbier
http://www.gnu.org/philosophy/no-word-attachments.html
--
Sent via pgsql-hackers mailing list
uot;thesaurus"
* "with parser" -> add "the" before "parser"
* "but we can use plainto_tsquery and to_tsvector functions" -> add
"the" before the name of the first function, or remove the "functions"
part
* "not a lexemes" ->
ia.org/wiki/GLSL>
There are (of course) competing "standards" such as:
http://en.wikipedia.org/wiki/High_Level_Shader_Language>
and:
http://en.wikipedia.org/wiki/Cg_%28programming_language%29>.
greetings,
Nicolas
--
Nicolas Barbier
http://www.gnu.org/
cess can be done recursively (implementation doesn't have to
be recursive, of course), to eliminate whole sub-trees of the join
tree.
Nicolas
--
Nicolas Barbier
http://www.gnu.org/philosophy/no-word-attachments.html
---(end of broadcast)---
TIP 9: In ve
that the children of the hierarchy are needlessly joined
in (as the only attribute that is actually needed is person_id, which
is on the parent level). It is not always trivial for the ORM to find
that out, without writing stuff that looks suspiciously similar to a
DBMS optimizer.
Maybe it is deba
is a key for it, and none of its attributes are used in the query.
Hibernate:
http://www.hibernate.org/>
Hibernate Inheritance Mapping:
http://www.hibernate.org/hib_docs/reference/en/html/inheritance.html>
greetings,
Nicolas
--
Nicolas Barbier
http://www.gnu.o
eeded to do the
full sort. Then, for a "partial sort", at least the first of these
passes has to be fully executed, because one needs to read at least
all the data once to find the "top n".
greetings,
Nicolas
--
Nicolas Barbier
http://www.gnu.org/phil
K). If used in a
subquery, one can then of course use the resulting column in the WHERE
clause of the outer query:
SELECT * FROM (
SELECT
ROW_NUMBER() OVER (ORDER BY key ASC) AS rownumber,
columns
FROM tablename
) AS foo
WHERE rownumber <= 10
(example stolen from the
under *safe* conditions.
>
> AFAICS there are no circumstances, ever, in which update-in-place is
> "safe". (No transaction can guarantee that it will commit.)
Updates to row values that did not "escape" the currect transaction
yet (ie, rows that were created by or have their
g.au/Papers/Neil%20Conway/Inside%20the%20PostgreSQL%20Query%20Optimizer/index.html>
The manual:
http://www.postgresql.org/docs/current/static/planner-optimizer.html>
Nicolas
--
Nicolas Barbier
http://www.gnu.org/philosophy/no-word-attachments.html
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On 11/20/05, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> On Sat, 19 Nov 2005, Nicolas Barbier wrote:
>
> > You might want to take a look at the pages that I set up to track the
> > progress on my master's thesis:
> >
> > http://www.nicolas.barbier.eas
thus, SQL). You should be able to
find all these papers with Google (Scholar) in case my computer is
shut down, otherwise you can download them directly from me.
Greetings,
Nicolas
--
Nicolas Barbier
http://www.gnu.org/philosophy/no-word-attachments.html
---(end of broadcas
101 - 127 of 127 matches
Mail list logo
