[COMMITTERS] pgsql: Update timezone mapping for Windows with new timezones added in

2008-02-11 Thread Magnus Hagander
Log Message:
---
Update timezone mapping for Windows with new timezones added
in windows servicepacks.
Fix timezone mapping for "Mexico 2"

Tags:

REL8_2_STABLE

Modified Files:
--
pgsql/src/timezone:
pgtz.c (r1.48 -> r1.48.2.1)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/timezone/pgtz.c?r1=1.48&r2=1.48.2.1)

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


[COMMITTERS] pgsql: Update timezone mapping for Windows with new timezones added in

2008-02-11 Thread Magnus Hagander
Log Message:
---
Update timezone mapping for Windows with new timezones added
in windows servicepacks.
Fix timezone mapping for "Mexico 2"

Modified Files:
--
pgsql/src/timezone:
pgtz.c (r1.57 -> r1.58)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/timezone/pgtz.c?r1=1.57&r2=1.58)

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


[COMMITTERS] pgsql: Repair VACUUM FULL bug introduced by HOT patch: the original way

2008-02-11 Thread Tom Lane
Log Message:
---
Repair VACUUM FULL bug introduced by HOT patch: the original way of
calculating a page's initial free space was fine, and should not have been
"improved" by letting PageGetHeapFreeSpace do it.  VACUUM FULL is going to
reclaim LP_DEAD line pointers later, so there is no need for a guard
against the page being too full of line pointers, and having one risks
rejecting pages that are perfectly good move destinations.

This also exposed a second bug, which is that the empty_end_pages logic
assumed that any page with no live tuples would get entered into the
fraged_pages list automatically (by virtue of having more free space than
the threshold in the do_frag calculation).  This assumption certainly
seems risky when a low fillfactor has been chosen, and even without
tunable fillfactor I think it could conceivably fail on a page with many
unused line pointers.  So fix the code to force do_frag true when notup
is true, and patch this part of the fix all the way back.

Per report from Tomas Szepe.

Tags:

REL8_0_STABLE

Modified Files:
--
pgsql/src/backend/commands:
vacuum.c (r1.299.4.3 -> r1.299.4.4)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuum.c?r1=1.299.4.3&r2=1.299.4.4)

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


[COMMITTERS] pgsql: Repair VACUUM FULL bug introduced by HOT patch: the original way

2008-02-11 Thread Tom Lane
Log Message:
---
Repair VACUUM FULL bug introduced by HOT patch: the original way of
calculating a page's initial free space was fine, and should not have been
"improved" by letting PageGetHeapFreeSpace do it.  VACUUM FULL is going to
reclaim LP_DEAD line pointers later, so there is no need for a guard
against the page being too full of line pointers, and having one risks
rejecting pages that are perfectly good move destinations.

This also exposed a second bug, which is that the empty_end_pages logic
assumed that any page with no live tuples would get entered into the
fraged_pages list automatically (by virtue of having more free space than
the threshold in the do_frag calculation).  This assumption certainly
seems risky when a low fillfactor has been chosen, and even without
tunable fillfactor I think it could conceivably fail on a page with many
unused line pointers.  So fix the code to force do_frag true when notup
is true, and patch this part of the fix all the way back.

Per report from Tomas Szepe.

Tags:

REL8_1_STABLE

Modified Files:
--
pgsql/src/backend/commands:
vacuum.c (r1.317.2.6 -> r1.317.2.7)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuum.c?r1=1.317.2.6&r2=1.317.2.7)

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


[COMMITTERS] pgsql: Repair VACUUM FULL bug introduced by HOT patch: the original way

2008-02-11 Thread Tom Lane
Log Message:
---
Repair VACUUM FULL bug introduced by HOT patch: the original way of
calculating a page's initial free space was fine, and should not have been
"improved" by letting PageGetHeapFreeSpace do it.  VACUUM FULL is going to
reclaim LP_DEAD line pointers later, so there is no need for a guard
against the page being too full of line pointers, and having one risks
rejecting pages that are perfectly good move destinations.

This also exposed a second bug, which is that the empty_end_pages logic
assumed that any page with no live tuples would get entered into the
fraged_pages list automatically (by virtue of having more free space than
the threshold in the do_frag calculation).  This assumption certainly
seems risky when a low fillfactor has been chosen, and even without
tunable fillfactor I think it could conceivably fail on a page with many
unused line pointers.  So fix the code to force do_frag true when notup
is true, and patch this part of the fix all the way back.

Per report from Tomas Szepe.

Modified Files:
--
pgsql/src/backend/commands:
vacuum.c (r1.363 -> r1.364)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuum.c?r1=1.363&r2=1.364)

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


[COMMITTERS] pgsql: Fix SPI_cursor_open() and SPI_is_cursor_plan() to push the SPI

2008-02-11 Thread Tom Lane
Log Message:
---
Fix SPI_cursor_open() and SPI_is_cursor_plan() to push the SPI stack before
doing anything interesting, such as calling RevalidateCachedPlan().  The
necessity of this is demonstrated by an example from Willem Buitendyk:
during a replan, the planner might try to evaluate SPI-using functions,
and so we'd better be in a clean SPI context.

