Hi all,
If there is nothing else wrong in our test case we noticed
the following:
We have done a test with two connections to the database on
different computers. After the first client (writer) had
inserted new data into a quite simple table, it told another
client (by TCP communication) to be
Yeb Havinga:
> [email protected] wrote:
[...]
> > We have done a test with two connections to the database
> > on different computers. After the first client (writer)
> > had inserted new data into a quite simple table, it told
> > another client (by TCP
Hi all,
I am using libpq 8.2.4 (and my own wrapper around it) for a
long time now. Due to some performance penalties I would
like to upgrade to 8.4.x libpq.
Is it o.k. if I upgraded my libpq to the newer 8.4
libraries but would still connect to old 8.2 servers?
Are there any compatibility issues
Hi all,
I have several databases here which I would like to update
from 8.2 to 8.4, which in turn requires a dump/restore.
However, the databases are OIDs depending, so, some values
depend on OIDs in other tables.
AFAIK the dump/restore does not rebuild the original OID
values, so all relations
Adrian Klaver:
> > AFAIK the dump/restore does not rebuild the original OID
> > values, so all relations built accross OIDs fail.
> >
> > (1)
> > Is there a way to keep the original OID values somehow?
>
> From here:
> http://www.postgresql.org/docs/8.4/interactive/app-pgdump.html
>
> -o
> --oid
Vick Khera:
> On Sat, Mar 13, 2010 at 4:33 PM, [email protected]
> wrote:
> > I am using libpq 8.2.4 (and my own wrapper around it) for a
> > long time now. Due to some performance penalties I would
> > like to upgrade to 8.4.x libpq.
> >
>
> What gives
Hi all,
I updated the server from 8.2 to 8.4, but I am still using
libpq 8.2 to write timestamps with the libpq C interface,
using the binary format and PQexecParams(). While pgAdmin in
8.2 server shows correct timestamps, 8.4 displays garbage
(year 15000 etc).
This has probably to do with the co
