Improve error message for incorrect number inputs in libecpg.
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/90d61bd1d16bb51d9bbc07e2e345e49bed7310fe
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 1 -
1 file changed, 1 deletion(-)
--
S
Improve error message for incorrect number inputs in libecpg.
Branch
--
REL9_3_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/deb429b51ed37e5c069f5d1fd659244a29d3a769
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 1 -
1 file changed, 1 deletion(-)
--
S
Improve error message for incorrect number inputs in libecpg.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/c63568b06edeece064771b8f170ef0298d8ab134
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 1 -
1 file changed, 1 deletion(-)
--
S
Improve error message for incorrect number inputs in libecpg.
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/6cf68e223643203494292c2787b72a7353264c7d
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 1 -
1 file changed, 1 deletion(-)
--
S
Improve error message for incorrect number inputs in libecpg.
Branch
--
REL9_4_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/946f165182a2e643c18fa21b563dc3ccc0c9ada7
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 1 -
1 file changed, 1 deletion(-)
--
S
Improve error message for incorrect number inputs in libecpg.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/7164991caf3858cbd75e5efb7943e11a51ad04f9
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 1 -
1 file changed, 1 deletion(-)
--
Sent via
Grammar typo in security warning about md5
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/0f6bd533341341de7007b6d5ed24742211471c68
Author: Simon Riggs
Modified Files
--
doc/src/sgml/client-auth.sgml | 2 +-
1 file changed, 1 insertion(+), 1 delet
On 2017-11-02 06:05:51 -0700, Andres Freund wrote:
> 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
> > > wea
Fix BRIN summarization concurrent with extension
If a process is extending a table concurrently with some BRIN
summarization process, it is possible for the latter to miss pages added
by the former because the number of pages is computed ahead of time.
Fix by determining a fresh relation size aft
Fix BRIN summarization concurrent with extension
If a process is extending a table concurrently with some BRIN
summarization process, it is possible for the latter to miss pages added
by the former because the number of pages is computed ahead of time.
Fix by determining a fresh relation size aft
Fix BRIN summarization concurrent with extension
If a process is extending a table concurrently with some BRIN
summarization process, it is possible for the latter to miss pages added
by the former because the number of pages is computed ahead of time.
Fix by determining a fresh relation size aft
Fix BRIN summarization concurrent with extension
If a process is extending a table concurrently with some BRIN
summarization process, it is possible for the latter to miss pages added
by the former because the number of pages is computed ahead of time.
Fix by determining a fresh relation size aft
Don't reset additional columns on subscriber to NULL on UPDATE
When a publisher table has fewer columns than a subscriber, the update
of a row on the publisher should result in updating of only the columns
in common. The previous coding mistakenly reset the values of
additional columns on the sub
Don't reset additional columns on subscriber to NULL on UPDATE
When a publisher table has fewer columns than a subscriber, the update
of a row on the publisher should result in updating of only the columns
in common. The previous coding mistakenly reset the values of
additional columns on the sub
Alvaro Herrera writes:
> Fix BRIN summarization concurrent with extension
Buildfarm is entirely unhappy ...
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mai
doc: Convert ids to upper case at build time
This makes the produced HTML anchors upper case, making it backward
compatible with the previous (9.6) build system.
Reported-by: Thomas Kellerer
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/5159626afbe969bdcb
doc: Convert ids to upper case at build time
This makes the produced HTML anchors upper case, making it backward
compatible with the previous (9.6) build system.
Reported-by: Thomas Kellerer
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/49df45acd8d40ee172c2f5491
Tom Lane wrote:
> Alvaro Herrera writes:
> > Fix BRIN summarization concurrent with extension
>
> Buildfarm is entirely unhappy ...
Will fix shortly.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent v
Andres Freund wrote:
Here's that patch. I've stared at this some, and Robert did too. Robert
mentioned that the commit message might need some polish and I'm not
100% sure about the error message texts yet.
The commit message should probably say that the bug involves the
resurrection of previ
Peter Geoghegan wrote:
> Andres Freund wrote:
> > Staring at the vacuumlazy hunk I think I might have found a related bug:
> > heap_update_tuple() just copies the old xmax to the new tuple's xmax if
> > a multixact and still running. It does so without verifying liveliness
> > of members. Isn't
Fix thinkos in BRIN summarization
The previous commit contained a thinko that made a single-range
summarization request process from there to end of table. Fix by
setting the correct end range point. Per buildfarm.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commi
Fix thinkos in BRIN summarization
The previous commit contained a thinko that made a single-range
summarization request process from there to end of table. Fix by
setting the correct end range point. Per buildfarm.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/1
Alvaro Herrera wrote:
He means that the tuple that heap_update moves to page 1 (which will no
longer be processed by vacuum) will contain a multixact that's older
than relminmxid -- because it is copied unchanged by heap_update instead
of properly checking against age limit.
I see. The problem
Flag index metapages as standard-format in xlog.c calls.
btree, hash, and bloom indexes all set up their metapages in standard
format (that is, with pd_lower and pd_upper correctly delimiting the
unused area); but they mostly didn't inform the xlog routines of this.
When calling log_newpage[_buffe
On November 4, 2017 1:22:04 AM GMT+05:30, Alvaro Herrera
wrote:
>Peter Geoghegan wrote:
>> Andres Freund wrote:
>
>> > Staring at the vacuumlazy hunk I think I might have found a related
>bug:
>> > heap_update_tuple() just copies the old xmax to the new tuple's
>xmax if
>> > a multixact and st
Avoid looping through line pointers twice in PageRepairFragmentation().
There doesn't seem to be any good reason to do the filling of the
itemidbase[] array separately from the first traversal of the pointers.
It's certainly not a win if there are any line pointers with storage,
and even if there
26 matches
Mail list logo
