Hi!
xor% uname -a
FreeBSD xor 5.0-RELEASE FreeBSD 5.0-RELEASE #7: Thu Mar 6 21:53:07 MSK 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/XOR i386
xor% gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.2.1 [FreeBSD] 20021119 (release)
Hi, all hackers,
I can startup database using command "/usr/local/pgsql/bin/postmaster -D
/usr/local/pgsql/data".
But when I debug it using gdb and set args -D /usr/local/pgsql/data, it can't startup
database. it says;
FATAL: Database "postgres" does not exist in the system catalog.
Is there an
Hi all.
I have read some codes on transaction abort
operation. When the transaction abort, it seem that
all the tuples related in the transaction have not been deal with. it XMIN
equals to the tuple create transaction
ID. Its XMAX equals null. Of cource , It make some records o
gdb doesn't like dealing with arguments (for me anyway). Try setting
the data directory via the PGDATA environment variable.
On Mon, 2003-03-17 at 04:35, Jinqiang Han wrote:
> Hi, all hackers,
> I can startup database using command "/usr/local/pgsql/bin/postmaster -D
> /usr/local/pgsql/data".
>
Is it just the password that expires or the account? The comment for
valid until says the password is valid until that time. However, one of
the examples says the account is valid until that time.
---(end of broadcast)---
TIP 6: Have you searched our
On Mon, Mar 17, 2003 at 17:35:10 +0800,
Jinqiang Han <[EMAIL PROTECTED]> wrote:
> Hi, all hackers,
> I can startup database using command "/usr/local/pgsql/bin/postmaster -D
> /usr/local/pgsql/data".
> But when I debug it using gdb and set args -D /usr/local/pgsql/data, it can't
> startup datab
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> gmake[4]: *** No rule to make target `../lib/typename.o', needed by `ecpg'. Stop.
Yeah, me too. I think the correct fix is '../lib' should become '../ecpglib'
in ecpg/preproc/Makefile, but am waiting on Michael to confirm.
rega
postgresql <[EMAIL PROTECTED]> writes:
> SGkgYWxsLg0KICAgIEkgaGF2ZSByZWFkIHNvbWUgY29kZXMgb24gdHJhbnNh
> Y3Rpb24gYWJvcnQgb3BlcmF0aW9uLiAgV2hlbiB0aGUgdHJhbnNhY3Rpb24g
> YWJvcnQsIGl0IHNlZW0gdGhhdCANCmFsbCB0aGUgdHVwbGVzIHJlbGF0ZWQg
> aW4gdGhlIHRyYW5zYWN0aW9uIGhhdmUgbm90IGJlZW4gZGVhbCB3aXRoLiBp
> dCBYTU
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Is it just the password that expires or the account? The comment for
> valid until says the password is valid until that time. However, one of
> the examples says the account is valid until that time.
Given the current implementation, I think it's corr
> 1. the userid isn't deleted or anything like that.
>
> 2. validuntil is only checked in password authentication methods; if you
> are able to connect via a non-password auth method (eg IDENT) then it's
> not checked.
>
> I've never been quite sure whether #2 is a bug or a feature, though.
Withou
On Fri, 14 Mar 2003, Steve Crawford wrote:
> One thing that would be great from a user's perspective (and which might
> reduce the volume of support questions as well) is to uniquely number all
> errors as in:
> Error 1036: the foo could not faz the fleep
>
I agree with the unique codes.
It does
I thought of something I'd overlooked in my original proposal for error-
handling upgrades: what about reporting where an error occurs in a PL
function?
Currently, plpgsql has a hack that prints a separate WARNING giving
the error location, but this is pretty darn ugly. It should be part of
the e
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Gregory Stark wrote:
>
> Just some fixup
On Sat, Mar 15, 2003 at 09:23:28AM -0600, Bruno Wolff III wrote:
> On Fri, Mar 14, 2003 at 14:19:46 -0600,
> Taral <[EMAIL PROTECTED]> wrote:
> > Same setup, different query:
> >
> > test=> explain select max(time) from test where id = '1';
> > NOTICE: QUERY PLAN:
> >
> > Aggregate (cost=5084
On Mon, Mar 17, 2003 at 11:23:47 -0600,
Taral <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 15, 2003 at 09:23:28AM -0600, Bruno Wolff III wrote:
> > On Fri, Mar 14, 2003 at 14:19:46 -0600,
> > Taral <[EMAIL PROTECTED]> wrote:
> > > Same setup, different query:
> > >
> > > test=> explain select max(
On the SQL list earlier today, I posted the following, and Josh Berkus
rightfully told me to post it here
I was looking for the source for this a month or so back, and couldn't
find
it. I needed similar stuff.
If someone could guide me, I **MIGHT** find the round tuit's for it for
7.4.
th
Tom Lane writes:
> * Backend's ReadyForQuery message (Z message) should carry an indication
> of current transaction status (idle/in transaction/in aborted transaction)
> so that frontend need not guess at state. Perhaps also indicate
> autocommit status.
If we do this, could we get rid of the m
On Tue, Mar 18, 2003 at 09:02:51 +0800,
Jinqiang Han <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III,
>
> Did you notice that postmaster is a link to postgres. So argv[0] is postgres
> not postmaster...
> I wonder if postmaster.c is still in use. It is really weird.
argv[0] gets set f
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> * Backend's ReadyForQuery message (Z message) should carry an indication
>> of current transaction status (idle/in transaction/in aborted transaction)
>> so that frontend need not guess at state. Perhaps also indicate
>> autocommit
Folks,
I'm currently working on an implementation of cursors that can function
outside the transaction that created them (the SQL spec calls them
"holdable cursors"). I can see 2 main ways to implement this:
(1) During the transaction that created the holdable cursor, don't do
anything special. W
On Mon, Mar 17, 2003 at 09:48:34PM -0500, Neil Conway wrote:
> (2) Use MVCC to ensure that the snapshot of the database that the
> transaction had is still valid, even after the transaction itself has
> committed.
What about opening a pseudo-transaction that exists only to serve the
cursor? Tha
On Mon, 2003-03-17 at 22:01, Alvaro Herrera wrote:
> What about opening a pseudo-transaction that exists only to serve the
> cursor?
What exactly do you mean by a pseudo-transaction?
Keep in mind we don't have nested transactions (yet?), and that the
holdable cursor needs to be accessible both in
On Mon, Mar 17, 2003 at 10:26:07PM -0500, Neil Conway wrote:
> On Mon, 2003-03-17 at 22:01, Alvaro Herrera wrote:
> > What about opening a pseudo-transaction that exists only to serve the
> > cursor?
>
> What exactly do you mean by a pseudo-transaction?
Assign an xid, create the transaction (crea
On Mon, 2003-03-17 at 20:48, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > If we do this, could we get rid of the messy autocommit GUC option and
> > handle autocommit in the client?
>
> Hmm ... that's a thought ... not very backwards-compatible with 7.3,
> but I think I like
Having a little problem with 7.3's tsearch:
usa=# select brand,description, ftiidx from food_foods where description
ilike '%frapp%';
brand | description
| ftiidx
---+---
hi,
i've successfully installed Postgresql 7.3.2 on Mac OSX 10.2.4, and can
access/administer as necessary
except, i can't seem to CREATELANG, specifically plpgsql .
the command:
createlang --pglib=/usr/local/pgsql/lib --dbname=apache_auth
plpgsql
simply returns:
ERROR: Load of file
Hackers,
I've been looking at what is involved into making nested transactions
possible. So far I've identified the following things. Please comment.
Additions are welcome.
Resource Management
---
We will create and select a new memory context for each subtransaction.
This con
> the command:
>
> createlang --pglib=/usr/local/pgsql/lib --dbname=apache_auth
> plpgsql
Try just this:
createlang plpgsql apache_auth
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Hi - there is a problem with PQescapeBytea for Win32. Since libpq is a DLL,
all memory allocated from within the DLL needs to be freed from within the
dll.
PQescapeBytea allocates memory, but there is no function call back into the
DLL to free this memory. This causes heap corruption when the m
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Why don't you like (1)? It seems fine to me, and I don't see how we are
> magically going to do any better in the future.
The restrictions of (1) seem pretty obvious to me ... but I don't
see any prospect of doing better in the near future, either.
Cros
--On Tuesday, March 18, 2003 12:22 PM +0800 Christopher Kings-Lynne
<[EMAIL PROTECTED]> wrote:
Try just this:
createlang plpgsql apache_auth
Chris
hi!
ok, but i wouldn't expect the result to be any different
here we go .
[EMAIL PROTECTED]/usr/local/pgsql/lib> createlang plpgsql apac
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Jeroen T. Vermeulen wrote:
> On Sat, Feb
Sure - I figured since it's a 1-line function, someone would just write it
themselves in the next release. But here it is attached. I'm not sure
exactly how you like your patches submitted, so here is a zip file with the
modified libpq-fe.h and fe-exec.c files.
The only change is the addition o
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> ... So the application already knows
> that "foo" is the table and "a" is the column. So if the application
> wants to know about details on the column "a", it can execute
> SELECT whatever FROM pg_attribute, pg_class WHERE relname = 'foo' AND attname
Attached is a committed patch to add a recommendation for ANALYZE after
restore. It is a shame we only have vacuumdb -a to do analyze _and_
vacuum, and no analyze-only option.
---
Tom Lane wrote:
> mlw <[EMAIL PROTECTED]> w
Tom Lane writes:
> Yes, Dave did answer --- basically, he's happy with not providing any
> column identity data in the cases where it's not obvious what the answer
> should be. And in particular he doesn't want the mechanism to drill
> down into view definitions (which is less than obviously righ
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > * Backend's ReadyForQuery message (Z message) should carry an indication
> > of current transaction status (idle/in transaction/in aborted transaction)
> > so that frontend need not guess at state. Perhaps also indicate
> > autocommit status.
>
>
I think (1) is fine. When I used Informix, we did lots of huge cursors
that we pulled from for reports, and they consumed huge amounts of RAM
before we could do a fetch --- and we expected that. It doesn't seem
worth adding complexity to avoid that, especially since even if (2) was
done, there w
Yes, I am aware of that limitation. If you link libpq as a
Multithreaded DLL, it will not link libc into each DLL, but have only
one libc that can free from anywhere.
Is that acceptable or do we need a Win32 specific memory free function?
---
Can someone comment on this bug report?
---
[EMAIL PROTECTED] wrote:
> Jiri Langr ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> Deallocating of
40 matches
Mail list logo
