Simon Riggs [EMAIL PROTECTED] writes:
I don't agree: If the truncation points are at 1 million, 2 million etc,
then if we advance the relvacuumxid from 1.2 million to 1.5 million,
then crash, the hints bits for that last vacuum are lost. Sounds bad,
but we have not truncated clog, so there is
On Mon, 2006-10-30 at 19:18 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I don't agree: If the truncation points are at 1 million, 2 million etc,
then if we advance the relvacuumxid from 1.2 million to 1.5 million,
then crash, the hints bits for that last vacuum are lost.
Simon Riggs [EMAIL PROTECTED] writes:
That was understood; in the above example I agree you need to flush. If
you don't pass a truncation point, you don't need to flush whether or
not you actually truncate. So we don't need to flush *every* time,
OK, but does that actually do much of anything
Simon Riggs [EMAIL PROTECTED] writes:
[I've just coded the relcache invalidation WAL logging patch also.]
What? That doesn't make any sense to me.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the
On Fri, 2006-10-27 at 12:01 -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's premature to start writing
patches until we've decided how this really needs to work.
Not logging hint-bit updates seems safe to me. As long as we have the
On Fri, 2006-10-27 at 22:19 +0100, Simon Riggs wrote:
So we definitely have a nasty problem here.
VACUUM FREEZE is just a loaded gun right now.
Maybe it's OK to say that during WAL replay we keep it
all the way back to the freeze horizon, but I'm not sure how we keep the
system from
Neil,
Sure, I'll wait for 8.3 to branch.
I have some cleanup I want to do for 8.3 too.
Josh Berkus
PostgreSQL @ Sun
San Francisco 415-752-2500
---(end of broadcast)---
TIP 6: explain analyze is your friend
Jonah H. Harris [EMAIL PROTECTED] writes:
On 10/26/06, Tom Lane [EMAIL PROTECTED] wrote:
This makes some really quite unacceptable assumptions about
the meaning and encoding of typmod ...
True, so VARCHAR seems like the only one? That's the only one I've
really encountered in the field on
On 10/26/06, Gregory Stark [EMAIL PROTECTED] wrote:
I think what you want is to add a new method entry in pg_type to
allow a type to declare a method to tell you whether a change
is work-free or not. Then any type, even user-defined types,
can allow some changes to be work-free and some not
+ #ifdef WIN32
+ #define _WIN32_WINNT 0x0400
+ #endif
Hmm ... in pg_ctl.c I see
#define _WIN32_WINNT 0x0500
Is there a reason for these to be different? Are there
other places
that will need this (ie, maybe it should be in c.h instead?)
Not really. The default
Magnus Hagander [EMAIL PROTECTED] writes:
+ #ifdef WIN32
+ #define _WIN32_WINNT 0x0400
+ #endif
Hmm ... in pg_ctl.c I see
#define _WIN32_WINNT 0x0500
Is there a reason for these to be different? Are there other
places that will need this (ie, maybe it should be in c.h instead?)
On Thu, Oct 12, 2006 at 06:58:52PM -0400, Tom Lane wrote:
I wrote:
aggregate_state would have no other uses in the system, and its input
and output functions would raise an error, so type safety is assured
--- there would be no way to call either the sfunc or ffunc manually,
except by
Martijn van Oosterhout kleptog@svana.org writes:
What this really calls for is a type that users are forbidden to
interact with directly. Basically, the type may only be used by C
functions and such C functions may not appear in an SQL query.
That's not really the flavor of solution I'd like
* Tom Lane ([EMAIL PROTECTED]) wrote:
That's not really the flavor of solution I'd like to have. Ideally,
it'd actually *work* to write
my_ffunc(my_sfunc(my_sfunc(null, 1), 2))
and get the same result as aggregating over the values 1 and 2. The
trick is to make sure that my_sfunc
Stephen Frost [EMAIL PROTECTED] writes:
That's not really the flavor of solution I'd like to have. Ideally,
it'd actually *work* to write
my_ffunc(my_sfunc(my_sfunc(null, 1), 2))
In general I like this idea but there are some complications, the main
one being where would the memory be
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
The other issue is, in the above scenario
is it acceptable to modify the result of my_sfunc(null, 1) in the ,2
call?
Yes, because the only place a nonnull value of the type could have come
from is a my_sfunc
Stephen Frost [EMAIL PROTECTED] writes:
Additionally, we'd have to be
able to mark the types as being polymorhpic along the same lines as
anyelement/anyarray.
What for?
So that the finalfunc can be polymorphic along the lines of my suggested
aaccum_sfunc(anyarray,anyelement) returns
Magnus Hagander [EMAIL PROTECTED] writes:
I've posted a 6.5kB patch (as an attachment) three times over the
past few days but haven't seen it hit the lists. Checking to see if
this goes through.
Did you by any chance gzip it? IIRC, mails with gzipped attachments are
silently dropped on-
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I've posted a 6.5kB patch (as an attachment) three times over the
past few days but haven't seen it hit the lists. Checking to see if
this goes through.
Did you by any chance gzip it? IIRC, mails with gzipped attachments are
Zdenek Kotala wrote:
Alvaro Herrera wrote:
What's global? A maybe-useful flag would be telling that a table is
shared. Is that it? Mind you, it's not useful to me because I know
which tables are shared, but I guess for someone not so familiar with
the catalogs it could have some use.
Zdenek Kotala [EMAIL PROTECTED] writes:
There is new version of catalogs overview patch. This version add only
one column into overview table which contains Oid/Filename for each
catalog table. Oid information is important if someone need make
relation with filename on disk and related
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
There is new version of catalogs overview patch. This version add only
one column into overview table which contains Oid/Filename for each
catalog table. Oid information is important if someone need make
relation with filename on disk
Magnus, is this the right fix?
Well, actually msdn states:
Return Value
If successful, _setmode returns the previous translation mode. A return
value of -1 indicates an error
So, shouldn't we be testing for -1 instead of 0 ?
The thing is probably academic, since _setmode is only supposed
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
If successful, _setmode returns the previous translation mode. A return
value of -1 indicates an error
So, shouldn't we be testing for -1 instead of 0 ?
I think the usual convention is to test for 0, unless there are other
negative return
I agree that this code is both wrong and unreadable
(although in
practice the _setmode will probably never fail, which
is why our
attention hasn't been drawn to it). Is someone going
to submit a
patch? I'm hesitant to change the code myself since
I'm not in a
Applied.
---
Bruce Momjian wrote:
Bruce Momjian wrote:
Magnus Hagander wrote:
Now, I still twist my head around the lines:
if ((fd = _open_osfhandle((long) h, fileFlags O_APPEND)) 0
||
(fileFlags
Now, I still twist my head around the lines:
if ((fd = _open_osfhandle((long) h, fileFlags O_APPEND)) 0
||
(fileFlags (O_TEXT | O_BINARY) (_setmode(fd, fileFlags
(O_TEXT
| O_BINARY)) 0)))
Without having studied it closely, it might also highlight a bug
on
failure of the
Magnus Hagander wrote:
Now, I still twist my head around the lines:
if ((fd = _open_osfhandle((long) h, fileFlags O_APPEND)) 0
||
(fileFlags (O_TEXT | O_BINARY) (_setmode(fd, fileFlags
(O_TEXT
| O_BINARY)) 0)))
Without having studied it closely, it might also highlight
Bruce Momjian wrote:
Magnus Hagander wrote:
Now, I still twist my head around the lines:
if ((fd = _open_osfhandle((long) h, fileFlags O_APPEND)) 0
||
(fileFlags (O_TEXT | O_BINARY) (_setmode(fd, fileFlags
(O_TEXT
| O_BINARY)) 0)))
Without having studied it
Without having studied it closely, it might also
highlight a bug
on
failure of the second clause -- if the _setmode
fails, shouldn't
_close be called instead of CloseHandle, and -1 returned?
(CloseHandle would still be called on failure of the
_open_osfhandle,
Mark,A model that intended to try and guarantee uniqueness would provide aUUID generation service for the entire host, that was not specific to
any application, or database, possibly accessible via the loopbackaddress. It would ensure that at any given time, either the time isnew, or the sequence
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2006-09-04 at 15:19 -0400, Tom Lane wrote:
AFAICT it's just junk. It happens to be the input times
MAX_RANDOM_VALUE, but what use is that? I wonder if we shouldn't
change the function to return VOID
I agree. Given how soon we want to get an 8.2
On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
I would not use a 100% random number generator for a UUID value as was
suggested. I prefer inserting the MAC address and the time, to at
least allow me to control if a collision is possible. This is not easy
to do using a few
On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
I would not use a 100% random number generator for a UUID value as was
suggested. I prefer inserting the MAC address and the time, to at
least allow me to control
On Tue, Sep 19, 2006 at 09:51:23AM -0400, [EMAIL PROTECTED] wrote:
On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
I would not use a 100% random number generator for a UUID value as was
suggested. I prefer
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the table is bootstrap, with oid and global.
Why is this a good idea?
Alvaro Herrera wrote:
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the table is bootstrap, with oid and global.
Why is
[EMAIL PROTECTED] wrote:
On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
I would not use a 100% random number generator for a UUID value as was
suggested. I prefer inserting the MAC address and the time, to
On Tue, Sep 19, 2006 at 11:21:51PM -0400, Alvaro Herrera wrote:
[EMAIL PROTECTED] wrote:
On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
I would not use a 100% random number generator for a UUID value as was
On Mon, Sep 18, 2006 at 10:33:22AM -0400, Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Isn't guaranteed uniqueness the very attribute that's expected? AFAIK
there's a commonly accepted algorithm providing this.
Anyone who thinks UUIDs are guaranteed unique has been drinking too
If you're going to yank it, please at least include a generator in
contrib.
Personally, I'd like to see at least some kind of generator in core,
with appropriate info/disclaimers in the docs. A simple random-number
generator is probably the best way to go in that regard. I think that
most people
On Mon, Sep 18, 2006 at 04:00:22PM -0500, Jim C. Nasby wrote:
BTW, at a former company we used SHA1s to identify files that had been
uploaded. We were wondering on the odds of 2 different files hashing to
the same value and found some statistical comparisons of probabilities.
I don't recall
On Mon, Sep 18, 2006 at 12:23:16PM -0400, [EMAIL PROTECTED] wrote:
I have UUID generation in core in my current implementation. In the
last year that I've been using it, I have already chosen twice to
generate UUIDs from my calling program. I find it faster, as it avoids
have to call out to
On Mon, 2006-09-18 at 16:00 -0500, Jim C. Nasby wrote:
BTW, at a former company we used SHA1s to identify files that had been
uploaded. We were wondering on the odds of 2 different files hashing to
the same value and found some statistical comparisons of probabilities.
I don't recall the
On Mon, Sep 18, 2006 at 04:17:50PM -0500, Jim C. Nasby wrote:
On Mon, Sep 18, 2006 at 12:23:16PM -0400, [EMAIL PROTECTED] wrote:
I have UUID generation in core in my current implementation. In the
last year that I've been using it, I have already chosen twice to
generate UUIDs from my
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Pavel Stehule wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
This patch doesn't seem to cope with cases
OK, removed from open item list.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've applied this but I'm now having some second thoughts about it,
because I'm seeing an actual *decrease*
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've applied this but I'm now having some second thoughts about it,
because I'm seeing an actual *decrease* in pgbench numbers from the
immediately prior CVS HEAD code.
The attached patch requires the new row to fit, and 10% to be free
On Tue, Sep 05, 2006 at 10:17:15AM +0400, Victor Wagner wrote:
It's a pity that it's to late for patch to get into 8.2.
It means that during all 8.2 lifecycle we'll have to maintain this patch
separately.
Hmm? After 8.2 releases, if it's ready, it will go straight into CVS at
which point it'll
Bruce Momjian wrote:
Susanne Ebrecht wrote:
Is it too hard to rip it back out once the full row support
arrives? That seems speculation at best anyway.
That's what I was thinking. Glad someone else replied. ;-)
If you're looking
Peter Eisentraut [EMAIL PROTECTED] writes:
Well, the line of code is
cpp_define=`echo $OIDSFILE | tr abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ | sed -e 's/[^A-Z]/_/g'`
so it ought to be pretty obvious what the correct solution for the
problem character ranges are locale-dependent
On 9/5/06, Tom Lane [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Well, the line of code is
cpp_define=`echo $OIDSFILE | tr abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ | sed -e 's/[^A-Z]/_/g'`
so it ought to be pretty obvious what the correct solution for the
On Sun, Sep 03, 2006 at 10:21:11PM -0400, Bruce Momjian wrote:
When I tried the ecpg regression tests it complained there was no
results/ directory. I created one and it worked.
Hmm, anyone else experiencing this? The pg_regress.sh has this code that
should create it:
outputdir=results/
if [
Michael Meskes [EMAIL PROTECTED] writes:
On Sun, Sep 03, 2006 at 10:21:11PM -0400, Bruce Momjian wrote:
When I tried the ecpg regression tests it complained there was no
results/ directory. I created one and it worked.
Hmm, anyone else experiencing this? The pg_regress.sh has this code that
Tom Lane wrote:
Michael Meskes [EMAIL PROTECTED] writes:
On Sun, Sep 03, 2006 at 10:21:11PM -0400, Bruce Momjian wrote:
When I tried the ecpg regression tests it complained there was no
results/ directory. I created one and it worked.
Hmm, anyone else experiencing this? The
Patch applied. Thanks.
---
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
The reason the patch is so short is that it's a kluge. If we really
cared about supporting this case, more wide-ranging changes
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
Wait a minute. This patch changes the behavior so that
LockBufferForCleanup is applied to *every* heap page, not only the ones
where there are removable tuples. It's not hard to imagine scenarios
where that results in severe
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
Wait a minute. This patch changes the behavior so that
LockBufferForCleanup is applied to *every* heap page, not only the ones
where there are removable tuples. It's not hard to imagine scenarios
where that
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
Wait a minute. This patch changes the behavior so that
LockBufferForCleanup is applied to *every* heap page, not only the ones
where there are removable tuples.
On Sun, Sep 03, 2006 at 12:01:06AM -0400, Tom Lane wrote:
But ever since 7.3 the convention for identifying system objects has
been pretty well-defined: anything that lives in one of the predefined
schemas. What problem were you having using that approach in
newsysviews?
It was just an issue
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD
ALL does not need this to work for 2G tables).
Already done because of bad coding. You want the TODO item removed too?
As I said, I see no
Michael Glaesemann [EMAIL PROTECTED] writes:
On Sep 4, 2006, at 9:41 , Tom Lane wrote:
This patch fails to apply --- looks like whitespace got mangled in
transit. Please resend as an attachment.
Please let me know if you have any problems with this one.
Ah, that one works --- applied. A
Tom Lane wrote:
You mentioned being unable to get the ecpg tests to run on your
machine. I'm sure Michael and Joachim would like the details. The
ecpg regression tests are pretty new and some portability problems
are to be expected, but they seem to be passing on all the machines
Michael and
Tom, should I apply this patch now? Are you still considering other
options for this?
---
Bruce Momjian wrote:
Tom, I ran your tests with fsync off (as you did), and saw numbers
bouncing between 400-700 tps without my
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, should I apply this patch now? Are you still considering other
options for this?
Please wait. This issue is very far down the to-list in terms of size
or significance ... but I'll get to it.
regards, tom lane
Susanne Ebrecht wrote:
Is it too hard to rip it back out once the full row support
arrives? That seems speculation at best anyway.
That's what I was thinking. Glad someone else replied. ;-)
If you're looking for votes, +1. I'll gladly take a subset of the
Thanks. Yes, it is need for two reasons. In 8.2 you can set
standard_conforming_strings to on, meaning \' is really treated as \ and
', and because some encodings now can't support \' for security reasons,
though I don't think tsearch2 supports those multibyte encodings.
Anyway, applied to 8.2
On Fri, Sep 01, 2006 at 12:36:11PM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the
bruce wrote:
I have merged your patch into current CVS and applied it; attached.
There was quite a bit of code drift. One drift area was the new
RETURNING clause; that was easy to fix. A more complex case is the
code no longer has values as ResTargets --- it is a simple a_expr list,
so I
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
This patch has broken half the buildfarm, and I've still not seen a
rationale why we need to make such a change at all.
Fixed with attached patch. The use case for this was not FETCH, but
MOVE for 2gig tables.
There is *no*
Jim C. Nasby [EMAIL PROTECTED] writes:
On Fri, Sep 01, 2006 at 12:36:11PM -0400, Alvaro Herrera wrote:
Whether a table is bootstrap or not doesn't seem useful to me.
Something that might be handy would be a method to determine if an
object is a system object or not (perhaps what the OP means
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD
ALL does not need this to work for 2G tables).
Already done because of bad coding. You want the TODO item removed too?
As I said, I see no use case for it. Maybe if
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the table is bootstrap, with oid and global.
Why is this a good idea?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I assume this is something we want in /contrib, right?
Peter posted an updated version, I believe.
Ah, it was lower in my mailbox. Thanks.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If
Am Mittwoch, 30. August 2006 18:01 schrieb Tom Lane:
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a small program struggling to get out. What is all the stuff about
handling multiple base rels?
On 8/30/06, Bruce Momjian [EMAIL PROTECTED] wrote:
I thought about this, and because we are placing two pieces of
information on the same line, it seems | is the best choice.
Good idea. It's far more readable with a pipe.
Oh. You want to pull the parameters out of that. I am thinking you
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 30. August 2006 18:01 schrieb Tom Lane:
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a small program struggling to get out.
But later SQL
Am Donnerstag, 31. August 2006 15:55 schrieb Tom Lane:
I'm unclear as to why you've got DO INSTEAD NOTHING rules in there ---
You need to have one unconditional rule if you have a bunch of
conditional ones. The system does not see through the fact that the
conditional ones cover all
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 31. August 2006 15:55 schrieb Tom Lane:
The proposed WITH CHECK OPTION implementation is unworkable for exactly
this reason --- it will give the wrong answers in the presence of
volatile functions such as nextval().
I'm not sure why
On 8/29/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Good point. I thought it was clear enough, but obviously not. I had a
similar case with bind, and used a comma to separate them:
LOG: statement: prepare sel1, SELECT $1;
LOG: statement: bind sel1, $1 = 'a''b'
For this one,
On Tue, 2006-08-29 at 18:31 -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
here comes the latest version (version 7) of the patch to handle large
result sets with psql. As previously discussed, a cursor is used
for SELECT queries when \set FETCH_COUNT some_value 0
Applied with
On Wed, Aug 30, 2006 at 12:01:25PM -0400, Tom Lane wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
[ latest views patch ]
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a small program struggling
Bruce,
I made a few tests here and the backend terminates with a SIG11 when a
parameter has the NULL value (it was logged as (null) before). I
suspect the new code broke something (perhaps it's due to the
escaping).
--
Guillaume
---(end of
On 8/29/06, Bruce Momjian [EMAIL PROTECTED] wrote:
DETAIL: prepare: SELECT $1; bind: $1 = 'a''b'
I attached a trivial patch to add a dash between the prepare part and
the bind part. People usually don't finish their queries with a semi
colon so it's more readable with a separator.
Guillaume Smet wrote:
On 8/29/06, Bruce Momjian [EMAIL PROTECTED] wrote:
DETAIL: prepare: SELECT $1; bind: $1 = 'a''b'
I attached a trivial patch to add a dash between the prepare part and
the bind part. People usually don't finish their queries with a semi
colon so it's more
Tom Lane [EMAIL PROTECTED] writes:
The reason the patch is so short is that it's a kluge. If we really
cared about supporting this case, more wide-ranging changes would be
needed (eg, there's no need to eat maintenance_work_mem worth of RAM
for the dead-TIDs array); and a decent respect to
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
The reason the patch is so short is that it's a kluge. If we really
cared about supporting this case, more wide-ranging changes would be
needed (eg, there's no need to eat maintenance_work_mem worth of RAM
for the dead-TIDs
Guillaume Smet wrote:
On 8/7/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Updated patch attached. It prints the text bind parameters on a single
detail line. I still have not seen portal names generated by libpq.
I'm currently testing CVS tip to generate sample log files. I noticed
that
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, I do. I have applied the attached patch to fix this issue and
several others. The fix was to save the bind parameters in the portal,
and display those in the executor output, if available.
I have a feeling you just blew away the 4% savings in psql
BTom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, I do. I have applied the attached patch to fix this issue and
several others. The fix was to save the bind parameters in the portal,
and display those in the executor output, if available.
I have a feeling you just blew away
bruce wrote:
BTom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, I do. I have applied the attached patch to fix this issue and
several others. The fix was to save the bind parameters in the portal,
and display those in the executor output, if available.
I have a
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
How often does that case come up in the real world, for tables that are
large enough that you'd care about vacuum performance?
I would have had the same objection if it resulted in substantially more
complex code but
On 8/7/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Updated patch attached. It prints the text bind parameters on a single
detail line. I still have not seen portal names generated by libpq.
I'm currently testing CVS tip to generate sample log files. I noticed
that Bruce only patched
Martin Atukunda [EMAIL PROTECTED] writes:
On 8/25/06, Tom Lane [EMAIL PROTECTED] wrote:
There's probably no way to get Apple's libedit to not try the fchmod,
so what do we want to do here? Maybe special-case the string
/dev/null?
If this is OK, I can up with a patch that special cases
On 8/25/06, Tom Lane [EMAIL PROTECTED] wrote:
Martin Atukunda [EMAIL PROTECTED] writes:
On 8/25/06, Tom Lane [EMAIL PROTECTED] wrote:
There's probably no way to get Apple's libedit to not try the fchmod,
so what do we want to do here? Maybe special-case the string
/dev/null?
If this is
Am Freitag, 25. August 2006 17:03 schrieb Martin Atukunda:
hmm, setting HISTFILE to /dev/null doesn't work on my MacOSX here.
Please elaborate on doesn't work.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
On 8/25/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Freitag, 25. August 2006 17:03 schrieb Martin Atukunda:
hmm, setting HISTFILE to /dev/null doesn't work on my MacOSX here.
Please elaborate on doesn't work.
without any .psqlrc file I get the following error when quitting a psql
Martin Atukunda [EMAIL PROTECTED] writes:
On 8/25/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Please elaborate on doesn't work.
without any .psqlrc file I get the following error when quitting a psql
session:
could not save history to file /Users/matlads/.psql_history: Invalid
argument
On 8/25/06, Tom Lane [EMAIL PROTECTED] wrote:
When I set HISTFILE to /dev/null I get the following:
could not save history to file /dev/null: Operation not permitted
Hm. ktrace shows this happening:
23279 psql CALL open(0x302d70,0x601,0x1b6)
23279 psql NAMI /dev/null
23279 psql
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
How about the callback solution for the SELECT case
that was copied from the original? Should I consider
open-coding in copy.c what ExecutorRun() does
to avoid the callback?
Adding a DestReceiver type is a good solution ...
301 - 400 of 660 matches
Mail list logo
