On 4 May 2016 at 01:35, Peter Eisentraut
wrote:
> On 5/3/16 3:10 PM, Dean Rasheed wrote:
>> On 3 May 2016 at 16:52, Peter Eisentraut
>>>
>>> I would change appendReloptionsArrayAH() to a function and keep AH as the
>>> first argument (similar to other functions that take such a handle).
>>
>> I ca
When parallel degree is set to very high say 7, there is a segmentation
fault in parallel code,
and that is because type casting is missing in the code..
Take a look at below test code:
create table abd(n int) with (parallel_degree=7);
insert into abd values (generate_series(1,100));
On 05/03/2016 08:45 PM, Robert Haas wrote:
Committed all of this except for the bit about pg_start_backup, for
which I committed a separate fix.
Thanks, and really good that you spotted the pg_start_backup() issue.
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 2016-04-28 17:41:29 +0100, Thom Brown wrote:
> I've noticed another breakage, which I can reproduce consistently.
Thanks for the testing! I pushed a fix for this. This wasn't actually
an issue in the original patch, but a too strict test added in my fix.
Greetings,
Andres Freund
--
Sent v
On 4 May 2016 at 13:03, Euler Taveira wrote:
> Question is: is the actual code so useless that it can't even be a 1.0
> release?
What's committed suffers from a design problem and cannot work correctly,
nor can it be fixed without an API change and significant revision. The
revised version I p
On 2016-05-04 07:46:42 +0200, Fabien COELHO wrote:
> >Well, TRUNCATED doesn't entirely work, there's I think some cases where
> >this currently also applies to deleted relations. I kind of like the
> >unintuitive sounding name, because it's really a dangerous options (any
> >further mdnblocks will
Rushabh,
* Rushabh Lathia (rushabh.lat...@gmail.com) wrote:
> On Tue, May 3, 2016 at 8:34 PM, Stephen Frost wrote:
>
> > * Rushabh Lathia (rushabh.lat...@gmail.com) wrote:
> > > With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
> > > bitmap
> > > to represent what to inclu
On 3 May 2016 at 22:03, Craig Ringer wrote:
> Hi all
>
> There's a bug (mine) in logical decoding timeline following where reading
> the first page from the segment containing a timeline switch fails to read
> from the most recent timeline in that segment. This is harmless if the old
> timeline's
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 03.05.2016 2:21, Andres Freund wrote:
Hi,
On 2016-04-28 21:58:00 +, Alex Ignatov wrote:
We have some issue with truncated pg_control file on Windows after
power failure.My questions is : 1) Is
On 03.05.2016 2:17, Tom Lane wrote:
Alex Ignatov writes:
I think that rename can help a little bit. At least on some FS it is
atomic operation.
Writing a single sector ought to be atomic too. I'm very skeptical that
it'll be an improvement to just move the risk from one filesystem
operatio
On 4 May 2016 at 09:59, Andres Freund wrote:
> On 2016-04-28 17:41:29 +0100, Thom Brown wrote:
> > I've noticed another breakage, which I can reproduce consistently.
>
> Thanks for the testing! I pushed a fix for this. This wasn't actually
> an issue in the original patch, but a too strict test
On Wed, May 4, 2016 at 2:05 AM, Andres Freund wrote:
> On 2016-04-29 10:38:55 -0700, Jeff Janes wrote:
> > I've bisected the errors I was seeing, discussed in
> >
> http://www.postgresql.org/message-id/CAMkU=1xqehc0ok4d+tkjfq1nvuho37pyrkhjp6q8oxifmx7...@mail.gmail.com
> >
> > It look like they fi
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Mon, Apr 25, 2016 at 12:39:09AM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> > > On Fri, Apr 22, 2016 at 12:31:41PM -0400, Stephen Frost wrote:
> > > > After looking through the code a bit, I realized that there are a
On 5/4/16 3:21 AM, Dean Rasheed wrote:
Well, appendStringLiteralAH() takes both, so that sets a precedent.
Works for me. Could you supply an updated patch with a static function
instead of a macro? Then I think this is good to go.
(bonus points for some tests)
--
Peter Eisentraut
On Wed, May 4, 2016 at 5:29 AM, Stephen Frost wrote:
> There is no such limitation on using pg_dump as a non-superuser. It's
> always been the case that you need to be able to LOCK the table that
> you're dumping. If you don't have rights to LOCK a certain table then
> pg_dump is going to throw
Hi.
As discovered by Oleg Bartunov, current filter() function for tsvector can
crash backend.
Bug was caused erroneous usage of char type in memmove argument.
tsvector_bugfix_type.diff
Description: Binary data
--
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
Russian Postgres
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, May 4, 2016 at 5:29 AM, Stephen Frost wrote:
> > There is no such limitation on using pg_dump as a non-superuser. It's
> > always been the case that you need to be able to LOCK the table that
> > you're dumping. If you don't have ri
> On 03 May 2016, at 00:59, David Fetter wrote:
>
> On Mon, May 02, 2016 at 01:58:11PM -0400, Tom Lane wrote:
>> I wrote:
>>> I think we'd be better off to rename these to tsvector_delete()
>>> and tsvector_filter() while we still can.
>>
>> ... although I now notice that hstore already exposes
On Wed, May 4, 2016 at 9:35 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, May 4, 2016 at 5:29 AM, Stephen Frost wrote:
>> > There is no such limitation on using pg_dump as a non-superuser. It's
>> > always been the case that you need to be able to LOCK the ta
Stas Kelvich writes:
>> On 03 May 2016, at 00:59, David Fetter wrote:
>> I suspect that steering that ship would be a good idea starting with
>> deprecation of the old name in 9.6, etc. hs_filter(), perhaps?
> In 9.5 there already were tsvector functions length(), numnode(), strip()
> Recent c
On Wed, May 4, 2016 at 4:02 PM, Alex Ignatov
wrote:
>
>
> On 03.05.2016 2:17, Tom Lane wrote:
>
>> Alex Ignatov writes:
>>
>>> I think that rename can help a little bit. At least on some FS it is
>>> atomic operation.
>>>
>>
>> Writing a single sector ought to be atomic too. I'm very skeptical
Hello,
This query is working in 9.4.x, but not in 9.5.2:
select 'x' sql;
ERROR: syntax error at or near "sql"
LINE 1: select 'x' sql;
Is this expected or a known issue?
I could neither find any hint about it in the incompatibility list of the 9.5
release notes,
nor is "sql" listed as reserve
On Wed, May 4, 2016 at 9:58 AM, Marc Mamin wrote:
> This query is working in 9.4.x, but not in 9.5.2:
>
> select 'x' sql;
>
> ERROR: syntax error at or near "sql"
> LINE 1: select 'x' sql;
>
> Is this expected or a known issue?
> I could neither find any hint about it in the incompatibility list
After all these years of inactivity I don't think that I have commit
access any more so perhaps someone can review the attached update to
chkpass.c and commit it if it looks OK.
There are two major changes to the existing chkpass type:
1. It now handles MD5 as well as DES
2. It has a GUC variabl
On Tue, May 3, 2016 at 11:48 AM, Robert Haas wrote:
> OK, I see now: the basic idea here is that we can't prune based on the
> newer XID unless the page LSN is guaranteed to advance whenever data
> is removed. Currently, we attempt to limit bloat in non-unlogged,
> non-catalog tables. You're sa
On Wed, May 4, 2016 at 8:58 AM, Marc Mamin wrote:
> select 'x' sql;
>
> ERROR: syntax error at or near "sql"
> LINE 1: select 'x' sql;
It's likely that you already know this, but for the benefit of
anyone finding the thread who doesn't -- you can avoid this sort of
error by either inserting the
Amit Kapila writes:
> On Wed, May 4, 2016 at 4:02 PM, Alex Ignatov
> wrote:
>> On 03.05.2016 2:17, Tom Lane wrote:
>>> Writing a single sector ought to be atomic too.
>> pg_control is 8k long(i think it is legth of one page in default PG
>> compile settings).
> The actual data written is always
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> But in Rushabh's example, he's not doing that. He's trying to do a
>> full-database dump of a database that contains one object which the
>> dump user has rights to access. Previously, that worked. Now, it
>> fails with an
"David G. Johnston" writes:
> This is a bit hard to reason about given that our implementation of
> inheritance is non-standard.
Yeah, that's a fairly key point. We've solved those problems with
respect to inherited CHECK constraints, and it seems like what we
ought to do with NOT NULL is make i
Thank you, pushed.
Stas Kelvich wrote:
Hi.
As discovered by Oleg Bartunov, current filter() function for tsvector can
crash backend.
Bug was caused erroneous usage of char type in memmove argument.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Dilip Kumar writes:
> When parallel degree is set to very high say 7, there is a segmentation
> fault in parallel code,
> and that is because type casting is missing in the code..
I'd say the cause is not having a sane range limit on the GUC.
> or corrupt some memory. Need to typecast
> *i *
Fabien COELHO writes:
>> There's not really a point in using an enum if you use neither the type
>> (which you shouldn't because if you or the bitmask value you have types
>> outside the range of the enum), nor the autogenerated numbers.
> I do not think that there is such a constraint in C, yo
I get the errors:
ERROR: attempted to delete invisible tuple
STATEMENT: update foo set count=count+1,text_array=$1 where text_array @> $2
And also:
ERROR: unexpected chunk number 1 (expected 2) for toast value
85223889 in pg_toast_16424
STATEMENT: update foo set count=count+1 where text_arr
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Why is it that we need to lock a table at all if we're just going to dump
> its ACL? I understand the failure modes that motivate locking when we're
> going to dump data or schema, but the ACL is not really subject to that
> kind of problem: we are going to
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Why is it that we need to lock a table at all if we're just going to dump
>> its ACL?
> I think I'm coming around to agree with that, but it seems like it'd be
> better to look at each component and say "we know X is safe, so we wo
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > - USERMAP
>
> > Uses pg_options_to_table(), but I don't think that actually uses
> > SysCache at all, it's just taking the array provided and builds a
> > table out of it, so I think this case is ok.
>
> USERMAP seems a bit
> On 04 May 2016, at 16:58, Tom Lane wrote:
>
> Stas Kelvich writes:
>>> On 03 May 2016, at 00:59, David Fetter wrote:
>>> I suspect that steering that ship would be a good idea starting with
>>> deprecation of the old name in 9.6, etc. hs_filter(), perhaps?
>
>> In 9.5 there already were tsv
Hello Tom,
There's not really a point in using an enum if you use neither the type
(which you shouldn't because if you or the bitmask value you have types
outside the range of the enum), nor the autogenerated numbers.
I do not think that there is such a constraint in C, you can use the enum
Craig Ringer wrote:
> On 4 May 2016 at 13:03, Euler Taveira wrote:
>
> > Question is: is the actual code so useless that it can't even be a 1.0
> > release?
>
> What's committed suffers from a design problem and cannot work correctly,
> nor can it be fixed without an API change and significant r
Andres Freund wrote:
> On 2016-05-04 00:01:20 +0300, Ants Aasma wrote:
> > On Tue, May 3, 2016 at 9:57 PM, Tomas Vondra
> > wrote:
> > > If you tell me how to best test it, I do have a 4-socket server sitting
> > > idly
> > > in the corner (well, a corner reachable by SSH). I can get us some
> >
Hi,
On 2016-05-04 13:35:02 -0300, Alvaro Herrera wrote:
> Honestly, I don't see any strong ground in which to base a revert threat
> for this feature.
It's datastructures are badly designed. But releasing it there's no
pressure to fix that. If this were an intrinsic cost - ok. But it's
not.
>
Stas Kelvich writes:
>> On 04 May 2016, at 16:58, Tom Lane wrote:
>> The other ones are not so problematic because they do not conflict with
>> SQL keywords. It's only delete() and filter() that scare me.
> Okay, so changed functions to ts_setweight, ts_delete, ts_unnest, ts_filter.
Somehow, I
Fabien COELHO writes:
> I understood the point and I do not see real disadvantages. The C standard
> really says that an enum is an int, and compilers just do that.
No, it doesn't say that, and compilers don't just do that. A compiler
is specifically allowed to store an enum in char or short if
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> * debugger ability to print variables symbolically
I might be misunderstanding what you're getting at here, but if you want
to be able to use #define'd values using their name, you can get that by
compiling with -g3. With -g3 and gdb, you can do thin
On 2016-05-04 18:12:45 +0300, Teodor Sigaev wrote:
> > > I get the errors:
> > >
> > > ERROR: attempted to delete invisible tuple
> > > STATEMENT: update foo set count=count+1,text_array=$1 where text_array
> > > @> $2
> > >
> > > And also:
> > >
> > > ERROR: unexpected chunk number 1 (expec
On Wed, May 4, 2016 at 12:42 PM, Andres Freund wrote:
> On 2016-05-04 13:35:02 -0300, Alvaro Herrera wrote:
>> Honestly, I don't see any strong ground in which to base a revert threat
>> for this feature.
>
> It's datastructures are badly designed. But releasing it there's no
> pressure to fix tha
Greetings all,
While testing pg_dump, I discovered that there seems to be an issue when
it comes to TRANSFORMs. I'll be the first to admit that I'm not
terribly familiar with transforms, but I do know that if you create one
using functions from pg_catalog (as our regression tests do), the CREATE
David Rowley writes:
> On 4 May 2016 at 09:18, David Rowley wrote:
>> On 4 May 2016 at 02:10, Tomas Vondra wrote:
>>> There are probably a few reasonably simple things we could do - e.g. ignore
>>> foreign keys with just a single column, as the primary goal of the patch is
>>> improving estimate
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> * debugger ability to print variables symbolically
> I might be misunderstanding what you're getting at here, but if you want
> to be able to use #define'd values using their name, you can get that by
> compiling with -g3. With -g
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> * debugger ability to print variables symbolically
>
> > I might be misunderstanding what you're getting at here, but if you want
> > to be able to use #define'd values using their name,
On 4/19/16 10:23 PM, Noah Misch wrote:
3. Because we use sed we do not tests for plpython3 under Windows. And I
> have trouble with CMake too.
Even if removing regress-python3-mangle.mk happened to be good for PL/Python,
we need build systems flexible enough to implement steps like it without a
On Wed, May 4, 2016 at 1:25 PM, Robert Haas wrote:
> If somebody had even hinted that such a problem might exist, Kevin
> probably would have fixed it before commit, but nobody did. As soon
> as it was raised, Kevin started working on it. That's about all you
> can ask, I think.
Right; I have
Hi,
On 2016-05-03 23:09:28 -0400, Robert Haas wrote:
> So what's the best API for that? One idea is to change
> ModifyWaitEvent to accept events = 0 instead of failing an assertion
> inside WaitEventAdjustEpoll. We don't want to wait for EPOLLERR |
> EPOLLHUP in that case since we'd have to wait
Andres Freund writes:
> Given that poll() has been introduced in SRV3 - which IIRC was below our
> usual baseline - and windows is not an issue for latch, I think it'd
> be ok to rely on it.
I think it's entirely reasonable to say that "if you want high performance
you should have poll(3)". Fail
On Wed, May 4, 2016 at 2:31 PM, Tom Lane wrote:
> Andres Freund writes:
>> Given that poll() has been introduced in SRV3 - which IIRC was below our
>> usual baseline - and windows is not an issue for latch, I think it'd
>> be ok to rely on it.
>
> I think it's entirely reasonable to say that "if
I wrote:
> Andres Freund writes:
>> Given that poll() has been introduced in SRV3 - which IIRC was below our
>> usual baseline - and windows is not an issue for latch, I think it'd
>> be ok to rely on it.
> I think it's entirely reasonable to say that "if you want high performance
> you should ha
The PostgreSQL 9.6 release management team has determined that there
is insufficient consensus at this time to revert any of the patches
mentioned in
http://www.postgresql.org/message-id/CA+TgmoYOWTtBQEL+Bv=w93bvUjbXSUw3uGnp+R29dduZ==8...@mail.gmail.com
because, with the exception of "snapshot too
On Wed, May 4, 2016 at 3:35 PM, Tom Lane wrote:
> I wrote:
>> Andres Freund writes:
>>> Given that poll() has been introduced in SRV3 - which IIRC was below our
>>> usual baseline - and windows is not an issue for latch, I think it'd
>>> be ok to rely on it.
>
>> I think it's entirely reasonable
Robert Haas writes:
> The PostgreSQL 9.6 release management team has determined that there
> is insufficient consensus at this time to revert any of the patches
> mentioned in
> http://www.postgresql.org/message-id/CA+TgmoYOWTtBQEL+Bv=w93bvUjbXSUw3uGnp+R29dduZ==8...@mail.gmail.com
> because, with
Robert Haas writes:
> On Wed, May 4, 2016 at 3:35 PM, Tom Lane wrote:
>> Hmm ... wait, I take that back. poll() is required by SUS v2, which has
>> been our minimum baseline spec for a long time (even my pet dinosaur HPUX
>> has it). As long as we have an answer for Windows, it's hard to argue
On 05/04/2016 12:51 PM, Tom Lane wrote:
Robert Haas writes:
The PostgreSQL 9.6 release management team has determined that there
is insufficient consensus at this time to revert any of the patches
mentioned in
http://www.postgresql.org/message-id/CA+TgmoYOWTtBQEL+Bv=w93bvUjbXSUw3uGnp+R29dduZ==
On Wed, May 4, 2016 at 3:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> The PostgreSQL 9.6 release management team has determined that there
>> is insufficient consensus at this time to revert any of the patches
>> mentioned in
>> http://www.postgresql.org/message-id/CA+TgmoYOWTtBQEL+Bv=w93bvUj
On Wed, May 4, 2016 at 4:00 PM, Joshua D. Drake wrote:
> Just my .02, pretty sure the majority of the community says, "TGL just sent
> -1, argument over." That may or may not be a good thing but his experience
> and depth of knowledge of our code base pretty much seals it for most of us.
Sure, bu
On Wed, May 4, 2016 at 3:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 4, 2016 at 3:35 PM, Tom Lane wrote:
>>> Hmm ... wait, I take that back. poll() is required by SUS v2, which has
>>> been our minimum baseline spec for a long time (even my pet dinosaur HPUX
>>> has it). As lon
Hi,
On 2016-05-04 15:54:32 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, May 4, 2016 at 3:35 PM, Tom Lane wrote:
> >> Hmm ... wait, I take that back. poll() is required by SUS v2, which has
> >> been our minimum baseline spec for a long time (even my pet dinosaur HPUX
> >> has it).
On 05/04/2016 01:03 PM, Robert Haas wrote:
On Wed, May 4, 2016 at 4:00 PM, Joshua D. Drake wrote:
Just my .02, pretty sure the majority of the community says, "TGL just sent
-1, argument over." That may or may not be a good thing but his experience
and depth of knowledge of our code base pretty
On Wed, May 4, 2016 at 2:54 PM, Tom Lane wrote:
> My other design-level complaint is that basing this on foreign keys is
> fundamentally the wrong thing. What actually matters is the unique index
> underlying the FK; that is, if we have "a.x = b.y" and there's a
> compatible unique index on b.y,
Hi,
On 2016-05-04 14:25:14 -0400, Robert Haas wrote:
> On Wed, May 4, 2016 at 12:42 PM, Andres Freund wrote:
> > On 2016-05-04 13:35:02 -0300, Alvaro Herrera wrote:
> >> Honestly, I don't see any strong ground in which to base a revert threat
> >> for this feature.
> >
> > It's datastructures are
Hi,
On 05/04/2016 08:54 PM, Tom Lane wrote:
David Rowley writes:
On 4 May 2016 at 09:18, David Rowley wrote:
On 4 May 2016 at 02:10, Tomas Vondra wrote:
There are probably a few reasonably simple things we could do - e.g. ignore
foreign keys with just a single column, as the primary goal o
Hi,
On 2016-05-04 16:01:18 -0400, Robert Haas wrote:
> On Wed, May 4, 2016 at 3:51 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> The PostgreSQL 9.6 release management team has determined that there
> >> is insufficient consensus at this time to revert any of the patches
> >> mentioned in
> >
Alvaro Herrera wrote:
> Here's a proposed revert patch. Many minor changes (mostly comment
> additions) that were applied as part of this series are kept intact.
> The test_slot_timeline test module and corresponding recovery test
> script are also reverted.
Pushed.
--
Álvaro Herrera
On 5/4/16 2:39 PM, Stephen Frost wrote:
These checks are looking for the functions used by the transform in the
list of functions that pg_dump has loaded, but in 9.5, we don't load any
of the function in pg_catalog, and even with my patches, we only dump
the functions in pg_catalog that have an A
On Tue, May 3, 2016 at 4:05 PM, Andres Freund wrote:
> Hi Jeff,
>
> On 2016-04-29 10:38:55 -0700, Jeff Janes wrote:
>> I've bisected the errors I was seeing, discussed in
>> http://www.postgresql.org/message-id/CAMkU=1xqehc0ok4d+tkjfq1nvuho37pyrkhjp6q8oxifmx7...@mail.gmail.com
>>
>> It look like t
Robert Haas writes:
> On Wed, May 4, 2016 at 2:54 PM, Tom Lane wrote:
>> My other design-level complaint is that basing this on foreign keys is
>> fundamentally the wrong thing. What actually matters is the unique index
>> underlying the FK; that is, if we have "a.x = b.y" and there's a
>> compa
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 5/4/16 2:39 PM, Stephen Frost wrote:
> >These checks are looking for the functions used by the transform in the
> >list of functions that pg_dump has loaded, but in 9.5, we don't load any
> >of the function in pg_catalog, and even wi
On Wed, May 4, 2016 at 3:42 PM, Andres Freund wrote:
> My concern isn't performing checks at snapshot build time and at buffer
> access time. That seems fairly reasonable. My concern is that the
> time->xid mapping used to determine the xid horizon is built at snapshot
> access time. The relevan
Hi,
On 05/04/2016 11:02 PM, Tom Lane wrote:
Robert Haas writes:
On Wed, May 4, 2016 at 2:54 PM, Tom Lane wrote:
My other design-level complaint is that basing this on foreign keys is
fundamentally the wrong thing. What actually matters is the unique index
underlying the FK; that is, if we h
Noah, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> The test suite is now covering 57% of pg_dump.c. I was hoping to get
> that number higher, but time marches on and more tests can certainly be
> added later.
I've managed to get the test suite up another 10%, to 67% of pg_dump.c.
Still qui
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Seems reasonable otherwise.
Attached patch implements this change to not LOCK the table in cases
where we don't need to. I'll push this with my other changes to pg_dump
tomorrow (and I've included it in an updated, complete, set of patches
sent on the thre
I noticed that commit 7e137f846 added functions named max() and min()
to pgbench's expression syntax. Unfortunately, these functions have
zilch to do with what max() and min() do in SQL. They're actually more
like the greatest() and least() server-side functions.
While I can't imagine that we'd
Hi Jeff,
On 2016-05-04 14:00:01 -0700, Jeff Janes wrote:
> On Tue, May 3, 2016 at 4:05 PM, Andres Freund wrote:
> > Hm. I appear to have trouble reproducing this issue (continuing to try)
> > on master as of 8826d8507. Is there any chance you could package up a
> > data directory after the issue
On Wed, May 4, 2016 at 5:02 PM, Tom Lane wrote:
> Very good point, but unless I'm missing something, that is not what the
> current patch does. I'm not sure offhand whether that's an important
> estimation failure mode currently, or if it is whether it would be
> sensible to try to implement that
On Wed, May 4, 2016 at 2:54 PM, Tom Lane wrote:
> I spent some time trying to make a test case that was impossibly slow,
> without any really impressive result: I saw at most about a 25% growth in
> planning time, for a 27-way join with one or two foreign keys per table.
> I noted however that wit
On Wed, May 4, 2016 at 5:51 PM, Robert Haas wrote:
> On Wed, May 4, 2016 at 2:54 PM, Tom Lane wrote:
>> I spent some time trying to make a test case that was impossibly slow,
>> without any really impressive result: I saw at most about a 25% growth in
>> planning time, for a 27-way join with one
Stephen Frost writes:
> Attached patch implements this change to not LOCK the table in cases
> where we don't need to. I'll push this with my other changes to pg_dump
> tomorrow (and I've included it in an updated, complete, set of patches
> sent on the thread where those changes were being discu
On Wed, May 4, 2016 at 1:42 PM, Andres Freund wrote:
>> Surely nobody here is blind to the fact that holding back xmin often
>> creates a lot of bloat for no reason - many or all of the retained old
>> row versions may never be accessed.
>
> Definitely. I *like* the feature.
+1.
>> I do not thin
Hi,
On 2016-05-04 16:22:41 -0500, Kevin Grittner wrote:
> On Wed, May 4, 2016 at 3:42 PM, Andres Freund wrote:
>
> > My concern isn't performing checks at snapshot build time and at buffer
> > access time. That seems fairly reasonable. My concern is that the
> > time->xid mapping used to determ
On Wed, May 4, 2016 at 2:54 PM, Tom Lane wrote:
> I spent some time trying to make a test case that was impossibly slow,
> without any really impressive result: I saw at most about a 25% growth in
> planning time, for a 27-way join with one or two foreign keys per table.
> I noted however that wit
On Wed, May 4, 2016 at 5:41 PM, Tom Lane wrote:
> I noticed that commit 7e137f846 added functions named max() and min()
> to pgbench's expression syntax. Unfortunately, these functions have
> zilch to do with what max() and min() do in SQL. They're actually more
> like the greatest() and least()
On Wed, May 4, 2016 at 6:06 PM, Andres Freund wrote:
>> Some of the proposals involve fairly small tweaks to call
>> MaintainOldSnapshotTimeMapping() from elsewhere or only when
>> something changes (like crossing a minute boundary or seeing that a
>> new TransactionId has been assigned). If you
On 2016-05-04 18:22:27 -0400, Robert Haas wrote:
> On Wed, May 4, 2016 at 6:06 PM, Andres Freund wrote:
> >> Some of the proposals involve fairly small tweaks to call
> >> MaintainOldSnapshotTimeMapping() from elsewhere or only when
> >> something changes (like crossing a minute boundary or seeing
On Wed, May 04, 2016 at 08:14:55AM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Mon, Apr 25, 2016 at 12:39:09AM -0400, Stephen Frost wrote:
> > > * Noah Misch (n...@leadboat.com) wrote:
> > > > On Fri, Apr 22, 2016 at 12:31:41PM -0400, Stephen Frost wrote:
> > > > >
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Attached patch implements this change to not LOCK the table in cases
> > where we don't need to. I'll push this with my other changes to pg_dump
> > tomorrow (and I've included it in an updated, complete, set of patches
> > sent o
On 2016-05-02 14:48:18 -0700, Andres Freund wrote:
> 77a1d1e Department of second thoughts: remove PD_ALL_FROZEN.
Nothing to say here.
> fd31cd2 Don't vacuum all-frozen pages.
Hm. I do wonder if it's going to bite us that we don't have a way to
actually force vacuuming of the whole table (besid
* Noah Misch (n...@leadboat.com) wrote:
> On Wed, May 04, 2016 at 08:14:55AM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> > > On Mon, Apr 25, 2016 at 12:39:09AM -0400, Stephen Frost wrote:
> > > > * Noah Misch (n...@leadboat.com) wrote:
> > > > > On Fri, Apr 22, 2016 at
On Wed, May 4, 2016 at 6:28 PM, Andres Freund wrote:
> On 2016-05-04 18:22:27 -0400, Robert Haas wrote:
>> On Wed, May 4, 2016 at 6:06 PM, Andres Freund wrote:
>> >> Some of the proposals involve fairly small tweaks to call
>> >> MaintainOldSnapshotTimeMapping() from elsewhere or only when
>> >>
On Tue, Mar 29, 2016 at 8:17 PM, Michael Paquier
wrote:
> On Tue, Mar 29, 2016 at 1:11 PM, Thomas Munro
> wrote:
>> (BTW, isn't the select call in libpq_select
>> lacking an exceptfds set, and can't it therefore block forever when
>> there is an error condition on the socket and no timeout?)
>
>
On 2016-05-05 13:30:42 +1200, Thomas Munro wrote:
> That was a red herring. I was confused because SUSv2 and POSIX call
> this argument 'errorfds' and say that sockets *also* tell you about
> errors this way. (Many/most real OSs call the argument 'exceptfds'
> instead and only use it to tell you
On Mon, Apr 18, 2016 at 03:37:21PM -0300, Alvaro Herrera wrote:
> The RMT will publish aggregate, unattributed results after the poll
> closes.
Thanks for voting. Join me in congratulating our top finishers:
1. fd31cd2 Dont vacuum all-frozen pages.
2. "Parallel Query"
3(tie). 3fc6e2d Make the up
On Wed, May 4, 2016 at 9:41 PM, Noah Misch wrote:
> On Mon, Apr 18, 2016 at 03:37:21PM -0300, Alvaro Herrera wrote:
>> The RMT will publish aggregate, unattributed results after the poll
>> closes.
>
> Thanks for voting. Join me in congratulating our top finishers:
>
> 1. fd31cd2 Dont vacuum all-
1 - 100 of 111 matches
Mail list logo
