On Wed, 14 Jan 2009, Bruce Momjian wrote:
This bug still exists in my testing.
We fixed all issues with ts_headline and will submit soon.
---
Tom Lane wrote:
"Denis Monsieur" writes:
The problem is a space being ad
I think not
(http://archives.postgresql.org/pgsql-hackers/2008-12/msg00126.php). The
return value of pg_stop_backup() is currently the same as
pg_switch_xlog()'s: the location of the last byte before the XLOG switch
+ 1. The proposed patch would remove the "+ 1". Seems like an
unnecessary API
The following bug has been logged online:
Bug reference: 4616
Logged by: Said Noucair
Email address: nouc...@gmail.com
PostgreSQL version: 8.3
Operating system: Suse 2.6
Description:Create Database with another encoding as the encoding
from postgres
Details:
Hi,
I
Said Noucair написа:
> The following bug has been logged online:
>
> Bug reference: 4616
> Logged by: Said Noucair
> Email address: nouc...@gmail.com
> PostgreSQL version: 8.3
> Operating system: Suse 2.6
> Description:Create Database with another encoding as the encod
Hi,
On Thu, Jan 15, 2009 at 9:09 PM, Heikki Linnakangas
wrote:
> I think not
> (http://archives.postgresql.org/pgsql-hackers/2008-12/msg00126.php). The
> return value of pg_stop_backup() is currently the same as
> pg_switch_xlog()'s: the location of the last byte before the XLOG switch +
> 1. The
Looking at the original post again:
The resulting *.backup file:
START WAL LOCATION: 10/FE1E2BAC (file 0002001000FE)
STOP WAL LOCATION: 10/FF00 (file 0002001000FF)
CHECKPOINT LOCATION: 10/FE1E2BAC
START TIME: 2008-11-09 01:15:06 CST
LABEL: /bck/db/sn200811090115.tar.
Fujii Masao wrote:
On Thu, Jan 15, 2009 at 9:09 PM, Heikki Linnakangas
wrote:
1. The proposed patch would remove the "+ 1". Seems like an unnecessary API
change, and I don't recall any reason why the new definition would be
better.
My patch doesn't change the return value of pg_stop_backup(),
Heikki Linnakangas writes:
> Fujii Masao wrote:
>> Only a part of backup
>> history file (the file name including stop wal location) is changed.
>> Currently, the file name is wrong if stop wal location indicates a boundary
>> byte. This would confuse the user, I think.
> Should we change it in H
The following bug has been logged online:
Bug reference: 4617
Logged by: Raymond L. Naseef
Email address: nas...@egr.msu.edu
PostgreSQL version: 8.3 & 7.4
Operating system: FreeBSD
Description:JDBC Drivers 8.2/8.3 return no ResultSet
Details:
Below is query using te
This has been fixed and will be in the next 8.3 minor release.
---
Tom Lane wrote:
> "Denis Monsieur" writes:
> > The problem is a space being added to text in the form of
> > http://some.url/path
> > Compare the output:
>
On Thu, 2009-01-15 at 11:15 -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Fujii Masao wrote:
> >> Only a part of backup
> >> history file (the file name including stop wal location) is changed.
> >> Currently, the file name is wrong if stop wal location indicates a boundary
> >> byte. T
Simon Riggs wrote:
>
> On Thu, 2009-01-15 at 11:15 -0500, Tom Lane wrote:
> > Heikki Linnakangas writes:
> > > Fujii Masao wrote:
> > >> Only a part of backup
> > >> history file (the file name including stop wal location) is changed.
> > >> Currently, the file name is wrong if stop wal location
On Thu, 2009-01-15 at 12:43 -0500, Bruce Momjian wrote:
> OK, do you have updated wording?
We are not changing the code, so Heikki's wording is appropriate since
it matches the code.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-b
John R Pierce wrote:
>
> aerkain wrote:
>> - It is Windows Vista Business.
>> - ..\PostgreSQL\8.3\data is existing and empty.
>> - during uninstallation postgre has reported an error: unable to stop
>> service
>> - I have deleted PostgreSQL directiory (after uninstall), but when I try
>> to
>>
Under a heavy load of NOTIFY events, entries in the pg_listener table
for some events are deleted, effectively acting as though UNLISTEN were
called.
I have only been able to make this occur on a PostgreSQL server running
on Windows. I cannot reproduce under Linux.
PostgreSQL version: 8.3.4
Heikki has updated the documentation to mention the meaning of this
field. Thanks for the report.
---
Fujii Masao wrote:
> On Fri, Dec 5, 2008 at 11:41 PM, Randy Isbell wrote:
> >
> > The following bug has been logged onli
Fujii Masao writes:
> Currently, stop wal filename is not always exclusive. If stop wal location
> doesn't indicate a boundary byte, its filename is inclusive. I'm afraid that
> the users cannot easily judge which "filename - 1" or "filename" should be
> waited. I mean that the users need to calcu
Hi,
On Fri, Jan 16, 2009 at 11:42 AM, Tom Lane wrote:
> It's really not worth changing the file contents. We're far more likely
> to hear complaints like "you broke my archive script and I lost all my
> data" than compliments about "the contents of this internal
> implementation file are lots mo
"Marshall, Steve" writes:
> Under a heavy load of NOTIFY events, entries in the pg_listener table
> for some events are deleted, effectively acting as though UNLISTEN were
> called.
> I have only been able to make this occur on a PostgreSQL server running
> on Windows.
AFAICS the most likely
Hi,
On Fri, Jan 16, 2009 at 12:23 AM, Heikki Linnakangas
wrote:
>> Only a part of backup
>> history file (the file name including stop wal location) is changed.
>> Currently, the file name is wrong if stop wal location indicates a
>> boundary
>> byte. This would confuse the user, I think.
>
> Hmm
20 matches
Mail list logo