"lou fridkis" writes:
> The problem is that the values for loutest1_lou_id_seq are different
> after the test:
This is expected. The slave may have a larger value than the primary.
It's because of the way that WAL logging for nextval() works.
regards, tom lane
--
Sent
The following bug has been logged online:
Bug reference: 5882
Logged by: lou fridkis
Email address: lfrid...@earthlink.net
PostgreSQL version: 9.0
Operating system: linux
Description:last_value of sequence on replicated properly
Details:
I am testing pg9 hot standby
"muthu" wrote:
> PostgreSQL version: 9.0.2
> Operating system: unbuntu 8.0
> Description:postgres query tuning
> Details:
>
> steps for postgres query tuning and postgres.conf files for 64gb
> ram...
>
> where i can recovery db using only data folder.
This is not a bug report. Pl
Hi,
the problem still exists in the 9.0.3 package provided by EnterpriseDB:
psql (9.0.3)
Type "help" for help.
Cannot read termcap database;
using dumb terminal settings.
Aborted
I've done some analysis:
- libtermcap is provided in the 9.0.3 package
- What is missing is the "termcap database"
The following bug has been logged online:
Bug reference: 5881
Logged by: muthu
Email address: dbamu...@gmail.com
PostgreSQL version: 9.0.2
Operating system: unbuntu 8.0
Description:postgres query tuning
Details:
steps for postgres query tuning and postgres.conf file
Tom Lane writes:
> Maybe you can duplicate the problem with a synthesized or anonymized
> data set? It's unlikely anybody will spend much time on such a vague
> report as this.
I reloaded the same data set overnight, and I could not reproduce the
error (which was present in one in 3.6 million r
Just checking back to see if there have been any updates on this.
Thanks!
Gabe
Apparently my colleague downloaded and installed a tarball of GNU
> termcap 1.3.1.
>
> I'm still not clear how this passed our internal testing though; I'm
> guessing the QA test VMs do have some package on them which
