On Sun, 2007-03-18 at 07:39 -0700, Randy Isbell (jisbell) wrote:
Tom Lane [EMAIL PROTECTED] writes:
BTW, the backup process is supposed to result in backup_label being
present in the filesystem dump, so that you'd have had to go out of
your
way for it to NOT be present (which is why we
On Wed, Jun 04, 2008 at 01:58:19PM -0700, Lon Varscsak wrote:
Wow, I want it to violate the spec so I can get my rows back! :)
I understand the problem and why it did what it did now though.
you might find this post also helpful (for future):
Simon Riggs [EMAIL PROTECTED] writes:
I would like to introduce a WARNING message into recovery to show that a
backup_label was expected, yet was not present. This is normal in some
use cases of recovery, but we need to be able to tell those situations
apart. Any objections?
Given that the
On Thu, 2008-06-05 at 10:59 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I would like to introduce a WARNING message into recovery to show that a
backup_label was expected, yet was not present. This is normal in some
use cases of recovery, but we need to be able to tell
Simon Riggs [EMAIL PROTECTED] writes:
* In the release note comments, add that in a future release we will add
a parameter to recovery.conf require_backup_label which defaults to
true.
The problem that I'm having with that idea is that it breaks
crash-recovery after replay starts, because we
Please keep the list cc'd so that others can help you out.
Parag Goyal wrote:
Actually my client-server application is using default database postgres and
using 39 tables. Out of thase one table is 'eventregistration' created by
hibernate automatically.
Some how we got stuck and tried delete
[ please keep the mailing list cc'd ]
Nathan Reed [EMAIL PROTECTED] writes:
Here is the dump of the config.log file in the pertinent area:
configure:19839: checking test program
configure:19854: gcc -o conftest -O2 -Wall -Wmissing-prototypes
-Wpointer-arith -Winline
On Thu, 2008-06-05 at 11:39 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
* In the release note comments, add that in a future release we will add
a parameter to recovery.conf require_backup_label which defaults to
true.
The problem that I'm having with that idea is that
Tom,
LD_LIBRARY_PATH is the correct env var to use. However, you are
correct that this hamstrings the generated executable - requiring
that the LD_LIBRARY_PATH include all of the shared object libraries
in the rc scripts themselves.
Regarding the possibility of a bug, I had indicated
The following bug has been logged online:
Bug reference: 4224
Logged by: Lawrence Cohan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: red hat 4.1.1-52
Description:issue with LIMIT and ORDER BY
Details:
Following queries run FOREVER in
On Thu, Jun 05, 2008 at 06:15:29PM +, Lawrence Cohan wrote:
Following queries run FOREVER in PG if an index exists on the id column
which is a integer - serial and PKey on the table.
SELECT id FROM orders WHERE merchant_id = xx ORDER BY id DESC LIMIT 31
-- or 30, 29, 28, 27, 26, 25
Many thanks for the quick reply and suggestion! Indeed we do have many
records in these tables - 20/50 million rows, and we do have index on
merchant_id already which is a NOT NULLable column as well. In my
opinion the duplicate index we have on the id column which is a
NONCLUSTERED Pkey as well
Frank Millman wrote:
1. If making a backup, make sure that your database is being updated.
This should say *not* being updated.
Fixed, thanks.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Dave Page wrote:
On Mon, May 26, 2008 at 10:01 AM, Daniel Migowski [EMAIL PROTECTED] wrote:
Entered Umlauts aren't correctly received by your script responsible for the
form at:
http://www.postgresql.org/support/submitbug
This might be a problem for entering encoding related
Alvaro Herrera [EMAIL PROTECTED] writes:
It does have a problem, because the email sent does not contain a
charset header. It does look OK for me too -- as long as I use a UTF8
terminal. The fix is easy, just add this line to the message headers:
Content-Type: text/plain; charset=utf-8
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
It does have a problem, because the email sent does not contain a
charset header. It does look OK for me too -- as long as I use a UTF8
terminal. The fix is easy, just add this line to the message headers:
Content-Type:
Tom Lane [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
It does have a problem, because the email sent does not contain a
charset header. It does look OK for me too -- as long as I use a UTF8
terminal. The fix is easy, just add this line to the message headers:
(please keep the mailing list CC'd)
Parag Goyal wrote:
As i told earlier some how i got stuck ,so i was dropping the
database but eventregistration table was not deleted due to ERROR: Cache
lookup failed for relation .
but after ward i check with defferent queries (select,insert also) on same
18 matches
Mail list logo
