On Wed, May 4, 2016 at 8:31 PM, Tom Lane wrote:
>
> 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 Thu, May 5, 2016 at 4:32 PM, Tom Lane wrote:
> Amit Kapila writes:
>> How about using 512 bytes as a write size and perform direct writes rather
>> than going via OS buffer cache for control file?
>
> Wouldn't that fail outright under a lot of implementations of direct write;
> ie the request
On Thu, May 5, 2016 at 5:35 AM, 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
On Thu, May 5, 2016 at 8:44 AM, Andres Freund wrote:
>
> On 2016-05-05 06:08:39 +0300, Ants Aasma wrote:
> > On 5 May 2016 1:28 a.m., "Andres Freund" wrote:
> > > On 2016-05-04 18:22:27 -0400, Robert Haas wrote:
> > > > How would the semantics change?
> > >
> > > Right now the time for computing
Amit Kapila writes:
> How about using 512 bytes as a write size and perform direct writes rather
> than going via OS buffer cache for control file?
Wouldn't that fail outright under a lot of implementations of direct write;
ie the request needs to be page-aligned, for some not-very-determinate
va
On Wed, May 4, 2016 at 8:03 PM, Tom Lane wrote:
>
> 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 defau
On 5 May 2016 at 06:54, 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 prim
Peter Eisentraut writes:
> 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
On 2016-05-05 06:08:39 +0300, Ants Aasma wrote:
> On 5 May 2016 1:28 a.m., "Andres Freund" wrote:
> > On 2016-05-04 18:22:27 -0400, Robert Haas wrote:
> > > How would the semantics change?
> >
> > Right now the time for computing the snapshot is relevant, if
> > maintenance of xids is moved, it'll
On 5 May 2016 1:28 a.m., "Andres Freund" wrote:
> On 2016-05-04 18:22:27 -0400, Robert Haas wrote:
> > How would the semantics change?
>
> Right now the time for computing the snapshot is relevant, if
> maintenance of xids is moved, it'll likely be tied to the time xids are
> assigned. That seems
On 05/04/2016 06:56 PM, Robert Haas wrote:
> 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
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-
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 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 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 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
>> >>
* 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 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
* 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 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:
> > > > >
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 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 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 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
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 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
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 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
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: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
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
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
* 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
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
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
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
* 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
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
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
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
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
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
> >
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 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
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,
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
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 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
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: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 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==
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
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
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
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
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
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
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
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
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
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
* 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,
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
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
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
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
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
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
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
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
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.
>
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
> >
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
> 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
* 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
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:
> 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
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
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
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 *
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
"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
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
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
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
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
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 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
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 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
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 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
> 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
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
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
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
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
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 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
1 - 100 of 111 matches
Mail list logo
