Hi,
I got some time to relook at the index with the snapshot patch. Still i
need to complete the freezing of index tuples with the snapshot.
a) When i was looking at the code for freezing heap tuples, i found out the
following. While freezing we log the complete block(not just the tuples we
fro
Hi,
Currently we check for the existence of NULL values in the tuple and we
set the has_null flag. If the has_null flag is present, the tuple will be
storing a null bitmap. What i propose is
a) By modifying the functions, heap_form_tuple and heap_fill_tuple, we can
check whether all the nulls
Hi,
On Dec 15, 2007 1:14 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> NikhilS <[EMAIL PROTECTED]> writes:
> > Any errors which occur before doing the heap_insert should not require
> > any recovery according to me.
>
> A sufficient (though far from all-encompassing) rejoinder to that is
> "triggers
On Dec 16, 2007 1:03 AM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Gokulakannan Somasundaram wrote:
> > I was going to say that I'm really only interested in physical I/O.
> Logical
> >> I/O which is satisfied by the kernel cache is only marginally
> interesting
> >> and
> >> buffer fetches
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> This behavior suggests that they can't even deal with LIMIT/OFFSET
>> values that aren't simple integer literals ...
> I suppose when they added these features I think they didn't have subqueries,
> so there wasn
"Tom Lane" <[EMAIL PROTECTED]> writes:
> mysql> select * from t limit 2 offset -2;
> ERROR 1064 (42000): You have an error in your SQL syntax; check the manual
> that corresponds to your MySQL server version for the right syntax to use
> near '-2' at line 1
>
> This behavior suggests that they c
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Since we got LIMIT/OFFSET from MySQL, would someone tell us how MySQL
> behaves in these cases?
Not very well, at least not in mysql 5.0.45:
mysql> select * from t limit -2;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
Gregory Stark wrote:
>
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > I'm fairly surprised these queries work. Is there some reason why we
> > support this? April Fools Day? Jules Verne? I'm all for fast queries,
> > but zero seems like the lowest value we should support...
>
> Huh, I was all
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> It seems pgindent is not considering EXEC_BACKEND typedefs.
>
> > Yep. The cause is that find_typedefs actually pulls the typedef out of
> > the debugged-enabled binary, and on Unix those functions aren't u
Andrew Hammond wrote:
> On Dec 12, 2007 11:37 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > Joshua D. Drake wrote:
> > > test
> >
> > Does anybody see any value in having [EMAIL PROTECTED] be an alias
> > for pgsql-hackers?
>
>
> No, but I see some mild irritation in having to modify my ru
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> It seems pgindent is not considering EXEC_BACKEND typedefs.
> Yep. The cause is that find_typedefs actually pulls the typedef out of
> the debugged-enabled binary, and on Unix those functions aren't used by
> default. This is s
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Fri, Dec 14, 2007 at 06:42:24PM -0500, Tom Lane wrote:
>> How do people feel about applying this to 8.3, rather than holding it?
> To me, this is a feature change, and therefore should be held.
Well, I wouldn't advocate making it in a minor release
Hannu Krosing <[EMAIL PROTECTED]> writes:
> But can't we _define_ such a subset, where we can do a transactionless
> load ?
Sure ... but you'll find that it's not large enough to be useful.
Once you remove all the interesting consistency checks such as
unique indexes and foreign keys, the COPY wil
On Fri, Dec 14, 2007 at 06:42:24PM -0500, Tom Lane wrote:
>
> How do people feel about applying this to 8.3, rather than holding it?
To me, this is a feature change, and therefore should be held.
A
---(end of broadcast)---
TIP 5: don't forget to
Magnus Hagander wrote:
> > > Should this mention that you don't need to turn it off at the disk level
> > > if
> > > you use fsync_writethrough?
> >
> > Uh, I remember we looked at this checkbox before but I don't remember
> > the details, and I can't find a comment about it. Was the issue that
Pavan Deolasee wrote:
> One of the improvements of HOT is to truncate a DEAD tuple to its
> line pointer. A DEAD tuple could be an old version of an updated
> tuple or a deleted tuple. When a tuple is truncated, the space used
> by the line pointer can not be reused (until the index entries are rem
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>>> Interesting. Maybe forever is going a bit too far, but retrying for
>>> seconds or so.
>
>> I think looping forever is the right thing. Having a fixed timeout jus
Ühel kenal päeval, L, 2007-12-15 kell 01:12, kirjutas Tom Lane:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > There's no way we can do a transactionless load, then? I'm thinking of the
> > load-into-new-partition which is a single pass/fail operation. Would
> > ignoring individual row errors i
Alvaro Herrera wrote:
> Hi,
>
> It seems pgindent is not considering EXEC_BACKEND typedefs. For
> example,
>
> static void restore_backend_variables(BackendParameters * param, Port *port);
>
> BackendParameters is not considered a typedef.
>
> Not sure how serious an issue this is ... I just n
On Saturday 2007-12-15 02:14, Simon Riggs wrote:
> On Fri, 2007-12-14 at 18:22 -0500, Tom Lane wrote:
> > Neil Conway <[EMAIL PROTECTED]> writes:
> > > By modifying COPY: COPY IGNORE ERRORS or some such would instruct COPY
> > > to drop (and log) rows that contain malformed data. That is, rows with
20 matches
Mail list logo
