"Oliver Elphick" <[EMAIL PROTECTED]> writes:
>> Smart Shutdown request at Thu Dec 28 02:41:49 2000
>> DEBUG: shutting down
>> FATAL 2: Checkpoint lock is busy while data base is shutting down
>> Shutdown failed - abort
> It's not just on Alpha; I've seen that on my i386 Linux system.
Oooh, th
Tom Lane wrote:
...
>system. Curiously, however, the system fails when you try to shut
>it down:
>
>Smart Shutdown request at Thu Dec 28 02:41:49 2000
>DEBUG: shutting down
>FATAL 2: Checkpoint lock is busy while data base is shutting down
>Shutdown failed - abort
>
>I have no
On 27 Dec 2000 at 21:45 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > | Hm. I thought I'd fixed that. Are you up to date on
| > | src/backend/utils/adt/oid.c ? Current CVS has rev 1.42.
|
| > yup. got that version -- 1.42 2000/12/22 21:36:09 tgl
|
| You're right, it
Brent Verner <[EMAIL PROTECTED]> writes:
> | Hm. I thought I'd fixed that. Are you up to date on
> | src/backend/utils/adt/oid.c ? Current CVS has rev 1.42.
> yup. got that version -- 1.42 2000/12/22 21:36:09 tgl
You're right, it was still broken :-(. I think I've got it now, though.
Oliver
Brent Verner <[EMAIL PROTECTED]> writes:
> This is a revised patch that I sent earlier to allow building
> pg-7.1 with gcc as well as DEC's cc. I've had good results with this
> applied. Could some other Alpha users try this out. Even better, could
> an Alpha asm guru look over the asm that I'm
On Wed, Dec 27, 2000 at 12:56:26AM -0500, Bruce Momjian wrote:
> I have been asked by the major PHP developer Rasmus Lerdorf to see if
> the PostgreSQL/PHP interface needs any improvements.
>
> Is the current PostgreSQL interface module in PHP adequate? Does it
> support all the current libpq fe
> For example: If we use PHP (>4.0.2), which way is correct or mostly correct?
>
> 1. pg_setclientencoding($cid, "BIG5")
> 2. pg_exec("SET NAMES 'BIG5'")
> 3. pg_exec("SET CLIENT_ENCODING TO 'BIG5'")
2 and 3 are actually identical: telling the backend "Your client's
encoding is BIG5, so you nee
Adam Lang wrote:
>
> I thought I saw mention on the interfaces list that the ODBC driver needed
> to be modified to properly use the large objects.
You normally wouldn't use ODBC to access Postgres from PHP but rather
the Postgres-specific interface. You _can_ use ODBC as well but normally
that
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> when configure.in is older than configure, which is not all that unlikely.
Newer than, I think you meant. Yes, that's quite possible just after a
"cvs update".
> I guess the rule in rserv's makefile needs to be qualified better.
Agreed.
>> FWIW,
Tom Lane writes:
> Last week I tried to do a "make clean" in some subdirectory that's
> not cleaned by a toplevel clean -- I think it was doc/src/sgml, but it
> might have been a contrib dir -- and make went absolutely nuts. When
> the dust settled I had a toplevel configure file that was identi
Adam Lang wrote:
>
> I'd say the most important thing would be to get it upto speed with 7.1.
> Make sure PHP supports large objects and the TOAST properly.
What would be the problem there? As I understand TOAST, the application shouldn't take
any
notice of it's inner workings whatsoever . . .
> Reviewed. No problem :-)
> Would anyone commit it? Thanks.
Is this something to commit to the source tree, or something to post on
the postgresql.org web site? We may as well get it on the web site in
either case. Vince?
- Thomas
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> There is something busted in the snapshots, that leads to a wrong
> configure file. The file is equal to configure.in (not autoconf'ed).
> First noticed shortly before Christmas.
Last week I tried to do a "make clean" in some subdirectory that
Brent Verner <[EMAIL PROTECTED]> writes:
> these are the steps leading up the the assignment of the fscked
> fcache->fcinfo.arg[i] at execQual.c:603, which is what will eventually
> blow up ExecEvalFieldSelect.
That looks OK as far as it goes. Inside ExecEvalVar, you need to look
at the tuple_ty
Matthew wrote:
>
> I have been asked by the major PHP developer Rasmus Lerdorf to see
> if
> the PostgreSQL/PHP interface needs any improvements.
>
> Is the current PostgreSQL interface module in PHP adequate? Does it
> support all the current libpq features?
>
> The only problem we have run into (and I have heard of others having this
> problem also) is with persistent connections. I have seen discussion on
> persistent connection problems but I'm not sure the problem was ever
> resolved. The problem we have seen is that when using persistent
> connec
Brent Verner <[EMAIL PROTECTED]> writes:
> after hours in the gdb-hole, I see this... maybe a clue? :)
I don't think that comment means anything. Possibly it's a leftover
from a time when there was something unportable there. But if att_align
were broken on Alphas, you'd have a lot worse proble
Bruce Momjian wrote:
>
> I have been asked by the major PHP developer Rasmus Lerdorf to see if
> the PostgreSQL/PHP interface needs any improvements.
>
> Is the current PostgreSQL interface module in PHP adequate? Does it
> support all the current libpq features?
>
> If not, would someone subm
Christopher Kings-Lynne wrote:
>
> > Some SQL92 functionality is missing from the BIT and VARBIT types.
> >
> > It should be possible to enter hexadecimal values as:
> >
> > B'[...]'[{...'[ > X'[...]'[{...'[ >
> > (Cannan and Otten: SQL - The Standard Handbook, p.38)
> >
> > but the hexadexim
I have been asked by the major PHP developer Rasmus Lerdorf to see
if
the PostgreSQL/PHP interface needs any improvements.
Is the current PostgreSQL interface module in PHP adequate? Does it
support all the current libpq features?
The only problem we have run i
> I would set Seed per default. Even worse than a bad query path
> is an unpredictable query path. I see no argument, that a random Seed
> would buy us anything.
This kindof bugs me -- if you leave it stuck at a preset value, it makes it
possible to never delve into parts of solution space that
Bruce Momjian wrote:
>
> I have been asked by the major PHP developer Rasmus Lerdorf to see if
> the PostgreSQL/PHP interface needs any improvements.
>
> Is the current PostgreSQL interface module in PHP adequate? Does it
> support all the current libpq features?
>
> If not, would someone subm
C.C. Hsieh wrote:
> Tatsuo Ishii wrote:
>
> > Here are the patches I promised against PHP
> > 3.0.15 or later.
> >
> > To set the client encoding to BIG5:
> >
> > pg_setclientencoding($cid, "BIG5");
> >
> > ($cid is the connection id)
> >
> > To get the current client encoding:
> >
> > pg_clie
Tatsuo Ishii wrote:
> Here are the patches I promised against PHP
> 3.0.15 or later.
>
> To set the client encoding to BIG5:
>
> pg_setclientencoding($cid, "BIG5");
>
> ($cid is the connection id)
>
> To get the current client encoding:
>
> pg_clientencoding($cid);
>
> Note that these fucntion
On 26 Dec 2000 at 23:41 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > | Please apply it locally and let me know what you find.
|
| > what I'm seeing now is much the same.
|
| Drat. More to do, then.
after hours in the gdb-hole, I see this... maybe a clue? :)
src/incl
There is something busted in the snapshots, that leads to a wrong
configure file. The file is equal to configure.in (not autoconf'ed).
First noticed shortly before Christmas.
Andreas
> For 7.1, I propose that we only allow creation of child tables to the
> owner of the parent table.
Or dba. Sounds reasonable, maybe even sufficient to me.
(Informix has a separate right (called under) to grant inheritability to others
(just to support your separate right point).)
Andreas
On 26 Dec 2000 at 23:41 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > | Please apply it locally and let me know what you find.
|
| > what I'm seeing now is much the same.
|
| Drat. More to do, then.
|
| > i've been in circles trying to figure out where fcinfo->arg is
> > You can remove the randomness by setting the Seed
> configuration value,
>
> True, but that's not the default setup.
I would set Seed per default. Even worse than a bad query path
is an unpredictable query path. I see no argument, that a random Seed
would buy us anything.
Andreas
29 matches
Mail list logo
