Heikki Linnakangas writes:
> Simon Riggs wrote:
>> Do I really need to write a patch to say that, have you formally review
>> it, then change the wording to what you would have written in the first
>> place and then commit? Really?
> Yes. It's not a trivial change for me, you're much better at wr
Dave Page writes:
> I've been playing with this for the last couple of hours, to no avail.
> Looking at the log with PIDs, it certainly appears to be the crashing
> backend that calls the atexit callback. I can't get a backtrace though
> - if I attach the debugger before crashing, it breaks out at
On Fri, May 15, 2009 at 5:26 PM, Tom Lane wrote:
> Dave Page writes:
>> Couldn't the callback have been called by another process though?
>
> Hmm, maybe, if the messages got to the log out of order. Try
> reproducing it with %p added to log_line_prefix.
I've been playing with this for the last
On Fri, May 15, 2009 at 11:45 AM, wrote:
> Hi,
>
>
>
> We are trying to access the postgresql database through the Informatica
> power Center. Could you please give me the details about the installable
> ODBC driver for this database.
>
> Note :the Informatica powercenter has been installed in
On Fri, May 15, 2009 at 11:45 AM, wrote:
> Hi,
>
>
>
> We are trying to access the postgresql database through the Informatica
> power Center. Could you please give me the details about the installable
> ODBC driver for this database.
>
> Note :the Informatica powercenter has been installed in L
Hi,
We are trying to access the postgresql database through the Informatica
power Center. Could you please give me the details about the installable
ODBC driver for this database.
Note :the Informatica powercenter has been installed in Linux box.
Thanks,
Vikram sampath
Cognizant Tech
Simon Riggs wrote:
On Fri, 2009-05-15 at 18:46 +0300, Heikki Linnakangas wrote:
What exactly do you want to change? Patch, please.
I find this exchange between us quite strange. The discussion on this
thread has been fairly clear. Fujii-san and myself have both asked for
it to be documented th
On Fri, 2009-05-15 at 18:46 +0300, Heikki Linnakangas wrote:
> Well, we already have this in the docs:
>
> > Each time a new timeline is created, PostgreSQL creates a "timeline
> history" file that shows which timeline it branched off from and when.
> These history files are necessary to allow t
On Fri, 2009-05-15 at 11:19 -0400, Andrew Dunstan wrote:
> I don't mean that it has bugs. I mean that it's far too easy to get it
> wrong and far too hard to get it right. I have reduced my uses to a
> couple of cases where I have worked out, with some trial and error,
> recipes that I follow.
On Friday 15 May 2009 09:16:33 Peter Eisentraut wrote:
> On Friday 15 May 2009 01:07:11 Hershel Fisch wrote:
> > Hi, I realized that sorting date is done like text and not numeric
> > (dates) e.g. SELELCT * FROM database_name ORDER BY date ASC
> This report would make a lot more sense if you p
Thomas Johansson writes:
> (detaild log message from pg_log
> 2009-05-15 00:00:17.179 CEST> LOCATION: make_inh_translation_lists,
> prepunion.c:992
> 2009-05-15 00:00:17.179 CEST> STATEMENT:
> UPDATE state_change SET (final_view_time, end_time) =
> (226, 10528) WHERE id = 91332
Dave Page writes:
> Couldn't the callback have been called by another process though?
Hmm, maybe, if the messages got to the log out of order. Try
reproducing it with %p added to log_line_prefix.
> Anyhoo, here's the backtrace for the actual problem:
> ...
> perl510.dll!28028026()
>> p
On Fri, May 15, 2009 at 3:47 PM, Tom Lane wrote:
> Dave Page writes:
>> On Fri, May 15, 2009 at 3:23 PM, Tom Lane wrote:
>>> Ho, that's pretty curious. The first two messages are the trace of the
>>> atexit hook I recently installed, which means something called exit()
>>> or the moral equivale
Simon Riggs wrote:
On Fri, 2009-05-15 at 17:39 +0300, Heikki Linnakangas wrote:
We've asked for some additional docs. What would be the objection to
that?
I'm certainly not opposed to improving docs.
OK, so will you update the docs as requested?
Well, we already have this in the docs:
Ea
On Fri, May 15, 2009 at 11:13 AM, Hector Saldarriaga wrote:
>
> PLEASE TAKE ME OFF YOUR MAILING LIST. I DO NOT WANT ANY MORE OF YOUR
> PESTERING E-MAILS.
> THANK YOU. I´LL APPRECIATE IF YOU DON´T SEND ME ANY MORE MAILS. I DON´T
> NEED THEM.
>
To get on the list, you have to subscribe yourself
Simon Riggs wrote:
On Fri, 2009-05-15 at 10:17 -0400, Andrew Dunstan wrote:
This whole area is unfortunately way too fragile. We need some way of
managing these facilities that hides a lot of these details and is
therefore less likely to produce shot feet, IMNSHO. I get very nervous
ever
PLEASE TAKE ME OFF YOUR MAILING LIST. I DO NOT WANT ANY MORE OF YOUR PESTERING
E-MAILS.
THANK YOU. I´LL APPRECIATE IF YOU DON´T SEND ME ANY MORE MAILS. I DON´T NEED
THEM.
_
Drag n’ drop—Get easy photo sharing with Windows Live™ Pho
On Fri, 2009-05-15 at 10:17 -0400, Andrew Dunstan wrote:
> This whole area is unfortunately way too fragile. We need some way of
> managing these facilities that hides a lot of these details and is
> therefore less likely to produce shot feet, IMNSHO. I get very nervous
> every time I have to t
On Fri, 2009-05-15 at 17:39 +0300, Heikki Linnakangas wrote:
> > We've asked for some additional docs. What would be the objection to
> > that?
>
> I'm certainly not opposed to improving docs.
OK, so will you update the docs as requested?
--
Simon Riggs www.2ndQuadrant.com
Postgre
Dave Page writes:
> On Fri, May 15, 2009 at 3:23 PM, Tom Lane wrote:
>> Ho, that's pretty curious. The first two messages are the trace of the
>> atexit hook I recently installed, which means something called exit()
>> or the moral equivalent thereof. I wouldn't really expect that to
>> happen
Simon Riggs wrote:
On Fri, 2009-05-15 at 17:19 +0300, Heikki Linnakangas wrote:
Yes, just as deleting old WAL files.
So what you're saying is because it's possible to blow your left foot
off, we're not concerned about blowing your right foot off either.
I don't get it. What are the left and
On Fri, May 15, 2009 at 3:23 PM, Tom Lane wrote:
> Ho, that's pretty curious. The first two messages are the trace of the
> atexit hook I recently installed, which means something called exit()
> or the moral equivalent thereof. I wouldn't really expect that to
> happen in a crash situation ...
Fujii Masao wrote:
On Fri, May 15, 2009 at 8:56 PM, Heikki Linnakangas
wrote:
Fujii Masao wrote:
When only the history file for timeline 6 is deleted, timeline 6 would be
assigned as the newest one *again* at the end of archive recovery.
Is this safe?
If you delete history file and all the WA
On Fri, 2009-05-15 at 17:19 +0300, Heikki Linnakangas wrote:
> Yes, just as deleting old WAL files.
So what you're saying is because it's possible to blow your left foot
off, we're not concerned about blowing your right foot off either.
We've asked for some additional docs. What would be the ob
Simon Riggs wrote:
On Fri, 2009-05-15 at 22:56 +0900, Fujii Masao wrote:
OK, I probably understood your point. The timeline history files whose
timeline ID is larger than that of an oldest backup must not be deleted
from the archive. On the other hand, the smaller or equal one can be
deleted. N
Dave Page writes:
> CREATE LANGUAGE plperl; causes a backend crash on 8.4 with ActivePerl
> 5.10.0 (running on XP Pro). I'm testing this on beta 2 which I just
> rolled, however I believe this is probably the same issue that Kevin
> Field was reporting here:
> http://archives.postgresql.org/messag
Simon Riggs wrote:
On Fri, 2009-05-15 at 22:56 +0900, Fujii Masao wrote:
OK, I probably understood your point. The timeline history files whose
timeline ID is larger than that of an oldest backup must not be deleted
from the archive. On the other hand, the smaller or equal one can be
delet
Peter Eisentraut writes:
> On Friday 15 May 2009 01:07:11 Hershel Fisch wrote:
>> Hi, I realized that sorting date is done like text and not numeric (dates)
>> e.g. SELELCT * FROM database_name ORDER BY date ASC
>>
>> Return order
>>
>> 3/02/09
>> 4/19/09
>> 4/2/09
> This report would make a lo
On Fri, 2009-05-15 at 22:56 +0900, Fujii Masao wrote:
> OK, I probably understood your point. The timeline history files whose
> timeline ID is larger than that of an oldest backup must not be deleted
> from the archive. On the other hand, the smaller or equal one can be
> deleted. Not all histor
"Paul Mathews" writes:
> Despite the existence of the index, postgresql is determined to full table
> scan when given.
> SELECT
> postcode
> WHERE
> boundary @> point 'x,y';
polygon @> point isn't an indexable operator. The indexable operators
for a gist index on polygon are
<<(po
Hi,
On Fri, May 15, 2009 at 8:56 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>
>> On Fri, May 15, 2009 at 8:20 PM, Heikki Linnakangas
>> wrote:
>>>
>>> The probe in findNewestTimeLine() initialized to recovery target timeline
>>> +
>>> 1. It doesn't require history files for any old time
On Fri, 2009-05-15 at 15:34 +0200, Mikael Krantz wrote:
> On Fri, May 15, 2009 at 2:26 PM, Heikki Linnakangas
> wrote:
> > That was the original issue you ran into. That has now been fixed by forcing
> > an xlog switch at pg_start_backup(), so that you can't start a backup in a
> > WAL file that
On Fri, May 15, 2009 at 2:26 PM, Heikki Linnakangas
wrote:
> That was the original issue you ran into. That has now been fixed by forcing
> an xlog switch at pg_start_backup(), so that you can't start a backup in a
> WAL file that contains records from a lower numbered timeline.
Ah, sorry.
/M
-
On Fri, 2009-05-15 at 15:41 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2009-05-15 at 12:56 +0100, Simon Riggs wrote:
> >
> >> There is no particular reason to send history files to the archive,
> >> since new ones are only ever generated at the end of an archive
> >> recove
Hi,
On Fri, May 15, 2009 at 9:22 PM, Simon Riggs wrote:
>> If you delete history file and all the WAL for timeline 6, yeah, nothing
>> stops it from being reused. It will work just fine, as if it never
>> existed. If you still have the history file and WAL for the old timeline
>> 6 lying around s
Simon Riggs wrote:
On Fri, 2009-05-15 at 12:56 +0100, Simon Riggs wrote:
There is no particular reason to send history files to the archive,
since new ones are only ever generated at the end of an archive
recovery.
It also clears up a long standing confusion between backup history files
and t
The following bug has been logged online:
Bug reference: 4810
Logged by: Paul Mathews
Email address: p...@netspace.net.au
PostgreSQL version: 8.3.7
Operating system: Linux SuSE 11.0
Description:Complex Contains, Bad Performace.
Details:
Consider a table :
Postcode
Simon Riggs wrote:
ehem, "It will work fine" isn't correct, as Fujii-san observes.
What exactly are the steps required to run into that problem? I fail to
see what the problem is.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql
On Fri, May 15, 2009 at 2:22 PM, Simon Riggs wrote:
> Let's document that timeline files should not be deleted from the
> archive iff there exists a base backup made during a lower numbered
> timeline.
Or made during a higher numbered timeline which happens to start in a
WAL-file containing recor
Mikael Krantz wrote:
On Fri, May 15, 2009 at 2:22 PM, Simon Riggs wrote:
Let's document that timeline files should not be deleted from the
archive iff there exists a base backup made during a lower numbered
timeline.
Or made during a higher numbered timeline which happens to start in a
WAL-fi
Simon Riggs wrote:
On Fri, 2009-05-15 at 20:38 +0900, Fujii Masao wrote:
On Fri, May 15, 2009 at 8:20 PM, Heikki Linnakangas
wrote:
The probe in findNewestTimeLine() initialized to recovery target timeline +
1. It doesn't require history files for any old timelines to be present.
What if rec
The following bug has been logged online:
Bug reference: 4809
Logged by: Paul Matthews
Email address: p...@netspace.net.au
PostgreSQL version: 8.3.7
Operating system: Linux OpenSuse 11.0
Description:Missing Expected Operator
Details:
Not a bug as such, but an obviou
On Fri, 2009-05-15 at 14:56 +0300, Heikki Linnakangas wrote:
> Simon's idea of keeping a copy of all the history files in the data
> directory wouldn't help here. In fact, I think we already never delete
> history files in the server, it's just that if you omit the pg_xlog
> directory in the b
Fujii Masao wrote:
On Fri, May 15, 2009 at 8:20 PM, Heikki Linnakangas
wrote:
The probe in findNewestTimeLine() initialized to recovery target timeline +
1. It doesn't require history files for any old timelines to be present.
What if recovery_target_timeline = 'latest'? The unexpected (not l
On Fri, 2009-05-15 at 12:56 +0100, Simon Riggs wrote:
> There is no particular reason to send history files to the archive,
> since new ones are only ever generated at the end of an archive
> recovery.
It also clears up a long standing confusion between backup history files
and timeline history
On Fri, 2009-05-15 at 20:38 +0900, Fujii Masao wrote:
> On Fri, May 15, 2009 at 8:20 PM, Heikki Linnakangas
> wrote:
> > The probe in findNewestTimeLine() initialized to recovery target timeline +
> > 1. It doesn't require history files for any old timelines to be present.
>
> What if recovery_
Hi,
On Fri, May 15, 2009 at 8:20 PM, Heikki Linnakangas
wrote:
> The probe in findNewestTimeLine() initialized to recovery target timeline +
> 1. It doesn't require history files for any old timelines to be present.
What if recovery_target_timeline = 'latest'? The unexpected (not latest)
recover
On Fri, 2009-05-15 at 20:11 +0900, Fujii Masao wrote:
> Hi,
>
> On Fri, May 8, 2009 at 2:42 AM, Heikki Linnakangas
> wrote:
> > When you create a new base backup, you shouldn't need any files archived
> > before starting the backup.
>
> If so, this fix is not enough, since findNewestTimeLine()
Fujii Masao wrote:
Hi,
On Fri, May 8, 2009 at 2:42 AM, Heikki Linnakangas
wrote:
When you create a new base backup, you shouldn't need any files archived
before starting the backup.
If so, this fix is not enough, since findNewestTimeLine() is
still based on the premise that *all* the history
Hi,
On Fri, May 8, 2009 at 2:42 AM, Heikki Linnakangas
wrote:
> When you create a new base backup, you shouldn't need any files archived
> before starting the backup.
If so, this fix is not enough, since findNewestTimeLine() is
still based on the premise that *all* the history files exist.
So, a
Magnus? Ping?
On Tue, May 12, 2009 at 8:56 AM, Dave Page wrote:
> On Tue, May 12, 2009 at 2:17 AM, Krimstock, Roger I (Roger)
> wrote:
>>
>> Dave,
>> Should the installer be the user "postgres"? I've installed both as
>> "rik" (global domain) and "postgres" (local domain). Each time
>> install
CREATE LANGUAGE plperl; causes a backend crash on 8.4 with ActivePerl
5.10.0 (running on XP Pro). I'm testing this on beta 2 which I just
rolled, however I believe this is probably the same issue that Kevin
Field was reporting here:
http://archives.postgresql.org/message-id/200904171407.n3he7uri070
Tom Lane wrote:
What PG version are you using?
8.2.11
In 8.3 it seems to work automatically,
although in prior versions you could well have some problems with cached
plans not getting invalidated.
Any proposed workaround?
Would SELECTs be affected by this too?
(detaild log message from pg_
On Friday 15 May 2009 01:07:11 Hershel Fisch wrote:
> Hi, I realized that sorting date is done like text and not numeric (dates)
> e.g. SELELCT * FROM database_name ORDER BY date ASC
>
> Return order
>
> 3/02/09
> 4/19/09
> 4/2/09
>
> Thanks,
This report would make a lot more sense if you posted
Hi, I realized that sorting date is done like text and not numeric (dates)
e.g. SELELCT * FROM database_name ORDER BY date ASC
Return order
3/02/09
4/19/09
4/2/09
Thanks,
55 matches
Mail list logo
