On Wed, Jun 15, 2016 at 8:57 PM, Andres Freund wrote:
> The simplest version of the scenario I'm concerned about is that a tuple
> in a tuple is *not* vacuumed, even though it's elegible to be removed
> due to STO. If that tuple has toasted columns, it could be the that the
> toast table was inde
On 2016-06-16 09:50:09 -0500, Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 8:57 PM, Andres Freund wrote:
>
> > The simplest version of the scenario I'm concerned about is that a tuple
> > in a tuple is *not* vacuumed, even though it's elegible to be removed
> > due to STO. If that tuple has to
On Thu, Jun 16, 2016 at 11:37 AM, Andres Freund wrote:
>> If that were really true, why would we not have the problem in
>> current production versions that the toast table could be vacuumed
>> before the heap, leading to exactly the issue you are talking
>> about?
>
> The issue isn't there withou
Add regression test for 04ae11f62e643e07c411c4935ea6af46cb112aa9.
The code in this area needs further revision, and it would be best
not to re-break the things we've already fixed.
Per a gripe from Tom Lane.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/8c1d9d56e9
Remove unused prototype
Commit 6f56b41ac0cd7 removed function get_pg_database_relfilenode but left
its prototype in place. Remove it.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/b000afea6596c4dab2f0595ded751659a158b754
Modified Files
--
src/bin/pg_u
On 2016-06-16 12:02:39 -0400, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 11:37 AM, Andres Freund wrote:
> >> If that were really true, why would we not have the problem in
> >> current production versions that the toast table could be vacuumed
> >> before the heap, leading to exactly the issue y
Avoid crash in "postgres -C guc" for a GUC with a null string value.
Emit "(null)" instead, which was the behavior all along on platforms
that don't crash, eg OS X. Per report from Jehan-Guillaume de Rorthais.
Back-patch to 9.2 where -C option was introduced.
Michael Paquier
Report: <2016061520
Avoid crash in "postgres -C guc" for a GUC with a null string value.
Emit "(null)" instead, which was the behavior all along on platforms
that don't crash, eg OS X. Per report from Jehan-Guillaume de Rorthais.
Back-patch to 9.2 where -C option was introduced.
Michael Paquier
Report: <2016061520
Avoid crash in "postgres -C guc" for a GUC with a null string value.
Emit "(null)" instead, which was the behavior all along on platforms
that don't crash, eg OS X. Per report from Jehan-Guillaume de Rorthais.
Back-patch to 9.2 where -C option was introduced.
Michael Paquier
Report: <2016061520
Avoid crash in "postgres -C guc" for a GUC with a null string value.
Emit "(null)" instead, which was the behavior all along on platforms
that don't crash, eg OS X. Per report from Jehan-Guillaume de Rorthais.
Back-patch to 9.2 where -C option was introduced.
Michael Paquier
Report: <2016061520
Avoid crash in "postgres -C guc" for a GUC with a null string value.
Emit "(null)" instead, which was the behavior all along on platforms
that don't crash, eg OS X. Per report from Jehan-Guillaume de Rorthais.
Back-patch to 9.2 where -C option was introduced.
Michael Paquier
Report: <2016061520
On Thu, Jun 16, 2016 at 12:14 PM, Andres Freund wrote:
>> > The issue isn't there without the feature, because we (should) never
>> > access a tuple/detoast a column when it's invisible enough for the
>> > corresponding toast tuple to be vacuumed away. But with
>> > old_snapshot_timeout that's obv
Reword bogus comment
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/3b5a2a8856b810ed354fb6dbb7df8d7325ece82f
Modified Files
--
src/bin/pg_upgrade/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Sent via pgsql-committers mailing list (pg
On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 12:14 PM, Andres Freund wrote:
> >> > The issue isn't there without the feature, because we (should) never
> >> > access a tuple/detoast a column when it's invisible enough for the
> >> > corresponding toast tuple to be vac
On Thu, Jun 16, 2016 at 12:54 PM, Andres Freund wrote:
>> The root of my confusion is: if we prune a tuple, we'll bump the page
>> LSN, so any session that is still referencing that tuple will error
>> out as soon as it touches the page on which that tuple used to exist.
>
> Right. On the main tab
Invent min_parallel_relation_size GUC to replace a hard-wired constant.
The main point of doing this is to allow the cutoff to be set very small,
even zero, to allow parallel-query behavior to be tested on relatively
small tables such as we typically use in the regression tests. But it
might be o
On 2016-06-16 13:44:34 -0400, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 12:54 PM, Andres Freund wrote:
> >> The root of my confusion is: if we prune a tuple, we'll bump the page
> >> LSN, so any session that is still referencing that tuple will error
> >> out as soon as it touches the page on w
On Thu, Jun 16, 2016 at 1:01 PM, Andres Freund wrote:
> The relevant part is the HeapTupleSatisfiesMVCC check, we're using
> SatisfiesToast for toast lookups.
>
> FWIW, I just tried to reproduce this with old_snapshot_threshold = 0 -
> but ran into the problem that I couldn't get it to vacuum any
On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
> On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>> The root of my confusion is: if we prune a tuple, we'll bump the page
>> LSN, so any session that is still referencing that tuple will error
>> out as soon as it touches the page on which
On 2016-06-16 13:16:35 -0500, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 1:01 PM, Andres Freund wrote:
>
> > The relevant part is the HeapTupleSatisfiesMVCC check, we're using
> > SatisfiesToast for toast lookups.
> >
> > FWIW, I just tried to reproduce this with old_snapshot_threshold = 0 -
Hi,
On 2016-06-16 13:19:13 -0500, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
> > On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>
> >> The root of my confusion is: if we prune a tuple, we'll bump the page
> >> LSN, so any session that is still referencing th
On Thu, Jun 16, 2016 at 1:19 PM, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
>> On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>>> Maybe it would help if you lay out the whole sequence of events, like:
>>>
>>> S1: Does this.
>>> S2: Does that.
>>> S1: Now doe
On Thu, Jun 16, 2016 at 1:32 PM, Andres Freund wrote:
> With old_snapshot_threshold=1 I indeed can reproduce the issue. I
> disabled autovacuum, to make the scheduling more predictable. But it
> should "work" just as well with autovacuum.
>
> S1: CREATE TABLE toasted(largecol text);
> INSERT
On 2016-06-16 13:53:01 -0500, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 1:19 PM, Kevin Grittner wrote:
> > On Thu, Jun 16, 2016 at 11:54 AM, Andres Freund wrote:
> >> On 2016-06-16 12:43:34 -0400, Robert Haas wrote:
>
> >>> Maybe it would help if you lay out the whole sequence of events, l
On 2016-06-16 11:57:48 -0700, Andres Freund wrote:
> See
> https://www.postgresql.org/message-id/[email protected]
For posterity's sake, that was supposed to be
https://www.postgresql.org/message-id/[email protected]
--
Sent via pgsql-co
Fix fuzzy thinking in ReinitializeParallelDSM().
The fact that no workers were successfully launched in the previous
iteration does not excuse us from setting up properly to try again.
This appears to explain crashes I saw in parallel regression testing
due to error_mqh being NULL when it shouldn'
On 10/06/16 17:01, Robert Haas wrote:
> Update pg_stat_statements extension for parallel query.
I couldn't readily find a review for this patch, and I am unsatisfied
with it. I think it's very strange that a 1.4 version would call a
function labeled 1.3, and when we make a 1.5 the code will look
Fix validation of overly-long IPv6 addresses.
The inet/cidr types sometimes failed to reject IPv6 inputs with too many
colon-separated fields, instead translating them to '::/0'. This is the
result of a thinko in the original ISC code that seems to be as yet
unreported elsewhere. Per bug #14198
Fix validation of overly-long IPv6 addresses.
The inet/cidr types sometimes failed to reject IPv6 inputs with too many
colon-separated fields, instead translating them to '::/0'. This is the
result of a thinko in the original ISC code that seems to be as yet
unreported elsewhere. Per bug #14198
Fix validation of overly-long IPv6 addresses.
The inet/cidr types sometimes failed to reject IPv6 inputs with too many
colon-separated fields, instead translating them to '::/0'. This is the
result of a thinko in the original ISC code that seems to be as yet
unreported elsewhere. Per bug #14198
Fix validation of overly-long IPv6 addresses.
The inet/cidr types sometimes failed to reject IPv6 inputs with too many
colon-separated fields, instead translating them to '::/0'. This is the
result of a thinko in the original ISC code that seems to be as yet
unreported elsewhere. Per bug #14198
Fix validation of overly-long IPv6 addresses.
The inet/cidr types sometimes failed to reject IPv6 inputs with too many
colon-separated fields, instead translating them to '::/0'. This is the
result of a thinko in the original ISC code that seems to be as yet
unreported elsewhere. Per bug #14198
Fix validation of overly-long IPv6 addresses.
The inet/cidr types sometimes failed to reject IPv6 inputs with too many
colon-separated fields, instead translating them to '::/0'. This is the
result of a thinko in the original ISC code that seems to be as yet
unreported elsewhere. Per bug #14198
Robert Haas writes:
> Add regression test for 04ae11f62e643e07c411c4935ea6af46cb112aa9.
BTW, the buildfarm thinks this test fails a lot of the time, and
running "make installcheck-parallel" a few times here agrees: it
falls over more than 20% of the time. Don't know why it would be
probabilistic
On Fri, Jun 17, 2016 at 9:20 AM, Tom Lane wrote:
>
> Robert Haas writes:
> > Add regression test for 04ae11f62e643e07c411c4935ea6af46cb112aa9.
>
> BTW, the buildfarm thinks this test fails a lot of the time, and
> running "make installcheck-parallel" a few times here agrees: it
> falls over more
35 matches
Mail list logo
