pgbench: replace run-time string comparisons with an enum identifier.
Minor refactoring that should yield some performance benefit.
Fabien Coelho, reviewed by Aleksandr Parfenov
Discussion: https://postgr.es/m/alpine.DEB.2.20.1709230538130.4999@lancre
Branch
--
master
Details
---
https
Set the metapage's pd_lower correctly in brin, gin, and spgist indexes.
Previously, these index types left the pd_lower field set to the default
SizeOfPageHeaderData, which is really a lie because it ought to point past
whatever space is being used for metadata. The coding accidentally failed
to
Fix float parsing in ecpg INFORMIX mode.
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/049dab00942165c3df3aeace9e8e86cd2679dce0
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
Fix float parsing in ecpg INFORMIX mode.
Branch
--
REL9_4_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/ad24e7bc28d45b180726d6ff144e58d67e73aaa4
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
Fix float parsing in ecpg INFORMIX mode.
Branch
--
REL9_3_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/7a35507acceb07c4ed1a7a0c82db50eee3101df3
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
Fix float parsing in ecpg INFORMIX mode.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/6976a4f05fc5f9d3b469869e412e0814c8c7ab2a
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
Sent vi
Fix float parsing in ecpg INFORMIX mode.
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/b6d95939ed6fc8bde97eb8c9af00838dde82cc41
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
Fix float parsing in ecpg INFORMIX mode.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/ee46980a73bf5b1b39c3a6be76dc01fa2a5819c7
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
pg_ctl: Improve message
Change message for restarting a server from a directory without a PID
file. This accounts for the case where a restart happens after an
initdb. The new message indicates that the start has not completed yet
and might fail.
Author: Jesper Pedersen
Branch
--
master
Robert Haas writes:
> Well, my thought was that delaying this release for a week would be
> better than either (a) doing an extra minor release just to get this
> fix out or (b) waiting another three months to release this fix. The
> former seems like fairly unnecessary work, and the latter doesn
On Thu, Nov 2, 2017 at 10:38 PM, Tom Lane wrote:
>> Personally, I think it would be best to push the release out a week.
>
> I would only be in favor of that if there were some reason to think that
> the bug is worse now than it's been in the four years since 9.3 was
> released. Otherwise, we sho
On Thu, Nov 2, 2017 at 10:26 PM, Peter Geoghegan wrote:
> On Thu, Nov 2, 2017 at 9:44 AM, Robert Haas wrote:
>> The second commit (22576734b805fb0952f9be841ca8f643694ee868) is where
>> I think things get a lot more dangerous. The problem (as Andres
>> pointed out to me this afternoon) is that it
Robert Haas writes:
> Just to be clear, it looks like "Fix freezing of a dead HOT-updated
> tuple" (46c35116ae1acc8826705ef2a7b5d9110f9d6e84) went in before 10.0
> was stamped, but "Fix traversal of half-frozen update chains"
> (22576734b805fb0952f9be841ca8f643694ee868) went in afterwards and is
>
I am setting up PostgreSQL standby on windows for the first time on version
9.4.14:
Is the below syntax correct in the recovery.conf file
restore_command = 'copy "D:\\apps\postgres\\pg_archivelog\\%f" "%p"'
archive_cleanup_command = 'pg_archivecleanup
"D:\\apps\postgres\pg_archivelog\\" %r'
Simplify new test suite handling of passwordcheck
This changes the use of a custom configuration file to enforce the value
of preload_shared_libraries to simply load the library during the tests.
This removes the restriction of running installcheck on the tests, and
simplifies its makefile contrar
On Thu, Nov 2, 2017 at 9:44 AM, Robert Haas wrote:
> The second commit (22576734b805fb0952f9be841ca8f643694ee868) is where
> I think things get a lot more dangerous. The problem (as Andres
> pointed out to me this afternoon) is that it seems possible to end up
> with a situation where there shoul
Fix corner-case errors in brin_doupdate().
In some cases the BRIN code releases lock on an index page, and later
re-acquires lock and tries to check that the tuple it was working on is
still there. That check was a couple bricks shy of a load. It didn't
consider that the page might have turned i
Fix corner-case errors in brin_doupdate().
In some cases the BRIN code releases lock on an index page, and later
re-acquires lock and tries to check that the tuple it was working on is
still there. That check was a couple bricks shy of a load. It didn't
consider that the page might have turned i
Fix corner-case errors in brin_doupdate().
In some cases the BRIN code releases lock on an index page, and later
re-acquires lock and tries to check that the tuple it was working on is
still there. That check was a couple bricks shy of a load. It didn't
consider that the page might have turned i
Fix corner-case errors in brin_doupdate().
In some cases the BRIN code releases lock on an index page, and later
re-acquires lock and tries to check that the tuple it was working on is
still there. That check was a couple bricks shy of a load. It didn't
consider that the page might have turned i
On Thu, Nov 2, 2017 at 4:20 AM, Andres Freund wrote:
> I think the problem is on the pruning, rather than the freezing side. We
> can't freeze a tuple if it has an alive predecessor - rather than
> weakining this, we should be fixing the pruning to not have the alive
> predecessor.
Excellent catc
Remove wal_keep_segments from default configuration in PostgresNode.pm
This is only used in the pg_rewind tests, so only set it there. It's
better if other tests run closer to a default configuration.
Author: Michael Paquier
Branch
--
master
Details
---
https://git.postgresql.org/pg/c
On Thu, Nov 2, 2017 at 8:25 PM, Alvaro Herrera wrote:
> Pushed the reverts.
>
> I noticed while doing so that REL_10_STABLE contains the bogus commits.
> Does that change our opinion regarding what to do for people upgrading
> to a version containing the broken commits? I don't think so, because
doc: Clarify pgstattuple privileges information
The description has gotten a bit confusing over time, so rewrite the
paragraph a bit.
Reported-by: Feike Steenbergen
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/0f53934164d37682fd6a6d87d57008f9ca03e3d0
Modified
Teach planner to account for HAVING quals in aggregation plan nodes.
For some reason, we have never accounted for either the evaluation cost
or the selectivity of filter conditions attached to Agg and Group nodes
(which, in practice, are always conditions from a HAVING clause).
Applying our regul
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Andres Freund writes:
> > > Do we care about people upgrading to unreleased versions? We could do
> > > nothing, document it in the release notes, or ???
> >
> > Do nothing.
>
> Agreed. Not much we can do there.
Pushed the rever
Revert bogus fixes of HOT-freezing bug
It turns out we misdiagnosed what the real problem was. Revert the
previous changes, because they may have worse consequences going
forward. A better fix is forthcoming.
The simplistic test case is kept, though disabled.
Discussion:
https://postgr.es/m/2
Revert bogus fixes of HOT-freezing bug
It turns out we misdiagnosed what the real problem was. Revert the
previous changes, because they may have worse consequences going
forward. A better fix is forthcoming.
The simplistic test case is kept, though disabled.
Discussion:
https://postgr.es/m/2
Revert bogus fixes of HOT-freezing bug
It turns out we misdiagnosed what the real problem was. Revert the
previous changes, because they may have worse consequences going
forward. A better fix is forthcoming.
The simplistic test case is kept, though disabled.
Discussion:
https://postgr.es/m/2
Revert bogus fixes of HOT-freezing bug
It turns out we misdiagnosed what the real problem was. Revert the
previous changes, because they may have worse consequences going
forward. A better fix is forthcoming.
The simplistic test case is kept, though disabled.
Discussion:
https://postgr.es/m/2
Revert bogus fixes of HOT-freezing bug
It turns out we misdiagnosed what the real problem was. Revert the
previous changes, because they may have worse consequences going
forward. A better fix is forthcoming.
The simplistic test case is kept, though disabled.
Discussion:
https://postgr.es/m/2
Revert bogus fixes of HOT-freezing bug
It turns out we misdiagnosed what the real problem was. Revert the
previous changes, because they may have worse consequences going
forward. A better fix is forthcoming.
The simplistic test case is kept, though disabled.
Discussion:
https://postgr.es/m/2
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund writes:
> > Do we care about people upgrading to unreleased versions? We could do
> > nothing, document it in the release notes, or ???
>
> Do nothing.
Agreed. Not much we can do there.
Thanks!
Stephen
signature.asc
Description: Digital
Andres Freund writes:
> Do we care about people upgrading to unreleased versions? We could do
> nothing, document it in the release notes, or ???
Do nothing.
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes t
doc: Adjust name in acknowledgments
per request of the named person
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/d8c435e1743773eba4e36498479ca6aef28a2d70
Modified Files
--
doc/src/sgml/release-10.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion
doc: Adjust name in acknowledgments
per request of the named person
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/769756fb74d6a183442ae3a3b5ce0816226ce64b
Modified Files
--
doc/src/sgml/release-10.sgml | 2 +-
1 file changed, 1 insertion(+), 1 d
Hi,
On 2017-11-02 13:49:47 +0100, Alvaro Herrera wrote:
> Andres Freund wrote:
> > I think the problem is on the pruning, rather than the freezing side. We
> > can't freeze a tuple if it has an alive predecessor - rather than
> > weakining this, we should be fixing the pruning to not have the aliv
Andres Freund wrote:
> I spent some time discussing this with Robert today (with both of us
> alternating between feeling the other and ourselves as stupid), and the
> conclusion I think is that the problem is on the pruning, rather than
> the freezing side.
Thanks both for spending some more tim
On Thu, Nov 2, 2017 at 4:50 PM, Andres Freund wrote:
> I think a5736bf754c82d8b86674e199e232096c679201d might be dangerous in
> the face of previously corrupted tuple chains and pg_upgraded clusters -
> it can lead to tuples being considered related, even though they they're
> from entirely indepe
Hi,
On 2017-09-28 14:47:53 +, Alvaro Herrera wrote:
> Fix freezing of a dead HOT-updated tuple
>
> Vacuum calls page-level HOT prune to remove dead HOT tuples before doing
> liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But
> concurrent transaction commit/abort may turn
40 matches
Mail list logo
