nks in large part to efforts put in
over the last few years.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Make up enjoying your city life...produced by BIC CAMERA
---(end of broadcast)---
TIP 9: In ve
ndeed. Maybe it's best just to document this stuff for the various
OSes, and let the admins deal with configuring their machines.
But you know, it might be a reasonable option switch, or something.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Make
startup scripts that could help with this. For example, in NetBSD you
can "dkctl setcache r" for most any disk device (certainly all
SCSI and ATA) to enable the read cache and disable the write cache.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBS
stance of an area where
functions work differently from things not in functions (and I tend to
think that the way things work in functions in most of these cases is
right).
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Make up enjoying your city life
deletes in a transaction, and it
works ok.
BEGIN;
DELETE FROM offer_mutable WHERE offer_id = 123;
DELETE FROM offer_immutable WHERE offer_id = 123;
COMMIT;
Bug?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Make up enjoying your city
hings. I'll look into that. Thanks for the tip.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Make up enjoying your city life...produced by BIC CAMERA
---(end of broadcast)---
TIP 3: if posting/readin
: time zone "asia/tokyo-9" not recognized
SELECT '2004-08-22 18:42:12' AT TIME ZONE 'JST';
timezone
-
2004-08-22 18:42:12
(1 row)
Anybody have any idea what's going on here? The only patch pkgsrc makes
is related to sha
;t know as much as Postgres about the load. Postgres
> could optimize its use of cache based on whether it knows the data is being
> loaded by a vacuum or sequential scan rather than an index lookup. In practice
> Postgres has gone with ARC which I suppose a kernel could implement anyways,
&g
aches is only costing us 1% in performance, there's
not really much point
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Make up enjoying your city life...produced by BIC CAMERA
---(end of broadcast)--
have_a_plan
FOREIGN KEY ( contract_id ) REFERENCES plan ( contract_id )
INITIALLY DEFERRED;
produces the error message:
UNIQUE constraint matching given keys for referenced table "plan" not found
Since a plan may have more than one contract.
cjs
--
Curt Sampson <[EMAIL P
On Mon, 1 Mar 2004, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > Can you explain how to do this? There is no reference to a plan in the
> > contract table; the constraint just checks to see that, if a contract
> > exists, there is at least one pla
_dump has to know or care what check
constraints do; if it simply treated them as it does all the other
constraints, and applied them after all the data are loaded, wouldn't
the problem just go away?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
epted?
I dunno...this looks really easy to me....
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 9: the
n a bug is fixed.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 8: explain analyze is your friend
enough for people to
> understand it could bite them.
My big question is, should we expect that anybody reading the
documentation also has to go through the TODO list to see if there are
bugs on the list not mentioned in the manual?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 773
referential constraints. (You might even document that
workaround in the SET CONSTRAINTS manual page, with an appropriate
warning, if one seems necessary.)
I've attached a short shell script that will demonstrate the problem.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 ht
src/interfaces/ecpg/pgtypeslib/timestamp.c, BTW.
Any thoughts? I'm prepared to pull down a CVS checkout and recompile
to test fixes, if that will help.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Don't you know, in this n
, pretty much every BSD system is going to be using 16K block sizes
on large partitions; the cylinder group size and filesystem overhead is
way, way too small when using 8K blocks.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Don't you know, in
lot of random access of small records, your caching will probably
do better if you use 8K filesystem blocks; you're like to be able to
effectively cache more data.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Don't you know, in this new
On Wed, 27 Aug 2003, Bruno Wolff III wrote:
> Implicit froms aren't depreciated yet.
It would be really nice, to my mind, if they were killed stone dead.
I've been bitten several times by having an implicit FROM added to a
query that destroyed it.
cjs
--
Curt Sampson <[EMAIL P
ed that the log entry has been written, because once you've
touched data in an mmaped block you have no way of stopping it from
being written to the disk right away.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org
Don't you know, in thi
; checks?
You don't want it to. It's more efficent just to use mmap, because then
all the paging and caching issues are taken care of for you.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in t
th discussion of this.
That said, one step at a time is always good, and even having just the
very simplest views updatable would be a very nice thing.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're
ake sense to checksum it to verify that the block was not partially
written.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
nging the page
layout for, either. Maybe, if anybody still cares next time the page layout
is changed, pop it in with whatever else is being changed.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new D
On Mon, 17 Feb 2003, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
>
> > If it's any kind of a serious problem, maybe it would be worth keeping
> > a CRC of the header at the end of the page somewhere.
>
> See past discussions about keeping CRC
of pg_control,
> > we should actually implement the reading of existing log segments
> > in reverse order -- newest to oldest -- in order to find the last
> > checkpoint. This has not been implemented, yet.
So if you do this, do you still need to store that informatio
the end of the page somewhere.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 6: Have you search
row
itself, and your space savings wouldn't be nearly so dramatic.)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)-
our data, the larger writes when doing a big
transaction, such as a copy, might be a noticable win, in fact.
(I was about to say that it would seem odd that someone would spend that
much on RAM and not splurge on an extra pair of disks to separate the
WAL log, but then I realized that we'
ut to handle possible corruption of pg_control,
we should actually implement the reading of existing log segments
in reverse order -- newest to oldest -- in order to find the last
checkpoint. This has not been implemented, yet.
cjs
--
Curt Sampson <[EMAIL PROTECTED]>
On Sat, 15 Feb 2003, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > ... But there's really no need for all fifty of those,
> > if you don't mind not being able to restore to any time before the
> > current time.
>
> Which, of course, is
gt; we're talking about when we talk about PITR...
I don't think most people are thinking of that when they think of PITR;
I think they're thinking of applying changes from a log to a previous
version of a database.
And you can't do such a rollback at all, except on an entire data
cause when you do a restore, you start
with a full backup that is ok, and once you've successfully applied
all the transactions in the log, you know it will be ok again, so any
intermediate states during the restore where integrity is not maintained
are not a problem.
cjs
--
Curt Sampso
not want to install it
separately on all of the others?
Typically, I want my favourite non-OS utilities on all machines, not
just one. (Even if I don't use them on all machines.) Thus /usr/local is
for site-local stuff.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://ww
ther limited resource that you
wouldn't have to deal with.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)--
at can be shared. Is the stuff in
/usr/local/apache/conf really supposed to be shared amongst all machines
of that architecture on your site that run apache?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark A
e not overridden on the command line. If you're in a situation
like #2, you're basically stuck where we are now all the time: you have
to just put it somewhere and hope that, if someone else needs to find
it, they can.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737
om for something that might potentially be a half terrabyte of
data, and is not infrequently several gigabytes or more, is pretty
system-depenendent.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we
On Wed, 12 Feb 2003, [ISO-8859-1] Hans-J$B|(Brgen Sch$Bv(Bnig wrote:
(B
(B> Be careful with sort_mem - this might lead to VERY unexpected results. I
(B> did some testing on my good old Athlon 500 with a brand new IBM 120 Gigs
(B> HDD. Reducing the sort_mem gave me significantly faster resul
oes
> lock the shared memory into a specific fixed location for all processes.
I don't believe that the shared memory is not locked to a specific VM
address for every process. There's certainly no reason it needs to be.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737
the
pages in question are used infrequently enough that the system decides
that they are good candidates to be paged out. I would imagine that
Windows does the same.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new
I, personally, also think it makes more sense to pass to the postmaster
a configuration file that contains all the rest of the information about
the database system, including the disk locations of the various data
directories and whatnot.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 9
ight well improve our portability, too.
For example, mmap is a POSIX standard, whereas shmget is only an X/Open
standard. That makes me suspect that mmap is more widely available on
non-Unix platforms. (But I could be wrong.)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http
On Wed, 11 Feb 2003, Greg Copeland wrote:
> On Wed, 2003-02-05 at 18:53, Curt Sampson wrote:
>
> [Re: everybody sharing a single key]
>
> This issue doesn't change regardless of the mechanism you pick. Anyone
> that is signing a key must take reasonable measures to ens
on the copy of the key he may have made.
A passphrase is like a lock on your barn door. After you've given
someone the key and he's gone in and taken the cow, changing the lock
gives you no protection at all.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
d with any passphrases you like,
or no passphrase, for that matter.
> One could also only allow a single person to hold the passphrase and
> divide it into parts between two or more. This is commonly done in
> financial circles.
Hm. Splitting the key into parts is a very interesting i
out that the important point is not that these are both hashes of
some data, but that the time and means of acquisition of that hash are
entirely different between the two.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don'
un FTP server.)
If the "security token" is stored with the item to be secured (i.e.,
on the same FTP server) and is unsigned, it is just as subject to
modification as the item itself, and provides no extra security.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http
in time, making substitution
of both much more difficult.
Someone can easily change an MD5 signature file that's sitting right next
to a binary on an FTP server. Someone can not easily change a PGP key that's
already sitting in your keyring on your computer.
cjs
--
Curt Sa
t over the phone at all, since we don't share much
non-public background and I'm not dead certain that I could tell his voice
from a similar one. The same is not true when it comes to doing this with
some of my close friends.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737
ed is indeed valid?
4. Do I trust the holder of the postgres release-signing key to have
taken care of the key and have been careful about signing releases
with it?
Even if you extend this chain by a couple of people, that's trust in a
lot fewer people than you're going to
n the address column) we can't do that.
Personally, I'm all for breaking backwards compatability (as I usually
am :-)) but could quite easily live with specifying all most hosts as
"n.n.n.n/32" forever into the future, too.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81
rocmail does.
Given this, I'm not even sure the whole idea is worth persuing. (Though
I guess I should find out what NetBSD is really doing, and fix the
manual pages correspond to reality.)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don'
using all the protocols you
know." So long as you have the ability to distinguish where you listen
by both protocol and address, it's easy to be as secure as you need to be.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you kno
On Sun, 2 Feb 2003, Kurt Roeckx wrote:
> On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote:
> >
> > Sure. But you still want to be able to say (and can say, in some [many?]
> > socket API implementations) that you want to accept only IPv4 or only IPv6
> > con
lock would disappear.
The other option would be that the lock belongs to the process, in which
case one would think that a child doing an unlock should not affect the
parent, because it's a different process
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http:
ogram that will install postgres,
install parts of cygwin if necessary, and set up postgres as a service?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
dresses into that type as well,
and why or why not.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
d on any of these issues, if someone
can point out particular parts of postgres that would fail over NFS.)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
ty by simply
running both IPv4 and IPv6 on the hosts that interoperate.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)-
ces. As
I recall, it's certainly not on Xenix, SCO Unix, any of the BSDs, Linux,
SunOS, Solaris, and Tru64 Unix.
(I'm talking about the flock system call, here.)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in
On Fri, 31 Jan 2003, Bruce Momjian wrote:
> Also, I have heard a lot of people reocommending RAID 0+1 or 1+0 as a
> good mix of reliability and performance.
Right. Striping across mirrored drives will definitely be better, but
you can't do that with only three drives.
cjs
--
C
ur swap is not on NFS
A ktrace would be helpful. Also, it would be helpful if you tried doing
an initdb to a directory on the filer to see if you can even create a
database cluster, and tried doing that or rsyncing and accessing your
data over NFS with a NetBSD system as the NFS server.
sses, but it turned out to be
impractical, and thus is generally not used. Certainly you cannot route
to arbitrary v4 hosts using a v6 address.)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all l
ple to try to illuminate this:
what about storing ISO/OSI addresses in the same type as well? Isn't
that just the same thing as storing IPv4 and IPv6 addresses together?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't y
INTO retval null, null, null;
RETURN NEXT retval;
RETURN;
END
' LANGUAGE 'plpgsql';
SELECT * FROM t2();
...produces rows with nulls in them.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in
d pair.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 2: you can get off all lists at once with the
),
cjs-> coalesce(value3, -999) from t2();
case | case | case
--+--+--
-999 | -999 | -999
(1 row)
(You get the same result if you delete the SELECT INTO line above.)
Am I misunderstanding something here, or is this a bug?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +8
That means that a) you don't
have to send back a potentially large amount of data unless the user
asks for it, and b) multi-column primary keys work just fine.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this
ection to adding a function or other method to get
the primary key of the most recent insertion, assuming it exists, for
those folks with multi-column primary keys. Presumably it would generate
a result set just like a regular SELECT
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90
r. And I still maintain that
if something does need something like of OIDs, it should be declared
explicitly in the database schema (as you have to do in other DBMSes)
and not use a "hidden" feature.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
t if the name
doesn't match the header, it's a recycled file
(This response sent only to hackers.)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---
patibility." I want to hear arguments that the cost of
breaking backwards compatability is X, and the benefit of the new way of
doing things is Y, and here is why you think X > Y.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't
On Fri, 23 Jan 2003, Hannu Krosing wrote:
> Curt Sampson kirjutas N, 23.01.2003 kell 17:42:
> > If the OS can handle the scheduling (which, last I checked, Linux couldn't,
>
> When did you do your checking ?
> (just curious, not to start a flame war ;)
This was perhaps a
end I reckon it's much easier just to have the object system
force you to declare specific a specific object-ID column, if that's
what it takes. So long as you've got a candidate key, even if it's not
the primary key, you're fine.
cjs
--
Curt Sampson <[EMAIL PROTECTED]&g
rage) all of the
fixed-length fields before the variable-length fields.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)
hell out a couple hundred thousand for the Sun.
As for how well postgres uses multiple CPUs: so long as you've got lots
of connections with the load distributed among them, it's dependent on
the OS, postgres. If the OS can handle the scheduling (which, last I
checked, Linux couldn't, a
ty cool, when you're doing I/O on a table, just to say,
with one system call, "mmap this entire file containing the table into
my address space," and not have to worry about running out of address
space when you do this on multiple large tables. (And yes, I know this
would actua
nerate the primary key followed by other indexes with parallel
sorts rather than having to generate the primary key on one CPU (while
the other remains idle), wait while that completes, generate two more
indices, and then generate the last one .
cjs
--
Curt Sampson <[EMAIL PROTECTED]>
umps, and may not be entirely easy to implement.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 2: yo
On Sun, 19 Jan 2003, [ISO-8859-1] Hans-J$B|(Brgen Sch$Bv(Bnig wrote:
(B
(B> >+ people measure postgresql by the speed of bulk imports
(B>
(B> This is a good point. I can complete agree. What we might need is
(B> something called "SQL Loader" or so. This may sound funny and it doesn't
(B>
dropping shared memory
and moving to mmap might (but it's not certain) provide some noticable
improvement for not too much implementation effort.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in thi
about combining
multiple indexes, so you often need to split your queries across
the two "partitions" of the table that have separate indexes.
> Shall I subscribe to performance?
Yes, you really ought to. The list is [EMAIL PROTECTED]
cjs
--
Curt Sampson <[EMAIL PROTECTED]>
Note that I've redirected followups to the pgsql-performance list.
Avoiding cross-posting would be nice, since I am getting lots of
duplicate messages these days.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dar
rhaps not made completely
clear, that Berkley FFS defaults to synchronous meta-data updates,
but asynchronous data updates. You can also specify entirely
synchronous or entirely asynchronous updates. Linux ext2fs supports
only these last two modes, which is the problem.
cjs
--
Curt Sampson
e you don't set it so high you drive your system into
swapping, or it will kill your performance. Remember also, that in
7.2.x, postgres will actually use almost three times the value you give
sort_mem (i.e., sort_mem of 32 MB will actually allocate close to 96 MB
of memory for the sort).
cjs
--
removing the environment variable option means that others
have less documentation to read, and will spend less time wondering
why there's two different ways to do the same thing. And naive
people won't chose the wrong way because they don't know any better.
cjs
y, which means that you have to have a program set it, and you
have to make sure that program gets run before any startup, be it an
automated startup from /etc/rc on boot or a manual startup.
> I want to have it it the config file.
Well, then we're agreed.
cjs
--
Curt Sampson
rt anyway? Why store configuration information
outside of the database data directory in a form that's not easily
backed up, and not easily found by other utilities?
It's almost like people *don't* want to put this in the config file
or something
cjs
--
Curt Sampson <[EMAIL
tion: the configuration
file. If I created a patch to move a variable out of the configuration
file and make it an environment variable instead, everybody would
(rightly) think I was nuts, and the patch certainly would not be
accepted. So why should the situation be different for new configuration
k anybody was objecting to what you
wanted to do. It was simply a bad implementation that I, and probably
all the others, were objecting to. So please don't go on like we didn't
like the concept.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd
nstead (if that is indeed what you're doing), I'm not sure
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)
sily change when you happen to, say,
start postgres in the wrong window.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)--
rk on the
program, I'm happy to give developer access on sourceforge.
http://sourceforge.net/project/showfiles.php?group_id=55994
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age
;ve got command batching at some point, we can get the version,
and then send all the setup commands we need as a single batch after that.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we&#x
ling from source implies certain knowledge.
No it doesn't. All it means is that someone's using a system for
which they don't have a package handy.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this ne
Not really, I don't think.
But I'm starting to wonder if we should re-think all SET commands being
rolled back if a transaction fails. Some don't seem to make sense, such
as having SET AUTOCOMMIT or SET SESSION AUTHORIZATION roll back.
cjs
--
Curt Sampson <[EMAIL PROTECTED]>
wardly compatible with 7.2 and 7.1 servers.
Can you not check the server's version on connect?
It would be ideal if the JDBC driver, without modification, ran
all tests properly against 7.3, 7.2 and 7.1.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.or
On Tue, 10 Sep 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > Well, for the sequential reads, the readahead should be trigerred
> > even when reading from a raw device.
>
> That strikes me as an unportable assumption.
Not only unportable: but
1 - 100 of 255 matches
Mail list logo
