As per discussion on -hackers the attached patch creates the 'default'
database at initdb time as a default target for initial connections to
keep template1 free from connections and available as template source.
I consider this DB a system object, so it's created before
make_template0 sets th
Umm. Tiny item, but your comment still refers to the database as
pg_system ;-)
//Magnus
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Pflug
> Sent: Saturday, June 18, 2005 10:42 AM
> To: PostgreSQL-patches
> Subject: [PATCHES] default d
Magnus Hagander wrote:
Umm. Tiny item, but your comment still refers to the database as
pg_system ;-)
:-)
Regards,
Andreas
Index: src/bin/initdb/initdb.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/initdb/initdb.c,v
retrieving
On Saturday 18 June 2005 04:55, Andreas Pflug wrote:
> Magnus Hagander wrote:
> > Umm. Tiny item, but your comment still refers to the database as
> > pg_system ;-)
> >
What is the purpose of this database? A generalized, shared resource for tool
makers and add-on packages to store information in
Andreas Pflug <[EMAIL PROTECTED]> writes:
> + "CREATE DATABASE \"default\";\n",
> + "REVOKE CREATE,TEMPORARY ON DATABASE \"default\" FROM
> public;\n",
Uh, why the rights revocation? That makes the thing essentially useless
... except to superusers, who will not be affect
Robert Treat wrote:
On Saturday 18 June 2005 04:55, Andreas Pflug wrote:
Magnus Hagander wrote:
Umm. Tiny item, but your comment still refers to the database as
pg_system ;-)
What is the purpose of this database? A generalized, shared resource for tool
makers and add-on pack
On Sat, Jun 18, 2005 at 09:27:49 -0400,
Robert Treat <[EMAIL PROTECTED]> wrote:
> On Saturday 18 June 2005 04:55, Andreas Pflug wrote:
> > Magnus Hagander wrote:
> > > Umm. Tiny item, but your comment still refers to the database as
> > > pg_system ;-)
> > >
>
> What is the purpose of this datab
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> I thought I would have a look at:
> (Datatypes) Add function to return compressed length of TOAST data values.
My recollection of that discussion is that we just wanted something
that would return the actual VARSIZE() of the datum. You're building
somet
Tom Lane wrote:
> I've attached the 2PC patch as applied in case you want to have a look.
> I did some fairly significant hacking on it, and I thought it'd be a
> good idea to enumerate some of the changes:
FYI: this commit seems to cause problems/crashes during make check on my
OpenBSD/Sparc64 b
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> FYI: this commit seems to cause problems/crashes during make check on my
> OpenBSD/Sparc64 buildfarmclient:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2005-06-17%2023:50:04
> I just checked manually with a fresh checkout - a
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>FYI: this commit seems to cause problems/crashes during make check on my
>>OpenBSD/Sparc64 buildfarmclient:
>
>
>>http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2005-06-17%2023:50:04
>
>
>>I just checked man
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> Can you get a stack trace from the core dump?
> (gdb) bt
> #0 0x50377ba4 in memcpy () from /usr/lib/libc.so.34.2
> #1 0x00326efc in hash_search ()
> #2 0x00343430 in pg_tzset ()
> #3 0x001fbcf0 in assign_timezo
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>>Can you get a stack trace from the core dump?
>
>
>>(gdb) bt
>>#0 0x50377ba4 in memcpy () from /usr/lib/libc.so.34.2
>>#1 0x00326efc in hash_search ()
>>#2 0x00343430 in pg_tzset ()
>>#3 0x000
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> the machine had some issues a week ago or so - but it looks like the
> problem occured first here:
Hmm, what kind of issues, and are you sure they are fixed?
The stack trace looks to me like it is trying to apply the PGTZ setting
that's coming in
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>the machine had some issues a week ago or so - but it looks like the
>>problem occured first here:
>
>
> Hmm, what kind of issues, and are you sure they are fixed?
admin error :-).
I had a second postgresql instance running
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> anyway - here is the promised backtrace:
> #0 0x4489fba4 in memcpy () from /usr/lib/libc.so.34.2
> #1 0x00326f9c in hash_search (hashp=0xa6e030, keyPtr=0xa5ff90,
> action=HASH_ENTER, foundPtr=0x0) at dynahash.c:653
> #2 0x00
pl_funcs.c has a comment that refers to "functins," which I'm
assuming should be "functions." The attached patch corrects
the spelling.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
Index: src/pl/plpgsql/src/pl_funcs.c
===
RCS file: /
On Sat, 18 Jun 2005, Tom Lane wrote:
I've attached the 2PC patch as applied in case you want to have a look.
I did some fairly significant hacking on it, and I thought it'd be a
good idea to enumerate some of the changes:
I modified the in-memory data structure so that there is a separate
dumm
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> On Sat, 18 Jun 2005, Tom Lane wrote:
>> I'm not totally satisfied with this --- it's OK from a correctness
>> standpoint but the performance leaves something to be desired.
> Ouch, that really hurts performance.
> In typical 2PC use, the state file
On Sat, 18 Jun 2005, Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Can we figure out another way to solve the race condition? Would it
in fact be ok for the checkpointer to hold the TwoPhaseStateLock,
considering that it usually wouldn't be held for long, since usually the
chec
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> In step 3.1, is it safe to skip gxacts not marked as valid? The gxact is
> marked as valid after the prepare record is written to WAL. If checkpoint
> runs after the WAL record is written but before the gxact is marked as
> valid, it doesn't get f
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
I thought I would have a look at:
(Datatypes) Add function to return compressed length of TOAST data values.
My recollection of that discussion is that we just wanted something
that would return the actual VARSIZE() of the datum. You
Thanks, applied.
---
Michael Fuhr wrote:
> pl_funcs.c has a comment that refers to "functins," which I'm
> assuming should be "functions." The attached patch corrects
> the spelling.
>
> --
> Michael Fuhr
> http://www.fuh
Hi,
This patch allows the PL/Python module to do (SRF) functions.
The patch was taken from the CVS version.
I have modified the plpython.c file and have added a test sql script for
testing the functionality. It was actually the script that was in the
8.0.3 version but have since been removed.
Hi!
Bruce Momjian [2005-06-15 15:26 -0400]:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > The 'bind' calles in the binaries are going to look for the proper
> > > version. Does that help, or is libpq the only thing we need to
> > > handle?
> >
> > Shared libraries have their version n
The next iteration -
Hopefully I have got the idea basically right.
I wonder if I have done the "am I a varlena" the long way.., pls advise
if so!
Cheers
Mark
Tom Lane wrote:
My recollection of that discussion is that we just wanted something
that would return the actual VARSIZE() of the da
26 matches
Mail list logo