Qingqing Zhou [EMAIL PROTECTED] writes:
Since we will invoke callback functions unconditionally in errfinish(), so
pts_error_callback() should not report invalid type name without checking
current error status.
Please exhibit a case in which you feel this is needed.
On Mon, 2005-08-08 at 17:18 -0400, Tom Lane wrote:
If you think that this should be a global option instead of a
per-statement one, something like the (undocumented) #option hack might
be a good way to specify it; that would give it per-function scope,
which seems reasonable.
create
Mark Wong wrote:
O_DIRECT + fsync() can make sense. It avoids the copying of data
to the page cache before being written and will also guarantee
that the file's metadata is also written to disk. It also
prevents the page cache from filling up with write data that
will never be read (I
There once was a rumour of a EXPLAIN EXECUTE command.
This minor patch removes all trace of that, but without disturbing other
valid occurrences of the EXECUTE command, which still lives on.
Best Regards, Simon Riggs
Index: commands/explain.c
Simon Riggs [EMAIL PROTECTED] writes:
There once was a rumour of a EXPLAIN EXECUTE command.
This minor patch removes all trace of that, but without disturbing other
valid occurrences of the EXECUTE command, which still lives on.
It's not as dead as you seem to think.
regression=# prepare foo
I did some performance checks after the recent code commit.
The good news is that the parsing speed of COPY is now MUCH faster, which is
great. It is about 5 times faster - about 100MB/sec on my machine
(previously 20MB/sec at best, usually less).
The better news is that my original patch
Alon Goldshuv wrote:
I performed those measurement by executing *only the parsing logic* of the
COPY pipeline. All data conversion (functioncall3(string...)) and tuple
handling (form_heaptuple etc...) and insertion were manually disabled. So
the only code measured is reading from disk and
On Fri, Jul 29, 2005 at 03:33:09PM -0400, Tom Lane wrote:
It occurs to me that vacuuming to prevent XID wraparound is not the only
reason to do DB-wide vacuums: we also need to keep
pg_database.datvacuumxid from getting too old, else we will have
problems with clog bloat. We may need to
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm. I have a patch for this, but now that it's ready, I wonder if it's
really needed. If I understand vacuum_set_xid_limits() correctly, it's
very difficult for the vacuumxid to be far behind the freeze limit.
Umm ... they can be close together, or a
On Tue, Aug 09, 2005 at 11:24:40PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm. I have a patch for this, but now that it's ready, I wonder if it's
really needed. If I understand vacuum_set_xid_limits() correctly, it's
very difficult for the vacuumxid to be far
Tom Lane [EMAIL PROTECTED] writes
Please exhibit a case in which you feel this is needed.
Suppose I want to print a debug info in parseTypeString() like this:
+ elog(DEBUG1, parse type %s, buf.data);
raw_parsetree_list = raw_parser(buf.data);
Rebuild the server, psql it:
11 matches
Mail list logo
