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
too
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 noticed
Ü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 in for
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 n
seconds or so.
I think looping forever is the right thing. Having a fixed timeout just means
Postgres
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
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
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
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 will
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, but
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 spelled
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 rules to tag a
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 used by
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 set to post
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
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 can't even
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't really
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 from Postgres's
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 and CHECK
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,
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
20 matches
Mail list logo
