> > Oops. That's a detail I left out. I can only reproduce this
> > problem so far
> > in PGAdmin. I couldn't reproduce the error in psql or in a
> > linked table in
> > MSAccess.
>
> Turn on query logging so you can see exactly what query PGAdmin is
> issuing to provoke the error. There isn't any
Martijn van Oosterhout writes:
> I think the issue here is that transaction begin is not when you type
> "begin" but at your first actual query. You can obviously only start a
> transaction once you know what serialisation level you want, and you
> don't see that till after the begin.
Right, the
"Bill Eaton" <[EMAIL PROTECTED]> writes:
> Oops. That's a detail I left out. I can only reproduce this problem so far
> in PGAdmin. I couldn't reproduce the error in psql or in a linked table in
> MSAccess.
Turn on query logging so you can see exactly what query PGAdmin is
issuing to provoke the e
On Wednesday 28. June 2006 21:33, Karsten Hilbert wrote:
>On Wed, Jun 28, 2006 at 06:25:22PM +0200, Leif B. Kristensen wrote:
>> >> event_date CHAR(18) NOT NULL DEFAULT
>>
>> The event_date field is a "fuzzy date" construct. It will allow the
>> storage of such dates as "1784", "ca. 18
On Wed, Jun 28, 2006 at 14:48:01 -0400,
Brad Nicholson <[EMAIL PROTECTED]> wrote:
> I'm seeing something fairly unintuitive about serializable transactions.
>
> "When a transaction is on the serializable level, a SELECT query sees
> only data committed before the transaction began; it never sees
self-replying with additional information
On Wed, Jun 28, 2006 at 09:33:18PM +0200, Karsten Hilbert wrote:
> A "full-blown" implementation of a fuzzy timestamp type which
>
> a) preserves the input/update timestamp
which tagged_types is able to handle
> b) allows setting the accuracy of the val
On Wed, Jun 28, 2006 at 06:25:22PM +0200, Leif B. Kristensen wrote:
> >> event_date CHAR(18) NOT NULL DEFAULT
> The event_date field is a "fuzzy date" construct. It will allow the
> storage of such dates as "1784", "ca. 1810", "May 1852", "1798 or
> 1799", "between 1820 and 1830" a
On Wed, Jun 28, 2006 at 02:48:01PM -0400, Brad Nicholson wrote:
> I'm seeing something fairly unintuitive about serializable transactions.
>
> Taking the following test case:
> http://www.postgresql.org/docs/8.1/interactive/transaction-iso.html
>
> "When a transaction is on the serializable le
I have an insert/update/delete trigger on all my tables which add data
to a log table.
I would like to be able to disable them when the tables are called from
one stored proceedure I have. Yet I would still like those triggers to
fire on any other operation that is happening concurrently. Is thi
I'm seeing something fairly unintuitive about serializable transactions.
Taking the following test case:
CREATE TABLE foo (id integer);
t1 t2
-- BEGIN;
-- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
INSERT INTO foo (id) --
V
> > I'm trying to migrate a database cluster from one server to
> another. So I
> > did a pg_dumpall, ported everything over, yada yada yada.
> >
> > I have one particular schema in one particular database that is
> giving me
> > trouble. All names for tables, sequences, functions, etc. are
> lower
On Wed, Jun 28, 2006 at 09:02:04AM -0700, Bill Eaton wrote:
> I'm trying to migrate a database cluster from one server to another. So I
> did a pg_dumpall, ported everything over, yada yada yada.
>
> I have one particular schema in one particular database that is giving me
> trouble. All names for
On Wednesday 28. June 2006 17:37, David Fetter wrote:
>On Wed, Jun 28, 2006 at 05:14:42PM +0200, Leif B. Kristensen wrote:
>> On a tangent to the never-ending NULL debate, I've got a table:
>>
>> CREATE TABLE events (
>> event_idINTEGER PRIMARY KEY,
>> tag_fk INTEGE
I'm trying to migrate a database cluster from one server to another. So I
did a pg_dumpall, ported everything over, yada yada yada.
I have one particular schema in one particular database that is giving me
trouble. All names for tables, sequences, functions, etc. are lowercase. I
repeat: everythin
On Sun, Jun 25, 2006 at 03:14:41PM -0400, brian ally wrote:
> My question is, can i safely run my modifications again, but swap out
> the INSERTs for the COPY WITH OIDs bit from the dump (adding my new
> INSERTs after)? Would those OIDs still be "good", so to speak?
Probably.
> ANY advice appr
On Fri, Jun 23, 2006 at 02:00:38PM -0400, Joseph Shraibman wrote:
> I like to make sure the vacuum takes place during off peak times, which
> is why I don't use autovacuum.
FWIW, now that there's vacuum_cost_delay that's usually not a very good
strategy. If you have anywhere close to enough load
On Wed, Jun 28, 2006 at 05:14:42PM +0200, Leif B. Kristensen wrote:
> On a tangent to the never-ending NULL debate, I've got a table:
>
> CREATE TABLE events (
> event_idINTEGER PRIMARY KEY,
> tag_fk INTEGER REFERENCES tags (tag_id),
> place_fkINTEG
On a tangent to the never-ending NULL debate, I've got a table:
CREATE TABLE events (
event_idINTEGER PRIMARY KEY,
tag_fk INTEGER REFERENCES tags (tag_id),
place_fkINTEGER REFERENCES places (place_id),
event_date CHAR(18) NOT NULL DEFAU
On Wed, Jun 28, 2006 at 02:43:03AM -0700, [EMAIL PROTECTED] wrote:
> 'Scuse my broken english and ungrammatical gibberish in my last
> missive. That's what I get for posting before my first cup of
> coffee for the day.
>
> I'm serious about nulls though, and am wondering if Date and Pascal,
> per
This reminds me of my favorite Bertrand Russell quote:
"The difference between theory and practice is: in theory there is no
difference, but in practice, there is"
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Florian G. Pflug
Sent: Wednesday, June 28,
On Wed, Jun 28, 2006 at 02:31:20AM -0700, [EMAIL PROTECTED] wrote:
> Date and Pascal hate nulls. One even goes so far as to say that if
> you permit NULLs in a database, then the results from *every* query
> is suspect. So they turn perform backflips suggesting ways to avoid
> nulls. None, so fa
On Wed, Jun 28, 2006 at 10:43:26AM -0400, A.M. wrote:
> NULL is nothing more than a shortcut. SQL logic has to do backflips to
> accomodate it- notice how NULL!=NULL- indeed, one NULL can mean a variety
> of things even in the same context! ("Bob doesn't know","HR doesn't
> know","No one cares","No
zhicheng wang <[EMAIL PROTECTED]> writes:
> the computer was shutdown properly. then the user
> restarted the computer, in the middle of rebooting, he
> switched off the power button on the wall. after that
> we cannot start the database server any more. the
> following is the log. please help.
Yo
On Wed, June 28, 2006 5:31 am, [EMAIL PROTECTED] wrote:
> Date and Pascal hate nulls. One even goes so far as to say that if you
> permit NULLs in a database, then the results from *every* query is suspect.
> So they turn perform backflips suggesting ways to avoid nulls.
> None, so far, seem appeal
Martijn van Oosterhout writes:
> The input functions get it, the output functions (bpcharout,
> bpcharsend, etc) don't. Which makes it kind of hard to print a raw
> value if you don't know how long it's going to be. They used to, but
> that was removed some time back.
Even back then you couldn't
--- Andrew Gould <[EMAIL PROTECTED]> wrote:
> --- Berend Tober <[EMAIL PROTECTED]> wrote:
>
> > Florian G. Pflug wrote:
> > > [EMAIL PROTECTED] wrote:
> > >
> > >> Date and Pascal hate nulls.
> > >
> > > ...the functions described by those functional
> > dependencies are
> > > not require
On Wed, Jun 28, 2006 at 01:56:47PM +0200, Thomas Hallgren wrote:
> A user that is trusted with installing a C-function in the backend is
> free to scan the process memory anyway so in what way did that increase
> the security? IMHO, the only relevant security in that context is to
> have trusted
--- Berend Tober <[EMAIL PROTECTED]> wrote:
> Florian G. Pflug wrote:
> > [EMAIL PROTECTED] wrote:
> >
> >> Date and Pascal hate nulls.
> >
> > ...the functions described by those functional
> dependencies are
> > not required to be defined for every possible
> value - let's say you have
>
Berend Tober wrote:
Florian G. Pflug wrote:
> [EMAIL PROTECTED] wrote:
>
>> Date and Pascal hate nulls.
>
> ...the functions described by those functional dependencies are
> not required to be defined for every possible value - let's say you have
> a function dependency A -> B - meaning th
Florian G. Pflug wrote:
> [EMAIL PROTECTED] wrote:
>
>> Date and Pascal hate nulls.
>
> ...the functions described by those functional dependencies are
> not required to be defined for every possible value - let's say you have
> a function dependency A -> B - meaning that whenever you know the val
Hi,
On Wed, 2006-06-28 at 18:20 +0530, surabhi.ahuja wrote:
> failed dependency librealdline.so.5 is needed by
> postgresql-8.1.4-1PGDG.i686.rpm
yum install readline
Regards,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Developmen
[EMAIL PROTECTED] wrote:
Date and Pascal hate nulls. One even goes so far as to say that if you
permit NULLs in a database, then the results from *every* query is
suspect. So they turn perform backflips suggesting ways to avoid nulls.
None, so far, seem appealing.
To me, nulls are quite useful i
Title: Re: [GENERAL] planning to upgrade to 8.1
i have 4 rpms
i first install
compat-postgresql-libs-3-3PGDG.i686.rpm
then i install
postgresql-libs-8.1.4-1PGDG.i686.rpm
the i install
postgresql-8.1.4-1PGDG.i686.rpm
here i get an error it says
failed dependency
librealdline.so.5 is n
Thanks all for the reply.
Once pg_hba.conf is modified, do I have to run
pg_ctl reload ?
James
louis gonzales wrote:
> James,
> the "psql" command as you know is just the command line program that
> requests connection to a database and depending how you issue the
> command, determines if it's at
'Scuse my broken english and ungrammatical gibberish in my last
missive. That's what I get for posting before my first cup of coffee
for the day.
I'm serious about nulls though, and am wondering if Date and Pascal,
perhaps, are the gibberish ones on this particular issue. The
insistence on no null
Date and Pascal hate nulls. One even goes so far as to say that if you
permit NULLs in a database, then the results from *every* query is
suspect. So they turn perform backflips suggesting ways to avoid nulls.
None, so far, seem appealing.
To me, nulls are quite useful in the Real World. For insta
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 12:03:40PM +0200, Thomas Hallgren wrote:
OK. I thought you always had a type descriptor handy when reading the
binary representation. I've noticed that the typmod is expected in some
receive functions (bpcharrecv and numeric_recv for inst
dear all
we have the following issues and cannot start the
postgresql server:
postgresql 8.0.5
redhat EL WS4 U3
the computer was shutdown properly. then the user
restarted the computer, in the middle of rebooting, he
switched off the power button on the wall. after that
we cannot start the data
On Wed, Jun 28, 2006 at 12:03:40PM +0200, Thomas Hallgren wrote:
> OK. I thought you always had a type descriptor handy when reading the
> binary representation. I've noticed that the typmod is expected in some
> receive functions (bpcharrecv and numeric_recv for instance). Are you
> saying that
On Tue, Jun 27, 2006 at 01:43:21PM +0200, Christian Rengstl wrote:
> i am in the middle of breaking my head over designing a
> database and came to the following question/problem: i have
> persons whose values (integer) have to be entered in the db,
> but per person the amount of values ranges fro
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 10:22:45AM +0200, Thomas Hallgren wrote:
Thanks. That would of course work but at the same time it increases the
complexity of my app. Yet another component to install and keep track
of. It's also a bit of an overkill since the only thing I
How much I/O Performance do you need ?
READ Performance ? Write Performance ?
I need an fast and reliable RAID Controller (harddisks have to be hot plug,
automatic rebuild etc.)
and I have to say that the HP DL 380 G 4 with Battery Backup Write Cache ,
FAST U320 HDs,
some gigs ram (chipkill is a
On Wed, Jun 28, 2006 at 10:22:45AM +0200, Thomas Hallgren wrote:
> Thanks. That would of course work but at the same time it increases the
> complexity of my app. Yet another component to install and keep track
> of. It's also a bit of an overkill since the only thing I need is an
> opaque bit s
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 09:01:49AM +0200, Thomas Hallgren wrote:
I'm building an app where I have several entities that are identified
using a UUID (i.e. a 128 bit quantity). My current implementation uses a
composite primary key consisting of two int8 values. I
On Wed, Jun 28, 2006 at 01:52:10AM -0600, Pat Maddox wrote:
> I end up calling this query quite often, so I need a way to speed it
> up. Don't know if I can take advantage of indexes or better joins or
> something (I don't even know if there are better joins), I'm really a
> newbie to DB stuff. H
I end up calling this query quite often, so I need a way to speed it
up. Don't know if I can take advantage of indexes or better joins or
something (I don't even know if there are better joins), I'm really a
newbie to DB stuff. Hoping somebody can help me make this much
quicker.
EXPLAIN ANALYZ
On Wed, Jun 28, 2006 at 09:01:49AM +0200, Thomas Hallgren wrote:
> I'm building an app where I have several entities that are identified
> using a UUID (i.e. a 128 bit quantity). My current implementation uses a
> composite primary key consisting of two int8 values. It's a bit
> cumbersome and I
I'm building an app where I have several entities that are identified
using a UUID (i.e. a 128 bit quantity). My current implementation uses a
composite primary key consisting of two int8 values. It's a bit
cumbersome and I would much rather have a distinct type. An earlier
implementation using
48 matches
Mail list logo
