Re: [BUGS] BUG #4562: ts_headline() adds space when parsing url
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 added to text in the form of
http://some.url/path
Compare the output:
shs=# SELECT ts_headline('http://some.url', to_tsquery('sometext'));
ts_headline
-
http://some.url
(1 row)
shs=# SELECT ts_headline('http://some.url/path', to_tsquery('sometext'));
ts_headline
---
http:// some.url/path
(1 row)
I looked into this, and it seems that the problem is that
generateHeadline() emits a space for any token marked as replace = 1.
I think it probably shouldn't emit anything at all. AFAICS the cases
where replace will get set are token types URL, TAG, NUMHWORD,
ASCIIHWORD, HWORD. For URL and the HWORD variants the space is
certainly undesirable, because these token types are just respecifying
text that is also covered by their component tokens. The only case
where you could make an argument that the space is useful is TAG,
as in
regression=# SELECT ts_headline('httpblah', to_tsquery('sometext'));
ts_headline
-
http blah
(1 row)
But it seems to me to be at least as plausible that you should get
nothing as that you should get a space for a removed tag.
Comments?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: o...@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
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 change, and I don't recall any reason why the new
definition would be better.
A fix for the broken waiting behavior discussed in that thread was
committed.
Bruce Momjian wrote:
Would someone please tell me if this should be applied?
---
Fujii Masao wrote:
On Fri, Dec 5, 2008 at 11:41 PM, Randy Isbell wrote:
The following bug has been logged online:
Bug reference: 4566
Logged by: Randy Isbell
Email address: jisb...@cisco.com
PostgreSQL version: 8.3.4
Operating system: FreeBSD 6.2
Description:pg_stop_backup() reports incorrect STOP WAL LOCATION
Details:
An inconsistency exists between the segment name reported by
pg_stop_backup() and the actual WAL file name.
SELECT pg_start_backup('filename');
pg_start_backup
-
10/FE1E2BAC
(1 row)
Later:
SELECT pg_stop_backup();
pg_stop_backup
10/FF00
(1 row)
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.gz
STOP TIME: 2008-11-09 01:15:48 CST
In my 8.3.4 instance, WAL file naming occurs as:
...
0001000300FD
0001000300FE
00010004
000100040001
...
WAL files never end in 'FF'. This causes a problem when trying to collect
the ending WAL file for backup.
It's a bug of pg_stop_backup(), which has been talked before.
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00108.php
Attached is a patch against HEAD. I think that we should
also backport.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
[ Attachment, skipping... ]
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4616: Create Database with another encoding as the encoding from postgres
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 tried to create a second database other than postgres with different encoding "WIN", but it keep gave me errors: Error: encoding WIN does not match server's locale UTF-8 > DETAIL: The server's LC_CTYPE setting requires encoding... Any hint? Regards -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #4616: Create Database with another encoding as the encoding from postgres
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 encoding > from postgres > Details: > > Hi, > > I tried to create a second database other than postgres with different > encoding "WIN", but it keep gave me errors: > Error: encoding WIN does not match server's locale UTF-8 >> DETAIL: The server's LC_CTYPE setting requires encoding... > > Any hint? Known restriction: "Any character set encoding specified for the new database must be compatible with the server's LC_CTYPE locale setting." (http://www.postgresql.org/docs/current/static/sql-createdatabase.html). -- Milen A. Radev -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
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 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(), it's still the same as the return value of pg_switch_xlog(). 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. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
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.gz STOP TIME: 2008-11-09 01:15:48 CST In my 8.3.4 instance, WAL file naming occurs as: ... 0001000300FD 0001000300FE 00010004 000100040001 ... WAL files never end in 'FF'. This causes a problem when trying to collect the ending WAL file for backup. I can see the potential confusion here. START WAL LOCATION is an inclusive value, while STOP WAL LOCATION is exclusive. You need to archive all WAL files < STOP WAL LOCATION to have a valid backup, not <=. Printing the filenames adds to the confusion. Perhaps if we printed them like "files 0002001000FE <= X < 0002001000FF" the intention would be clearer, but we can't change the format now without braking all existing backups. In 8.4, this will be less of an issue, because pg_stop_backup() now waits for the last file to be archived before returning, so you don't have to look at those values to implement the waiting yourself. In the passing, I notice that the manual says for pg_xlog_switch(): pg_switch_xlog moves to the next transaction log file, allowing the current file to be archived (assuming you are using continuous archiving). The result is the ending transaction log location within the just-completed transaction log file. If there has been no transaction log activity since the last transaction log switch, pg_switch_xlog does nothing and returns the end location of the previous transaction log file. That's incorrect. According comments in RequestXLogSwitch(), what it actually returns is: * The return value is either the end+1 address of the switch record, * or the end+1 address of the prior segment if we did not need to * write a switch record because we are already at segment start. Note that "end+1 address of the prior segment" is the same as "first byte of the *next* segment", which contradicts with the manual. I'll change that paragraph in the manual into: The result is the ending transaction log location *+ 1* within the just-completed transaction log file. If there has been no transaction log activity since the last transaction log switch, pg_switch_xlog does nothing and returns the *start* location of the transaction log file *currently in use*. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
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(), it's still the same as the return value of pg_switch_xlog(). Oh, ok. 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, I guess that would make it less confusing. Seems quite dangerous to change the meaning now, however :-(. A program (or person) that knows its current meaning would currently wait for STOP WAL filename - 1 file to be archived. If we change the meaning, the same program would determine that the backup is safe, even if the last xlog file hasn't yet been archived. So I think this is not back-portable. Should we change it in HEAD? I'm leaning towards no, on the grounds that tools/people would then have to know the version it's dealing with to interpret the value correctly, and because pg_stop_backup() now waits for the last xlog file to be archived before returning, there's little need to look at that file. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
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 HEAD? I'm leaning towards no, on the grounds that > tools/people would then have to know the version it's dealing with to > interpret the value correctly, and because pg_stop_backup() now waits > for the last xlog file to be archived before returning, there's little > need to look at that file. I agree. It might have been better to define it the other way originally, but the risks of changing it now outweigh any likely benefit. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4617: JDBC Drivers 8.2/8.3 return no ResultSet
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 temporary table instead of "IN" to greatly improve
performance. This worked in older JDBC driver, but no longer does. The
following were checked, making no difference:
1) Removed from query:
CREATE UNIQUE INDEX lookup_username_idx
ON lookup_username
USING btree
(username);
2) Setting auto-commit (checked with false and true, and unset).
Servers:
PostgreSQL 7.4.19 on amd64-portbld-freebsd7.0, compiled by GCC cc (GCC)
4.2.1.20070719 [FreeBSD]
PostgreSQL 8.3.5 on amd64-portbld-freebsd7.0, compiled by GCC cc (GCC)
4.2.1.20070719 [FreeBSD]
JDBC Drivers:
Result Driver
== ===
WORKpg74.216.jdbc3.jar
FAILpostgresql-8.2-506.jdbc3.jar
FAILpostgresql-8.3-604.jdbc3.jar
This was tested using AutoCommit default and false, using EITHER A or B:
PreparedStatement ps = connection.prepareStatement([shown_below]);
[ A ]
ps.execute();
ResultSet rs = ps.getResultSet();
RESULT:
rs == null
[ B ]
ResultSet rs = ps.executeQuery();
RESULT:
org.postgresql.util.PSQLException: No results were returned by the
query.
QUERY:
--
create temporary table lookup_username (username varchar) on commit drop;
insert into lookup_username values ('naseef');
CREATE UNIQUE INDEX lookup_username_idx
ON lookup_username
USING btree
(username);
SELECT enp.username, trim(enp.full_name)
FROM egr_nis_person as enp
JOIN lookup_username as lu
ON lu.username = enp.username
WHERE enp.start_date < now() + interval '30 seconds'
AND enp.end_date > now() + interval '30 seconds';
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4562: ts_headline() adds space when parsing url
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:
>
> > shs=# SELECT ts_headline('http://some.url', to_tsquery('sometext'));
> >ts_headline
> > -
> > http://some.url
> > (1 row)
>
> > shs=# SELECT ts_headline('http://some.url/path', to_tsquery('sometext'));
> > ts_headline
> > ---
> > http:// some.url/path
> > (1 row)
>
> I looked into this, and it seems that the problem is that
> generateHeadline() emits a space for any token marked as replace = 1.
> I think it probably shouldn't emit anything at all. AFAICS the cases
> where replace will get set are token types URL, TAG, NUMHWORD,
> ASCIIHWORD, HWORD. For URL and the HWORD variants the space is
> certainly undesirable, because these token types are just respecifying
> text that is also covered by their component tokens. The only case
> where you could make an argument that the space is useful is TAG,
> as in
>
> regression=# SELECT ts_headline('httpblah', to_tsquery('sometext'));
> ts_headline
> -
> http blah
> (1 row)
>
> But it seems to me to be at least as plausible that you should get
> nothing as that you should get a space for a removed tag.
>
> Comments?
>
> regards, tom lane
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
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. This would confuse the user, I think. > > > Should we change it in HEAD? I'm leaning towards no, on the grounds that > > tools/people would then have to know the version it's dealing with to > > interpret the value correctly, and because pg_stop_backup() now waits > > for the last xlog file to be archived before returning, there's little > > need to look at that file. > > I agree. It might have been better to define it the other way > originally, but the risks of changing it now outweigh any likely > benefit. Agreed. It's too confusing the other way. The manual entry wasn't changed from my original submission unfortunately. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
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 indicates a > > >> boundary > > >> byte. This would confuse the user, I think. > > > > > Should we change it in HEAD? I'm leaning towards no, on the grounds that > > > tools/people would then have to know the version it's dealing with to > > > interpret the value correctly, and because pg_stop_backup() now waits > > > for the last xlog file to be archived before returning, there's little > > > need to look at that file. > > > > I agree. It might have been better to define it the other way > > originally, but the risks of changing it now outweigh any likely > > benefit. > > Agreed. It's too confusing the other way. > > The manual entry wasn't changed from my original submission > unfortunately. OK, do you have updated wording? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect 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-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Installation problem "...The database cluster initialization failed.."
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 >> install it still display message that "The database cluster >> initialisation >> failed." >> > > to clean up a old/failed postgres install on windows... > > * delete the postgres user, via command line NET USER POSTGRES /DELETE > * delete the postgres 'service', via command line SC DELETE PGSQL-8.3 > * delete the directories as you did. > > > (command lines can (should?) be all lower case, i just capitalized them > to make it clear they were commands). older versions use different > service names... try > > sc query | find "pg" > > to get the service name for the `sc delete` command... > > now, you should be able to clean install postgres > > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > > I had the same problem! I found a way to go a step further by checking the security one the data directory. It appears that the install process create the data folder using login you're currently logon. But it tried to access it using the postgres login that doesn't have any right on that directory. I had the "Full control" permission to postgres on the data directory and I went a step further. Haven't found the way to get the install all the way and I cannot start the service yet. I have a windows 2003 server SP1 running has a standalone machine (Not connected to a domain controler). Hope it will help getting forward to a solution. Regards, Francis -- View this message in context: http://www.nabble.com/Installation-problem-%22...The-database-cluster-initialization-failed..%22-tp21343831p21487626.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] pg_listener entries deleted under heavy NOTIFY load only on Windows
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
Operating System: Windows XP
I have provided some shell script that can reproduce the problem. It
helps to use three psql sessions.
First start a session that listens for two events ("first" and
"second"), then periodically polls for notifications:
check_for_events | psql -h windows_server -U postgres postgres
Second, start an interactive session and execute the command "SELECT *
from pg_listener". You should see the events "first" and "second" listed.
Third, start a session to do repeated notification. The script produces
"NOTIFY first" and "NOTIFY second" in separate transactions repeatedly.
generate_events | psql -h windows_server -U postgres postgres
Continue to check the pg_listener table in the interactive session.
Very quickly one of the two events will disappear from the table.
Strangely, when I execute the same scripts against a database server on
a CentOS Linux system, this problem does not occur.
#!/bin/sh
poll_sec=15
imax=`expr 1 / ${poll_sec}`
if [ $# -ge 1 ]; then
imax=$1
fi
echo "LISTEN first;"
echo "LISTEN second;"
i=0
while [ $i -lt $imax ]; do
echo "SELECT pg_sleep(${poll_sec});"
i=`expr $i + 1`
done
#!/bin/sh
imax=10
autocommit=1
if [ $# -ge 1 ]; then
imax=$1
fi
echo "BEGIN;"
i=0
while [ $i -lt $imax ]; do
#echo "NOTIFY \"a_fairly_long_event_name_followed_by_colon:INSERT\";"
#echo "NOTIFY \"a_fairly_long_event_name_followed_by_colon:UPDATE\";"
#echo "NOTIFY \"a_fairly_long_event_name_followed_by_colon:INSERT\";"
#echo "NOTIFY \"a_very_different_event_name\";"
echo "NOTIFY first;"
echo "NOTIFY second;"
if [ "${autocommit}" ]; then
echo "COMMIT;"
echo "BEGIN;"
fi
i=`expr $i + 1`
done
echo "COMMIT;"
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
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 online:
> >
> > Bug reference: 4566
> > Logged by: Randy Isbell
> > Email address: jisb...@cisco.com
> > PostgreSQL version: 8.3.4
> > Operating system: FreeBSD 6.2
> > Description:pg_stop_backup() reports incorrect STOP WAL LOCATION
> > Details:
> >
> > An inconsistency exists between the segment name reported by
> > pg_stop_backup() and the actual WAL file name.
> >
> >
> > SELECT pg_start_backup('filename');
> > pg_start_backup
> >-
> > 10/FE1E2BAC
> >(1 row)
> >
> > Later:
> > SELECT pg_stop_backup();
> > pg_stop_backup
> >
> > 10/FF00
> >(1 row)
> >
> > 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.gz
> > STOP TIME: 2008-11-09 01:15:48 CST
> >
> > In my 8.3.4 instance, WAL file naming occurs as:
> >
> > ...
> > 0001000300FD
> > 0001000300FE
> > 00010004
> > 000100040001
> > ...
> >
> > WAL files never end in 'FF'. This causes a problem when trying to collect
> > the ending WAL file for backup.
>
> It's a bug of pg_stop_backup(), which has been talked before.
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg00108.php
>
> Attached is a patch against HEAD. I think that we should
> also backport.
>
> Regards,
>
> --
> Fujii Masao
> NIPPON TELEGRAPH AND TELEPHONE CORPORATION
> NTT Open Source Software Center
[ Attachment, skipping... ]
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
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 calculate whether stop wal location > indicates a boundary byte or not before starting waiting. Such calculation > should be done by the users? No, which is why we provide functions to do it ;-) 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 more sensible now". regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
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 more sensible now". OK. I understood that changing the filename would more confuse users. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg_listener entries deleted under heavy NOTIFY load only on Windows
"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 explanation for this is that Send_Notify() gets an error from kill() and concludes that the listening process has died without removing its pg_listener entry; whereupon it removes it itself. Looking at pgkill(), that theory implies that CallNamedPipe() failed when under sufficient stress. I'm not sure what the "timeout" parameter we use with CallNamedPipe actually limits, but maybe it's too small? (Microsoft's doc suggests that the timeout only matters if the pipe doesn't already exist, so I'm not sure I believe this theory; though certainly the doc is vague enough that that reading could be wrong.) Theory B is that you've got some broken antivirus code on there that is arbitrarily interfering with the pipe access. The lack of any similar previous reports suggests that there's some local issue contributing ,,, regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
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, I guess that would make it less confusing. Seems quite dangerous to > change the meaning now, however :-(. A program (or person) that knows its > current meaning would currently wait for STOP WAL filename - 1 file to be > archived. If we change the meaning, the same program would determine that > the backup is safe, even if the last xlog file hasn't yet been archived. So > I think this is not back-portable. Yes, I agree that we need to be careful about changing such meaning. But, there are two reasons why I think this would confuse the users. 1. 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 calculate whether stop wal location indicates a boundary byte or not before starting waiting. Such calculation should be done by the users? 2. I think it's odd that the return value of pg_xlogfile_name(pg_stop_backup()) is different from the wal stop filename in backup history file, though the return value of pg_stop_backup() is the same as the wal stop location in backup history file. We should uniform them? pg_xlogfile_name() always returns the inclusive filename, so the users don't need to care about whether the return value of pg_stop_backup() indicates a boundary byte. This is already documented. - http://www.postgresql.org/docs/current/static/functions-admin.html > Similarly, pg_xlogfile_name extracts just the transaction log file name. > When the given transaction log location is exactly at a transaction log file > boundary, both these functions return the name of the preceding transaction > log file. This is usually the desired behavior for managing transaction log > archiving behavior, since the preceding file is the last one that currently > needs to be archived. - Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
