* Xu Yifeng <[EMAIL PROTECTED]> [010315 22:25] wrote:
> Hello Tom,
>
> Friday, March 16, 2001, 6:54:22 AM, you wrote:
>
> TL> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> >> How many files need to be fsync'd?
>
> TL> Only one.
>
> >> If it's more than one, what might work is using mmap() to
Hello Tom,
Friday, March 16, 2001, 6:54:22 AM, you wrote:
TL> Alfred Perlstein <[EMAIL PROTECTED]> writes:
>> How many files need to be fsync'd?
TL> Only one.
>> If it's more than one, what might work is using mmap() to map the
>> files in adjacent areas, then calling msync() on the entire ran
Bruce Momjian <[EMAIL PROTECTED]> writes:
> It is hard for me to imagine O_* being slower than fsync(),
Not hard at all --- if we're writing multiple xlog blocks per
transaction, then O_* constrains the sequence of operations more
than we really want. Changing xlog.c to combine writes as much
as
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > My question was what are we needing to test? If we can do only single writes
> > to the log, don't we prefer O_* to fsync, and the O_D* options over
> > plain O_*? Am I confused?
>
> I don't think we have enough data to conclude that with any cert
Bruce Momjian <[EMAIL PROTECTED]> writes:
> My question was what are we needing to test? If we can do only single writes
> to the log, don't we prefer O_* to fsync, and the O_D* options over
> plain O_*? Am I confused?
I don't think we have enough data to conclude that with any certainty.
begin 644 searchraw.php3
M/#]P:'`*"2\O'!L;V1E*"<@)RP@)&-L96%N7W%U97)Y*3L*"2\O82!L:7-T(&]F('-T
M;W`@=V]R9',@8F5C;VUE2`](&%R2D["@DO+W)E2!I
M;F1E>`H)"7-O7=O&5C
M*"1C;VYN+"`D7=O7=O7=O7=O&5C*"1C;VYN+"`Dhttp://www.postgresql.org/users-lounge/docs/faq.html
I have written a simple search engine that utilizes pgsql. I would
like to make it a stored procedure, although I am still learning
plpgsql. Attached to this message is the basic search logic (in PHP).
This script will be in production on a major e-commerce site in about
a week. I think it woul
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, but the point of adding all those configuration options was to allow
> > us to figure out which was faster. If you can do the code so we no
> > longer need to know the answer of which is best, why bother adding the
> > config options.
>
> How i
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was wondering if the multiple writes performed to the XLOG could be
> > grouped into one write().
>
> That would require fairly major restructuring of xlog.c, which I don't
> want to undertake at this point in the cycle (we're trying to push out
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, but the point of adding all those configuration options was to allow
> us to figure out which was faster. If you can do the code so we no
> longer need to know the answer of which is best, why bother adding the
> config options.
How in the world di
Christopher Sawtell <[EMAIL PROTECTED]> writes:
> I'm getting errors as a result of making queries. The attached log from
> the last two queries gives an idea as to what is happening.
Hmmm ... you were the one who did the pg_resetxlog bit today, right?
I have a feeling I missed something in th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was wondering if the multiple writes performed to the XLOG could be
> grouped into one write().
That would require fairly major restructuring of xlog.c, which I don't
want to undertake at this point in the cycle (we're trying to push out
a release can
I was wondering if the multiple writes performed to the XLOG could be
grouped into one write(). Seems everyone agrees:
fdatasync/O_DSYNC is better then plain fsync/O_SYNC
and the O_* flags are better than fsync() if we are doing only one write
before every fsync. It seems the o
Greetings,
I'm getting errors as a result of making queries. The attached log from
the last two queries gives an idea as to what is happening.
I suspect I must have done something bad when I upgraded via cvsup.
Does this mean that I should do an initdb?
--
Sincerely etc.,
NAME
On Thu, 15 Mar 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Is there anything *major* left, other then the fsync issue, that needs to
> > be resolved?
>
> Don't believe so.
>
> I'm testing xlog fsync revisions now, should be ready to commit in an
> hour or so. (I'm j
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Is there anything *major* left, other then the fsync issue, that needs to
> be resolved?
Don't believe so.
I'm testing xlog fsync revisions now, should be ready to commit in an
hour or so. (I'm just curious to see what it does to the pgbench
resul
I know there are still discussions going on concerning the whole fsync
issue, but, from what I've been following, its purely a performance issue
then anything ...
Now that Tom's patch is in place for the XLOG stuff, I'd like to put out a
Beta6 tomorrow for testing, with an RC1 schedualed for nex
At 16:55 15/03/01 -0800, Alfred Perlstein wrote:
>* Philip Warner <[EMAIL PROTECTED]> [010315 16:46] wrote:
>> At 16:17 15/03/01 -0800, Alfred Perlstein wrote:
>> >
>> >Lost data is probably better than incorrect data. Either use locks
>> >or a copying mechanism. People will depend on the data r
* Philip Warner <[EMAIL PROTECTED]> [010315 17:08] wrote:
> At 16:55 15/03/01 -0800, Alfred Perlstein wrote:
> >* Philip Warner <[EMAIL PROTECTED]> [010315 16:46] wrote:
> >> At 16:17 15/03/01 -0800, Alfred Perlstein wrote:
> >> >
> >> >Lost data is probably better than incorrect data. Either use
Is someone able to put together a testing-type script or sequence so
people can run this on the various platforms and then report the
results?
For example, I can setup benchmarking, (or automated testing) on various
Solaris platforms to run overnight and report the results in the
morning. I susp
Bruce Momjian <[EMAIL PROTECTED]> writes:
> For example, Tom had a nice fsync test program. Why can't we run that
> on various platforms and collect the results, then make a decision on
> the best default.
Mainly because (a) there's not enough time before release, and (b) that
test program was f
> Bruce Momjian wrote:
> >
>
> > No one will ever do the proper timing tests to know which is better except us.
>
> Hi Bruce,
>
> I believe in the future that anyone doing serious benchmark tests before
> large-scale implementation will indeed be testing things like this.
> There will also be
* Philip Warner <[EMAIL PROTECTED]> [010315 16:46] wrote:
> At 16:17 15/03/01 -0800, Alfred Perlstein wrote:
> >
> >Lost data is probably better than incorrect data. Either use locks
> >or a copying mechanism. People will depend on the data returned
> >making sense.
> >
>
> But with per-backend
Bruce Momjian wrote:
>
> No one will ever do the proper timing tests to know which is better except us.
Hi Bruce,
I believe in the future that anyone doing serious benchmark tests before
large-scale implementation will indeed be testing things like this.
There will also be people/companies ou
At 16:17 15/03/01 -0800, Alfred Perlstein wrote:
>
>Lost data is probably better than incorrect data. Either use locks
>or a copying mechanism. People will depend on the data returned
>making sense.
>
But with per-backend data, there is only ever *one* writer to a given set
of counters. Everyon
At 06:57 15/03/01 -0500, Jan Wieck wrote:
>
>And shared memory has all the interlocking problems we want
>to avoid.
I suspect that if we keep per-backend data in a separate area, then we
don;t need locking since there is only one writer. It does not matter if a
reader gets an inconsiste
* Philip Warner <[EMAIL PROTECTED]> [010315 16:14] wrote:
> At 06:57 15/03/01 -0500, Jan Wieck wrote:
> >
> >And shared memory has all the interlocking problems we want
> >to avoid.
>
> I suspect that if we keep per-backend data in a separate area, then we
> don;t need locking since the
> Well, that's exactly *why* we need an overridable default. Or would you
> like to try to do some performance measurements in configure?
At this point I'm more comfortable with a compile-time option
(determined statically or in a configure compilation test, not a
performance test), rather than
* Tom Lane <[EMAIL PROTECTED]> [010315 14:54] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > How many files need to be fsync'd?
>
> Only one.
>
> > If it's more than one, what might work is using mmap() to map the
> > files in adjacent areas, then calling msync() on the entire range,
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> How many files need to be fsync'd?
Only one.
> If it's more than one, what might work is using mmap() to map the
> files in adjacent areas, then calling msync() on the entire range,
> this would allow you to batch fsync the data.
Interesting though
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> switch(lower(string[0]) + lower(string[5]))
> {
> case 'f': /* fsync */
> case 'f' + 's': /* fdatasync */
> case 'o' + 's': /* open_sync */
> case 'o' + 'd': /* open_datasync */
> }
> Although ugly, it should serve as a
* Mikheev, Vadim <[EMAIL PROTECTED]> [010315 13:52] wrote:
> > I believe that we don't know enough yet to nail down a hard-wired
> > decision. Vadim's idea of preferring O_DSYNC if it appears to be
> > different from O_SYNC is a good first cut, but I think we'd
> > better make it possible to ove
Tom Lane writes:
> wal_sync_method = fsync | fdatasync | open_sync | open_datasync
> A small problem is that I don't want to be doing multiple strcasecmp's
> to figure out what to do in xlog.c.
This should be efficient:
switch(lower(string[0]) + lower(string[5]))
{
case 'f': /* f
I have started the "PL/pgSQL CookBook" project. The goal is to
create a cookbook of PL/pgSQL functions that will be catalogued and made
available for others to use and learn from.
Come to http://www.brasileiro.net/postgres and contribute your own
PL/pgSQL (or PL/Tcl, PL/Perl) fun
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > What about a collector deamon, fired up by the postmaster and
> > receiving UDP packets from the backends. Under heavy load, it
> > might miss some statistic messages, well, but that's not as
> > bad as having locks caus
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > What about a collector deamon, fired up by the postmaster and
> > receiving UDP packets from the backends. Under heavy load, it
> > might miss some statistic messages, well, but that's not as
> > bad as having locks caus
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> We postulate that one of those has to exist. Alternatively, you make the
> option read
> wal_sync_method = fsync | open_sync
> In the "parse_hook" for the parameter you if #ifdef out 'open_sync' as a
> valid option if none of those exist, so a user w
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I haven't followed the jungle of numbers too closely.
> Is it not the case that WAL + fsync is still faster than 7.0 + fsync and
> WAL/no fsync is still faster than 7.0/no fsync?
I believe the first is true in most cases. I wouldn't swear to the
sec
> "The default is 'on' if your system defines one of the macros O_SYNC,
> O_DSYNC, O_FSYNC, and if O_SYNC and O_DSYNC are distinct, otherwise the
> default is 'off'."
>
> The net result of this would be that the average user would have
> absolutely no clue what the default on his machine is.
>
>
Tom Lane writes:
> I've been mentally working through the code, and see only one reason why
> it might be necessary to go with a compile-time choice: suppose we see
> that none of O_DSYNC, O_SYNC, O_FSYNC, [others] are defined?
We postulate that one of those has to exist. Alternatively, you mak
> I believe that we don't know enough yet to nail down a hard-wired
> decision. Vadim's idea of preferring O_DSYNC if it appears to be
> different from O_SYNC is a good first cut, but I think we'd
> better make it possible to override that, at least for testing purposes.
So let's leave fsync as
I have completed all the features I want in the first release of
pgmonitor. It is available at:
ftp://candle.pha.pa.us/pub/postgresql/pgmonitor.tar.gz
I am going to send this over soon to announce/general to encourage its
use.
--
Bruce Momjian| http://candle
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Peter, what do you think about configuration-dependent defaults for
>> GUC variables?
> We have plenty of those already, but we should avoid a variable whose
> specification is:
> "The default is 'on' if your system defines one of the macros O_SYNC
Tom Lane writes:
> However, I can actually make a case for this: we are flushing out
> performance bugs in a new feature, ie WAL.
I haven't followed the jungle of numbers too closely.
Is it not the case that WAL + fsync is still faster than 7.0 + fsync and
WAL/no fsync is still faster than 7.0/
Tom Lane writes:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > ... I would either
> > use fsync as default or don't deal with O_SYNC at all.
> > But if O_DSYNC is defined and O_DSYNC != O_SYNC then we should
> > use O_DSYNC by default.
>
> Hm. We could do that reasonably painlessly as a com
I'd actually vote for it to remain for a release or two or more, as
we get more experience with stuff, the defaults may be different for
different workloads.
LER
--
Larry Rosenman
http://www.lerctr.org/~ler/
Phone: +1 972 41
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I later read Vadim's comment that fsync() of two blocks may be faster
> > than two O_* writes, so I am now confused about the proper solution.
> > However, I think we need to pick one and make it invisible to the user.
> > Perhaps a compiler/config
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I later read Vadim's comment that fsync() of two blocks may be faster
> than two O_* writes, so I am now confused about the proper solution.
> However, I think we need to pick one and make it invisible to the user.
> Perhaps a compiler/config.h flag fo
[ Charset ISO-8859-1 unsupported, converting... ]
> > Based on the tests we did last week, it seems clear than on many
> > platforms it's a win to sync the WAL log by writing it with open()
> > option O_SYNC (or O_DSYNC where available) rather than
> > issuing explicit fsync() (resp. fdatasync())
> > I've been mentally working through the code, and see only one reason why
> > it might be necessary to go with a compile-time choice: suppose we see
> > that none of O_DSYNC, O_SYNC, O_FSYNC, [others] are defined? With the
> > compile-time choice it's easy: #define USE_FSYNC_FOR_WAL, and sail
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Can someone explain why configure/platform-specific flags are allowed to
> > be added at this stage in the release, but my pgmonitor patch was
> > rejected?
>
> Possibly just because Marc hasn't stomped on me quite yet ;-)
>
> However, I can actual
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can someone explain why configure/platform-specific flags are allowed to
> be added at this stage in the release, but my pgmonitor patch was
> rejected?
Possibly just because Marc hasn't stomped on me quite yet ;-)
However, I can actually make a case f
> Based on the tests we did last week, it seems clear than on many
> platforms it's a win to sync the WAL log by writing it with open()
> option O_SYNC (or O_DSYNC where available) rather than issuing explicit
> fsync() (resp. fdatasync()) calls. In theory fsync ought to be faster,
> but it seems
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > As a general rule, if something can be a run time option, as opposed to a
> > compile time option, then it should be. At the very least you keep the
> > installation simple and allow for easier experimenting.
>
> I've been mentally working throu
* Tom Lane <[EMAIL PROTECTED]> [010315 11:45] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > And since we're sorta on the topic of IO, I noticed that it looks
> > like (at least in 7.0.3) that vacuum and certain other routines
> > read files in reverse order.
>
> Vacuum does that becau
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> And since we're sorta on the topic of IO, I noticed that it looks
> like (at least in 7.0.3) that vacuum and certain other routines
> read files in reverse order.
Vacuum does that because it's trying to push tuples down from the end
into free space i
* Peter Eisentraut <[EMAIL PROTECTED]> [010315 11:33] wrote:
> Alfred Perlstein writes:
>
> > Sorry, what's a GUC? :)
>
> Grand Unified Configuration system
>
> It's basically a cute name for the achievement that there's now a single
> name space and interface for (almost) all postmaster run ti
Alfred Perlstein wrote:
> * Tom Lane <[EMAIL PROTECTED]> [010315 11:07] wrote:
> > Peter, what do you think about configuration-dependent defaults for
> > GUC variables?
> Sorry, what's a GUC? :)
Grand Unified Configuration, Peter E.'s baby.
See the thread starting at
http://www.postgresql.org
Alfred Perlstein writes:
> Sorry, what's a GUC? :)
Grand Unified Configuration system
It's basically a cute name for the achievement that there's now a single
name space and interface for (almost) all postmaster run time
configuration variables,
--
Peter Eisentraut [EMAIL PROTECTED]
* Tom Lane <[EMAIL PROTECTED]> [010315 11:07] wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > ... I would either
> > use fsync as default or don't deal with O_SYNC at all.
> > But if O_DSYNC is defined and O_DSYNC != O_SYNC then we should
> > use O_DSYNC by default.
>
> Hm. We could do
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> ... I would either
> use fsync as default or don't deal with O_SYNC at all.
> But if O_DSYNC is defined and O_DSYNC != O_SYNC then we should
> use O_DSYNC by default.
Hm. We could do that reasonably painlessly as a compile-time test in
xlog.c, but I
> Based on the tests we did last week, it seems clear than on many
> platforms it's a win to sync the WAL log by writing it with open()
> option O_SYNC (or O_DSYNC where available) rather than
> issuing explicit fsync() (resp. fdatasync()) calls.
I don't remember big difference in using fsync or
On Thu, Mar 15, 2001 at 01:18:57PM -0500, Tom Lane wrote:
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> >> Is there a way to just remove the "_opto" from the end of the string?
>
> > If you have exactly one known string to (optionally) remove, this works
> > (and even works if the string is
On Thu, 15 Mar 2001, Paul wrote:
> Sorry, if I used not corresponding mailing list, but I really dont
> know where to send such email.
>
> Is that possible to add one more SQL command to Postgres? The problem
> that IMHO no one RDBMS allows SQL command for sheduling. To support
> sheduling SQL p
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
>> Is there a way to just remove the "_opto" from the end of the string?
> If you have exactly one known string to (optionally) remove, this works
> (and even works if the string is missing. Watch out for the early
> occurance of substring problem,
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> As a general rule, if something can be a run time option, as opposed to a
> compile time option, then it should be. At the very least you keep the
> installation simple and allow for easier experimenting.
I've been mentally working through the code,
Tom Lane writes:
> I think we need to make both O_SYNC and fsync() choices available in
> 7.1. Two important questions need to be settled:
>
> 1. Is a compile-time flag (in config.h.in) good enough, or do we need
> to make it configurable via a GUC variable? (A variable would have to
> be postm
On Thu, Mar 15, 2001 at 09:34:04AM -0800, G. Anthony Reina wrote:
> Ken Hirsch wrote:
>
> > So rtrim("center_out_opto", "_opto") returns
> > "center_ou"
> > because "u" is not in the set {o, p, t, _} but all the characters after it
> > are.
> > rtrim("center_out_opto", "pot_") will produce th
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> * Tom Lane <[EMAIL PROTECTED]> [010315 09:35] wrote:
>> BTW, are there any platforms where O_DSYNC exists but has a different
>> spelling?
> Yes, FreeBSD only has: O_FSYNC
> it doesn't have O_SYNC nor O_DSYNC.
Okay ... we can fall back to O_FSYNC if
* Tom Lane <[EMAIL PROTECTED]> [010315 09:35] wrote:
>
> BTW, are there any platforms where O_DSYNC exists but has a different
> spelling?
Yes, FreeBSD only has: O_FSYNC
it doesn't have O_SYNC nor O_DSYNC.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
-
Based on the tests we did last week, it seems clear than on many
platforms it's a win to sync the WAL log by writing it with open()
option O_SYNC (or O_DSYNC where available) rather than issuing explicit
fsync() (resp. fdatasync()) calls. In theory fsync ought to be faster,
but it seems that too
Ken Hirsch wrote:
> So rtrim("center_out_opto", "_opto") returns
> "center_ou"
> because "u" is not in the set {o, p, t, _} but all the characters after it
> are.
> rtrim("center_out_opto", "pot_") will produce the same thing.
>
That seems like an odd definition (although as Tom points out,
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (some of the protocol changes in 6.4 were done to make it easier ;-)).
> I may misremember, but IIRC some older protocol (or at least libpq)
> returned 0 as backend pid to listening client if it was notified by itself.
> Currently i
Tom Lane wrote:
>
> I've built applications that do roughly this sort of thing in Postgres
> (some of the protocol changes in 6.4 were done to make it easier ;-)).
I may misremember, but IIRC some older protocol (or at least libpq)
returned 0 as backend pid to listening client if it was notifi
Michael Meskes wrote:
> Is anyone on this list in Hannover for CeBit? Maybe we could arrange a
> meeting.
Looks pretty much that I'll be still in Hamburg by then. What
are the days you planned?
Jan
--
#==#
# It's easi
Jan Wieck <[EMAIL PROTECTED]> writes:
> What about a collector deamon, fired up by the postmaster and
> receiving UDP packets from the backends. Under heavy load, it
> might miss some statistic messages, well, but that's not as
> bad as having locks causing backends to loose perf
Paul <[EMAIL PROTECTED]> writes:
> CREATE SHEDULER name
> ON table.field
> [FOR [EACH]|[LAST]]
> EXECUTE PROCEDURE func(arguments)
> When the current time becomes equal or more than minimal time in
> the _table.field_, the event happens and the _func_ will be executed,
> and after that all record
Tim Allen <[EMAIL PROTECTED]> writes:
> Are there any known database-corrupting bugs in 7.0.3?
None that aren't also in earlier releases, AFAIR, so your report is
fairly troubling. However there's not enough here to venture a guess
about the source of the problem.
Do you see any backend crashes
[EMAIL PROTECTED] (D'Arcy J.M. Cain) writes:
> One thing I notice is that a single query can seem to block other queries,
> at least to some extent.
It's not supposed to, except with certain specific features (for
example, I don't think any of the index types other than btree allow
concurrent ins
> Hi all pgsql-hackers,
>
> Iam a new hacker of this list.
>
> I and a few others have started an Linux localization project for Indian
> Languages called - Project Tuxila (http://inapp.com/tuxila), and are
> currently doing the localization for an Indian language called
> "Malayalam". The utili
Hello all,
I try to build postgresql 7.1 beta 5 on UnixWare 7.1.1. I have problem to
build the Python extension,
there is a problem to build the shared library, I have see some information
on that but don't help me.
Sorry
Can you help me by providing the correct command
Thanks
Joel
--
Thus spake Tom Lane
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I have tested PostgreSQL with 2-4 CPU linux boxes. In summary, 2 CPU
> > was a big win, but 4 was not. I'm not sure where the bottle neck is
> > though.
>
> Our not-very-good implementation of spin locking (using select() to
> wai
Hi all pgsql-hackers,
Iam a new hacker of this list.
I and a few others have started an Linux localization project for Indian
Languages called - Project Tuxila (http://inapp.com/tuxila), and are
currently doing the localization for an Indian language called
"Malayalam". The utilities that will b
Bruce Momjian wrote:
>
> Yes, it seems storing info in shared memory and having a system table to
> access it is the way to go.
Depends,
first of all we need to know WHAT we want to collect. If we
talk about block read/write statistics and such on a per
table base, which
On Wed, Mar 14, 2001 at 01:23:30PM -0500, Roland Roberts wrote:
> > "AZ" == Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>
> >> Unix day-of-week starts on Sunday, not Monday, which is what
> >> date_trunc('dow',...) returns. Presumably this is modeled on
> >> the traditional
Sorry, if I used not corresponding mailing list, but I really dont
know where to send such email.
Is that possible to add one more SQL command to Postgres? The problem
that IMHO no one RDBMS allows SQL command for sheduling. To support
sheduling SQL programmers have to use outer tools to periodic
Can confirm this. Get this just yesterday time ago...
Messages:
NOTICE: Rel acm: TID 1697/217: OID IS INVALID. TUPGONE 1.
And lots of such lines...
And
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or whil
We have an application that we were running quite happily using pg6.5.3
in various customer sites. Now we are about to roll out a new version of
our application, and we are going to use pg7.0.3. However, in testing
we've come across a couple of isolated incidents of database
corruption. They are s
88 matches
Mail list logo
