Re: [HACKERS] pg_dump broken for non-super user

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

Re: [HACKERS] what to revert

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? > >

Re: [HACKERS] Is pg_control file crashsafe?

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

Re: [HACKERS] Is pg_control file crashsafe?

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

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

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

Re: [HACKERS] pg_dump vs. TRANSFORMs

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

Re: [HACKERS] what to revert

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

Re: [HACKERS] what to revert

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 >

Re: [HACKERS] Postgres 9.6 scariest patch tournament

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

Re: [HACKERS] Postgres 9.6 scariest patch tournament

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.

Re: [HACKERS] Postgres 9.6 scariest patch tournament

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

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

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

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

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 >>

Re: [HACKERS] what to revert

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 >> >>

Re: [HACKERS] pg_dump dump catalog ACLs

* 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

Re: [HACKERS] Reviewing freeze map code

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

Re: [HACKERS] pg_dump broken for non-super user

* 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

Re: [HACKERS] pg_dump dump catalog ACLs

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: > > > > >

Re: [HACKERS] what to revert

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

Re: [HACKERS] what to revert

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

Re: [HACKERS] New pgbench functions are misnamed

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

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

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

Re: [HACKERS] what to revert

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

Re: [HACKERS] what to revert

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.

Re: [HACKERS] pg_dump broken for non-super user

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

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

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

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

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

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

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

Re: [HACKERS] atomic pin/unpin causing errors

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

[HACKERS] New pgbench functions are misnamed

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

Re: [HACKERS] pg_dump broken for non-super user

* 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

Re: [HACKERS] pg_dump dump catalog ACLs

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

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

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

Re: [HACKERS] what to revert

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 >

Re: [HACKERS] pg_dump vs. TRANSFORMs

* 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

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

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,

Re: [HACKERS] atomic pin/unpin causing errors

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

Re: [HACKERS] pg_dump vs. TRANSFORMs

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

Re: [HACKERS] Timeline following for logical slots

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

Re: [HACKERS] release management team statement on patch reverts

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

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

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

Re: [HACKERS] what to revert

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. > > > >

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

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

Re: [HACKERS] release management team statement on patch reverts

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

Re: [HACKERS] modifying WaitEventSets (was: Performance degradation in commit ac1d794)

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

Re: [HACKERS] modifying WaitEventSets (was: Performance degradation in commit ac1d794)

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

Re: [HACKERS] release management team statement on patch reverts

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

Re: [HACKERS] release management team statement on patch reverts

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 >>

Re: [HACKERS] release management team statement on patch reverts

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

Re: [HACKERS] modifying WaitEventSets (was: Performance degradation in commit ac1d794)

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

Re: [HACKERS] release management team statement on patch reverts

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 >

Re: [HACKERS] modifying WaitEventSets (was: Performance degradation in commit ac1d794)

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

[HACKERS] release management team statement on patch reverts

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

Re: [HACKERS] modifying WaitEventSets (was: Performance degradation in commit ac1d794)

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

Re: [HACKERS] modifying WaitEventSets (was: Performance degradation in commit ac1d794)

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

Re: [HACKERS] modifying WaitEventSets (was: Performance degradation in commit ac1d794)

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

Re: [HACKERS] modifying WaitEventSets (was: Performance degradation in commit ac1d794)

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

Re: [HACKERS] what to revert

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,

Re: [HACKERS] Proposal: Remove regress-python3-mangle.mk

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

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

* 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

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

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 >

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

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

[HACKERS] pg_dump vs. TRANSFORMs

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

Re: [HACKERS] what to revert

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

Re: [HACKERS] atomic pin/unpin causing errors

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

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

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

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

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

Re: [HACKERS] Naming of new tsvector functions

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

Re: [HACKERS] what to revert

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. >

Re: [HACKERS] what to revert

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

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

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

Re: [HACKERS] what to revert

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

Re: [HACKERS] Naming of new tsvector functions

> 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

Re: [HACKERS] pg_dump broken for non-super user

* 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. >

Re: [HACKERS] pg_dump broken for non-super user

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

Re: [HACKERS] pg_dump broken for non-super user

* 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

Re: [HACKERS] atomic pin/unpin causing errors

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

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

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

Re: [HACKERS] Segmentation fault when max_parallel degree is very High

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.

Re: [HACKERS] tsvector filter problem

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

Re: [HACKERS] Make PG's "NOT NULL"s and attnotnull ("is_nullable") conform to SQL-2011

"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

Re: [HACKERS] pg_dump broken for non-super user

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,

Re: [HACKERS] Is pg_control file crashsafe?

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 >>

Re: [HACKERS] 9.5.2: "sql" as reserved word?

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

Re: [HACKERS] old_snapshot_threshold's interaction with hash index

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, >

[HACKERS] Update to contrib/chkpass

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

Re: [HACKERS] 9.5.2: "sql" as reserved word?

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

[HACKERS] 9.5.2: "sql" as reserved word?

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

Re: [HACKERS] Is pg_control file crashsafe?

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

Re: [HACKERS] Naming of new tsvector functions

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

Re: [HACKERS] pg_dump broken for non-super user

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

Re: [HACKERS] Naming of new tsvector functions

> 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

Re: [HACKERS] pg_dump broken for non-super user

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.

[HACKERS] tsvector filter problem

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

Re: [HACKERS] pg_dump broken for non-super user

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 >

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

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

Re: [HACKERS] pg_dump dump catalog ACLs

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

Re: [HACKERS] atomic pin/unpin causing errors

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 > > > >

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

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,

Re: [HACKERS] Is pg_control file crashsafe?

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

  1   2   >