A small downside of this fix is that these two functions will now fail
outright if called when not inside a SPI-using procedure (ie, a
SPI_connect/SPI_finish pair).  The documentation never promised or suggested
that that would work, though; and they are normally used in concert with
other functions, mainly SPI_prepare, that always have failed in such a case.
So the odds of breaking something seem pretty low.

In passing, make SPI_is_cursor_plan's error handling convention clearer,
and fix documentation's erroneous claim that SPI_cursor_open would
return NULL on error.

Before 8.3 these functions could not invoke replanning, so there is probably
no need for back-patching.

Modified Files:
--
pgsql/doc/src/sgml:
spi.sgml (r1.59 -> r1.60)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/spi.sgml?r1=1.59&r2=1.60)
pgsql/src/backend/executor:
spi.c (r1.187 -> r1.188)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/spi.c?r1=1.187&r2=1.188)

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


[COMMITTERS] pgsql: Repair VACUUM FULL bug introduced by HOT patch: the original way

2008-02-11 Thread Tom Lane
Log Message:
---
Repair VACUUM FULL bug introduced by HOT patch: the original way of
calculating a page's initial free space was fine, and should not have been
"improved" by letting PageGetHeapFreeSpace do it.  VACUUM FULL is going to
reclaim LP_DEAD line pointers later, so there is no need for a guard
against the page being too full of line pointers, and having one risks
rejecting pages that are perfectly good move destinations.

This also exposed a second bug, which is that the empty_end_pages logic
assumed that any page with no live tuples would get entered into the
fraged_pages list automatically (by virtue of having more free space than
the threshold in the do_frag calculation).  This assumption certainly
seems risky when a low fillfactor has been chosen, and even without
tunable fillfactor I think it could conceivably fail on a page with many
unused line pointers.  So fix the code to force do_frag true when notup
is true, and patch this part of the fix all the way back.

Per report from Tomas Szepe.

Tags:

REL8_2_STABLE

Modified Files:
--
pgsql/src/backend/commands:
vacuum.c (r1.342.2.4 -> r1.342.2.5)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuum.c?r1=1.342.2.4&r2=1.342.2.5)

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


[COMMITTERS] pgloader - pgloader: New Directory

2008-02-11 Thread User Dim
Update of /cvsroot/pgloader/pgloader/examples/parallel
In directory pgfoundry.org:/tmp/cvs-serv64636/examples/parallel

Log Message:
Directory /cvsroot/pgloader/pgloader/examples/parallel added to the repository


---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[COMMITTERS] pgsql: Repair VACUUM FULL bug introduced by HOT patch: the original way

2008-02-11 Thread Tom Lane
Log Message:
---
Repair VACUUM FULL bug introduced by HOT patch: the original way of
calculating a page's initial free space was fine, and should not have been
"improved" by letting PageGetHeapFreeSpace do it.  VACUUM FULL is going to
reclaim LP_DEAD line pointers later, so there is no need for a guard
against the page being too full of line pointers, and having one risks
rejecting pages that are perfectly good move destinations.

This also exposed a second bug, which is that the empty_end_pages logic
assumed that any page with no live tuples would get entered into the
fraged_pages list automatically (by virtue of having more free space than
the threshold in the do_frag calculation).  This assumption certainly
seems risky when a low fillfactor has been chosen, and even without
tunable fillfactor I think it could conceivably fail on a page with many
unused line pointers.  So fix the code to force do_frag true when notup
is true, and patch this part of the fix all the way back.

Per report from Tomas Szepe.

Tags:

REL7_4_STABLE

Modified Files:
--
pgsql/src/backend/commands:
vacuum.c (r1.263.2.4 -> r1.263.2.5)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuum.c?r1=1.263.2.4&r2=1.263.2.5)

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[COMMITTERS] pgloader - pgloader: First implementation of parallel loading, each

2008-02-11 Thread User Dim
Log Message:
---
First implementation of parallel loading, each thread loading a part of the 
input file (stat, seek, etc)

Modified Files:
--
pgloader:
pgloader.py (r1.21 -> r1.22)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgloader/pgloader/pgloader.py.diff?r1=1.21&r2=1.22)
pgloader/debian:
changelog (r1.16 -> r1.17)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgloader/pgloader/debian/changelog.diff?r1=1.16&r2=1.17)
pgloader/examples:
pgloader.conf (r1.13 -> r1.14)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgloader/pgloader/examples/pgloader.conf.diff?r1=1.13&r2=1.14)
pgloader/pgloader:
csvreader.py (r1.4 -> r1.5)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgloader/pgloader/pgloader/csvreader.py.diff?r1=1.4&r2=1.5)
options.py (r1.15 -> r1.16)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgloader/pgloader/pgloader/options.py.diff?r1=1.15&r2=1.16)
pgloader.py (r1.23 -> r1.24)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgloader/pgloader/pgloader/pgloader.py.diff?r1=1.23&r2=1.24)
reader.py (r1.8 -> r1.9)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgloader/pgloader/pgloader/reader.py.diff?r1=1.8&r2=1.9)
textreader.py (r1.11 -> r1.12)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgloader/pgloader/pgloader/textreader.py.diff?r1=1.11&r2=1.12)

Added Files:
---
pgloader/examples/parallel:
parallel.sql (r1.1)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgloader/pgloader/examples/parallel/parallel.sql?rev=1.1&content-type=text/x-cvsweb-markup)

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster