I wrote:
> I propose that we define typdefault as containing the *external*
> representation of the desired value, and have get_typdefault apply the
> type's input conversion function to produce a Datum. Any objections?
This change is committed for 7.2.
regards, tom lane
> Thomas, any status on this? If not, I should add it to the TODO list.
Well, sure, there is *always* status ;)
I started coding a couple of days ago. So far, no showstoppers.
There are two related issues:
1) I should recode TIME WITH TIME ZONE to conform to SQL99. I had done
it originally wi
Funny, I found this going through my mailbox. Seems I was going to
return to this SO_PEERCRED anyway.
> Bruce Momjian wrote:
> >> > I think our current idea is to have people run local ident servers to
> >> > handle this. We don't have any OS-specific stuff in pg_hba.conf and I
> >> > am
Doug McNaught <[EMAIL PROTECTED]> writes:
> Hmmm--AFAIK, VACUUM is supposed to grab locks on the tables it
> processes, which will block until all open transactions against that
> table are finished. So either VACUUM or your transactions will have
> to wait, but they shouldn't interfere with each
> > >
> > > \\012In my early tests 0x0a (LF) was getting converted to 0x20
> (space).
> > > I think this was happening during PHP's parsing, but I'm still not sure.
> > > I'll dig into this some more later.
> > >
>
>
> The script I was using in PHP *explicitly* converted all linefeeds to
Thomas, any status on this? If not, I should add it to the TODO list.
> > Is this a TODO item?
>
> Sure, but I'd hate to have all of these individual items showing up as
> separate things in some ToDo list, since it won't paint a coherent
> picture of where things are headed.
>
> I'm plannin
Was this completed?
> OK, so I've defined a grammar for string_expr, which means the following
> currently works:
>
> CREATE FUNCTION foo_raise_loop(text) RETURNS text AS '
> DECLARE
> a ALIAS FOR $1;
> i integer;
> myrec RECORD;
> BEGIN
> i:=0;
> FOR myrec IN SELECT * FROM
Is this all addresssed?
> On Sat, 14 Jul 2001, Tom Lane wrote:
>
> > ... however, if you want to do some of the legwork yourself, here are
> > the ideas I had about what to do:
>
> OK. We'll dig into problem in august. At least we'll try.
> How many possible problems would arise after changing
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>>> And no, "use syslog" doesn't count.
>>
>> Why not?
> The standard implementations of syslog lose log entries under heavy
> load,
Okay, that's a sufficient answer for that point.
> (My personal preference th
> Bruce Momjian wrote:
> >
> > Has this gotten back to the DBD Perl maintainers?
> >
>
> yes, I just want to to apply some more patches,
> before releasing the next version.
Edmund, what do you think about moving DBD perl into our main CVS tree?
Seems it would be a logical place for it.
--
> > > > We could use POSIX spinlocks/semaphores now but we
> > > > don't because of performance, right?
> > >
> > > No. As long as no one proved with test that mutexes are bad for
> > > performance...
> > > Funny, such test would require ~ 1 day of work.
> >
> > Good question. I know the number
Tom Lane <[EMAIL PROTECTED]> writes:
> > And no, "use syslog" doesn't count.
>
> Why not?
The standard implementations of syslog lose log entries under heavy
load, because they rely on a daemon which reads from a named pipe with
a limited buffer space. This is not acceptable in a production
sy
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
> Attached patch does the above.
>
> Notes:
> 1. Incompatible changes: CURSOR is now a keyword and may not be used as an
>
I wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> I have a fatal error message while connecting more than 32 users using
>> current:
>> Aug 29 11:25:18 srapc1474 postgres[12189]: [1] FATAL 1:
>> ProcGetNewSemIdAndNum: cannot allocate a free semaphore
>> rather than a more informative message:
Mike Cianflone <[EMAIL PROTECTED]> writes:
> Is there a problem with running vacuum, or vacuum analyze in the
> middle of making transactions? If there happens to be a transaction running
> at the time I do a vacuum analyze, the transaction has problems and the
> trigger doesn't get complet
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> With all the great work put into allowing true 24/7 operation, as
> distributed we're still unable to rotate the log file. While the log file
> tends to be smaller than the database system as a whole, this is still
> going to annoy people because the
Thanks. Patch applied.
> Hello, i just reviewed the win32 errno patch and i saw that maybe i didn't
> really played it totally safe in my last suggestion, the system table might
> pick up the msg but not the netmsg.dll, so better try both.
> I also added a hex printout of the "errno" appended t
Denis Perchine <[EMAIL PROTECTED]> writes:
> Sep 5 08:42:30 mx postgres[5341]: [9] FATAL 2: XLogFlush: request is not satisfied
Hmm. I think you must be running into some kind of logic bug (boundary
condition maybe?) in XLogFlush. Could you add some debugging printouts,
along the line of
**
Is there a problem with running vacuum, or vacuum analyze in the
middle of making transactions? If there happens to be a transaction running
at the time I do a vacuum analyze, the transaction has problems and the
trigger doesn't get completed all the way, and the transaction fails.
Thanks
Hello,
I have quite strange problem. Postgres refuses to start.
This is 7.1.2. Actually this is Aug 15 snapshot of REL7_1_STABLE branch.
This is what should be 7.1.2. Any ideas how to repair data?
This is quite urgent. The system is live, and now stopped.
Sep 5 08:42:30 mx postgres[5341]
> So, is log rotation a concern? Is this a reasonable solution? Other
> ideas?
>
> (No Grand Unified Logging Solutions please. And no, "use syslog" doesn't
> count.)
What's the problem with using newsyslog or logrotate at the moment? (ie.
use the system log rotator)
Chris
-
Tom Lane writes:
> > I agree that it would be better to *not* allow implicit coercions. Given
> > that, any preferences on function names? Are text_to_bytea() and
> > bytea_to_text() too ugly?
>
> They're pretty ugly, but more importantly they're only suitable if we
> have exactly one conversion
With all the great work put into allowing true 24/7 operation, as
distributed we're still unable to rotate the log file. While the log file
tends to be smaller than the database system as a whole, this is still
going to annoy people because they can't control disk usage without taking
the server
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Why not just stick these things into encode() and name them
> > "my-cool-encoding" or whatever.
>
> Sounds good to me ...
>
> regards, tom lane
>
Sounds good to me too. Patch forthcoming . . .
-- Joe
---(end of broad
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Why not just stick these things into encode() and name them
> "my-cool-encoding" or whatever.
Sounds good to me ...
regards, tom lane
---(end of broadcast)---
TIP 3: if posting
I seem to be unable to access the CVS server:
cvs [update aborted]: connect to cvs.postgresql.org:2401 failed:
Marc, do you know anthing about this?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
26 matches
Mail list logo
