Re: [HACKERS] Multi-xacts and our process problem

On Mon, May 11, 2015 at 05:33:04PM -0400, Bruce Momjian wrote: > On Tue, May 12, 2015 at 12:29:56AM +0300, Heikki Linnakangas wrote: > > On 05/12/2015 12:00 AM, Bruce Momjian wrote: > > >Multi-xacts were made durable in Postgres 9.3 (released 2013-09-09) to > > >allow primary-key-column-only locks.

[HACKERS] Leftovers after dcae5fac (improve speed of make check-world) in git tree with check-world

Hi all, Since dcae5fac, we use a central path ($GIT_ROOT/tmp_install) to store the installation deliverables during tests. Each module uses a .gitignore with more or less those entries: /log/ /results/ /tmp_check/ First note that /log/ is not used anymore, replaced by /tmp_check/log/ so we could

[HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

Hi all For some time I've wanted a way to "SET SESSION AUTHORISATION" or "SET ROLE" in a way that cannot simply be RESET, so that a connection may be handed to a less-trusted service or application to do some work with. This is most useful for connection pools, where it's currently necessary to h

[HACKERS] Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?

PostgreSQL (<=9.4) trend to smooth buffer write smooth in a checkpoint_completion_target (checkpoint_timeout or checkpoint_segments), but when we use synchronous_commit=off, there is a little problem for the checkpoint_segments target, because xlog write fast(for full page write which the first

Re: [HACKERS] Multi-xacts and our process problem

Robert Haas wrote: > On Mon, May 11, 2015 at 7:04 PM, Tom Lane wrote: > > I think there's nobody, or at least very few people, who are getting > > paid to find/fix bugs rather than write cool new features. This is > > problematic. It doesn't help when key committers are overwhelmed by > > trying

Re: [HACKERS] Multi-xacts and our process problem

On Tue, May 12, 2015 at 4:55 AM, Andres Freund wrote: > > On 2015-05-11 19:04:32 -0400, Tom Lane wrote: > > I think there's nobody, or at least very few people, who are getting > > paid to find/fix bugs rather than write cool new features. This is > > problematic. It doesn't help when key commit

Re: [HACKERS] Final Patch for GROUPING SETS

>I think the problem is "just" that for each variable, in each grouping >set - a very large number in a large cube - we're recursing through the >whole ChainAggregate tree, as each Var just points to a var one level >lower. For small values of very large, that is. Had a little thinko there. Its s

Re: [HACKERS] Final Patch for GROUPING SETS

On 2015-04-30 05:35:26 +0100, Andrew Gierth wrote: > > "Andres" == Andres Freund writes: > > Andres> This is not a real review. I'm just scanning through the > Andres> patch, without reading the thread, to understand if I see > Andres> something "worthy" of controversy. While scanning I mi

Re: [HACKERS] Minor ON CONFLICT related fixes

On Mon, May 11, 2015 at 7:34 PM, Andres Freund wrote: > You should try to understand why it's failing. Just prohibiting the > rules, without understanding what's actually going on, could very well > hide a real bug. It's not as if I have no idea. ReplaceVarsFromTargetList() is probably quite conf

Re: [HACKERS] pg_basebackup vs. Windows and tablespaces

On Tue, May 12, 2015 at 5:50 AM, Andrew Dunstan wrote: > > > On 05/11/2015 02:02 AM, Amit Kapila wrote: >> >> On Sun, May 10, 2015 at 6:01 AM, Andrew Dunstan mailto:and...@dunslane.net>> wrote: >> > >> > >> > >> > This generally looks good, but I have a couple of questions before I commit it. >> >

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

On 2015/05/12 7:42, Tom Lane wrote: > On further consideration ... Thanks for the consideration! > I don't much like the division of labor between LockForeignRow and > FetchForeignRow. In principle that would lead to not one but two > extra remote accesses per locked row in SELECT FOR UPDATE, at

[HACKERS] Improving regression tests to check LOCK TABLE and table permissions

Hi all, As mentioned in this thread, it would be good to have regression tests to test the interactions with permissions and LOCK TABLE: http://www.postgresql.org/message-id/20150511195335.ge30...@tamriel.snowman.net Attached is a patch achieving that. Note that it does some checks on the modes SH

Re: [HACKERS] LOCK TABLE Permissions

On Tue, May 12, 2015 at 4:53 AM, Stephen Frost wrote: > Yeah, it might not be bad to have tests for all the different lock types > and make sure that the permissions match up. I'd probably put those > tests into 'permissions.sql' instead though. You mean privileges.sql, right? I just wrote a patc

Re: [HACKERS] Minor ON CONFLICT related fixes

On 2015-05-11 19:33:02 -0700, Peter Geoghegan wrote: > On Mon, May 11, 2015 at 7:22 PM, Peter Geoghegan wrote: > > You just get an error within the > > optimizer following rewriting of a query involving the application of > > a rule that specifies an ON CONFLICT DO UPDATE alternative/DO INSTEAD >

Re: [HACKERS] Minor ON CONFLICT related fixes

On Mon, May 11, 2015 at 7:22 PM, Peter Geoghegan wrote: > You just get an error within the > optimizer following rewriting of a query involving the application of > a rule that specifies an ON CONFLICT DO UPDATE alternative/DO INSTEAD > action. I found it would say: "variable not found in subplan

Re: [HACKERS] Minor ON CONFLICT related fixes

On Mon, May 11, 2015 at 7:11 PM, Andres Freund wrote: > Do I understand correctly that you cut this out because there > essentially was a ruleutils bug with with EXCLUDED? If so, I don't find > that acceptable. I'm pretty strictly convincded that independent of rule > support, we shouldn't add thi

Re: [HACKERS] Minor ON CONFLICT related fixes

HI, Don't have time to go through this in depth. On 2015-05-11 18:53:22 -0700, Peter Geoghegan wrote: > Note that the patch proposes to de-support CREATE RULE with an > alternative action involving ON CONFLICT DO UPDATE. Such a rule seems > particularly questionable to me, and I'm pretty sure it

Re: [HACKERS] Minor ON CONFLICT related fixes

On Mon, May 11, 2015 at 6:53 PM, Peter Geoghegan wrote: > Attached patch fixes some issues with ON CONFLICT DO UPDATE/DO > NOTHING. There is a commit message which explains the changes at a > high level. I just realized that there is a silly bug here. Attached is a fix that applies on top of the

[HACKERS] Minor ON CONFLICT related fixes

Attached patch fixes some issues with ON CONFLICT DO UPDATE/DO NOTHING. There is a commit message which explains the changes at a high level. The only real bug fix is around deparsing by ruleutils.c. Note that the patch proposes to de-support CREATE RULE with an alternative action involving ON CON

Re: [HACKERS] Multi-xacts and our process problem

On Mon, May 11, 2015 at 7:04 PM, Tom Lane wrote: > I think there's nobody, or at least very few people, who are getting > paid to find/fix bugs rather than write cool new features. This is > problematic. It doesn't help when key committers are overwhelmed by > trying to process other peoples' pa

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

Hi, Let me back to the original concern and show possible options we can take here. At least, the latest master is not usable to implement custom-join logic without either of these options. option-1) Revert create_plan_recurse() to non-static function for extensions. It is the simplest solution,

Re: [HACKERS] Multi-xacts and our process problem

On 05/11/2015 04:18 PM, Simon Riggs wrote: On 11 May 2015 at 23:47, Bruce Momjian mailto:br...@momjian.us>> wrote: On Mon, May 11, 2015 at 03:42:26PM -0700, Joshua Drake wrote: > >The releases themselves are not the problem, but rather the volume of > >bugs and our slowness in getti

Re: [HACKERS] Multi-xacts and our process problem

On 05/11/2015 04:04 PM, Tom Lane wrote: Bruce Momjian writes: On Mon, May 11, 2015 at 03:42:26PM -0700, Joshua Drake wrote: What I am arguing is that the release cycle is at least a big part of the problem. We are trying to get so many new features that bugs are increasing and quality is decr

Re: [HACKERS] Patch to improve a few appendStringInfo* calls

On 4/11/15 6:25 AM, David Rowley wrote: > I've attached a small patch which just fixes a few appendStringInfo* > calls that are not quite doing things the way that it was intended. done -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Fixing busted citext function declarations

On May 11, 2015, at 5:01 PM, Tom Lane wrote: > Me too. Something fell through the cracks rather badly there :-(. > Would you check your commit history to see if anything else got missed? Let’s see… In https://github.com/theory/citext/commit/4030b4e1ad9fd9f994a6cdca1126a903682acae4 I copied y

Re: [HACKERS] pg_basebackup vs. Windows and tablespaces

On 05/11/2015 02:02 AM, Amit Kapila wrote: On Sun, May 10, 2015 at 6:01 AM, Andrew Dunstan > wrote: > > > > This generally looks good, but I have a couple of questions before I commit it. > > First, why is the new option for the BASE_BACKUP command of the Streamin

Re: [HACKERS] Fixing busted citext function declarations

"David E. Wheeler" writes: > On May 5, 2015, at 9:40 AM, Tom Lane wrote: >> In >> http://www.postgresql.org/message-id/bn1pr04mb37467aa1d412223b3d4a595df...@bn1pr04mb374.namprd04.prod.outlook.com >> it's revealed that the citext extension misdeclares its versions of >> regexp_matches(): they shou

Re: [HACKERS] Multi-xacts and our process problem

On 2015-05-11 19:04:32 -0400, Tom Lane wrote: > I think there's nobody, or at least very few people, who are getting > paid to find/fix bugs rather than write cool new features. This is > problematic. It doesn't help when key committers are overwhelmed by > trying to process other peoples' patche

Re: [HACKERS] Fixing busted citext function declarations

Tom, On May 5, 2015, at 9:40 AM, Tom Lane wrote: > In > http://www.postgresql.org/message-id/bn1pr04mb37467aa1d412223b3d4a595df...@bn1pr04mb374.namprd04.prod.outlook.com > it's revealed that the citext extension misdeclares its versions of > regexp_matches(): they should return SETOF text[] but

Re: [HACKERS] Multi-xacts and our process problem

On 11 May 2015 at 23:47, Bruce Momjian wrote: > On Mon, May 11, 2015 at 03:42:26PM -0700, Joshua Drake wrote: > > >The releases themselves are not the problem, but rather the volume of > > >bugs and our slowness in getting additional people involved to remove > > >data corruption bugs more quickl

Re: [HACKERS] Multi-xacts and our process problem

Bruce Momjian writes: > On Mon, May 11, 2015 at 03:42:26PM -0700, Joshua Drake wrote: >> What I am arguing is that the release cycle is at least a big part >> of the problem. We are trying to get so many new features that bugs >> are increasing and quality is decreasing. > Now that is an interest

Re: [HACKERS] Multixid hindsight design

Heikki Linnakangas writes: > So the lesson here is that having a permanent pg_multixact is not nice, > and we should get rid of it. Here's how to do that: That would be cool, but ... > Looking at the tuple header, the CID and CTID fields are only needed, > when either xmin or xmax is running.

Re: [HACKERS] Multi-xacts and our process problem

On Mon, May 11, 2015 at 03:42:26PM -0700, Joshua Drake wrote: > >The releases themselves are not the problem, but rather the volume of > >bugs and our slowness in getting additional people involved to remove > >data corruption bugs more quickly and systematically. Our reputation > >for reliability

Re: [HACKERS] Multi-xacts and our process problem

On 05/11/2015 02:15 PM, Bruce Momjian wrote: On Mon, May 11, 2015 at 02:11:48PM -0700, Joshua Drake wrote: Here are some options Slow down the release cycle The shortness of the release cycle puts a preference on adding features versus providing a more mature outcome. or Increas

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

On further consideration ... I don't much like the division of labor between LockForeignRow and FetchForeignRow. In principle that would lead to not one but two extra remote accesses per locked row in SELECT FOR UPDATE, at least in the case that an EvalPlanQual recheck is required. (I see that i

Re: [HACKERS] deparsing utility commands

David Steele wrote: > I have reviewed and tested this patch and everything looks good to me. > It also looks like you added better coverage for schema DDL, which is a > welcome addition. Thanks -- I have pushed this now. My hope is to get this test module extended quite a bit, not only to cover

Re: [HACKERS] Multi-xacts and our process problem

On Tue, May 12, 2015 at 12:29:56AM +0300, Heikki Linnakangas wrote: > On 05/12/2015 12:00 AM, Bruce Momjian wrote: > >Multi-xacts were made durable in Postgres 9.3 (released 2013-09-09) to > >allow primary-key-column-only locks. 1.7 years later, we are still > >dealing with bugs related to this fe

Re: [HACKERS] Multi-xacts and our process problem

On 05/12/2015 12:00 AM, Bruce Momjian wrote: Multi-xacts were made durable in Postgres 9.3 (released 2013-09-09) to allow primary-key-column-only locks. 1.7 years later, we are still dealing with bugs related to this feature. Obviously, something is wrong. There were many 9.3 minor releases co

[HACKERS] Multixid hindsight design

I'd like to discuss how we should've implemented the infamous 9.3 multixid/row-locking stuff, and perhaps still should in 9.6. Hindsight is always 20/20 - I'll readily admit that I didn't understand the problems until well after the release - so this isn't meant to bash what's been done. Rather

Re: [HACKERS] Multi-xacts and our process problem

On Mon, May 11, 2015 at 02:11:48PM -0700, Joshua Drake wrote: > > On 05/11/2015 02:00 PM, Bruce Momjian wrote: > > >I think we now know that our inaction didn't serve us well. The > >question is how can we identify chronic problems and get resources > >involved sooner. I feel we have been "asle

Re: [HACKERS] Multi-xacts and our process problem

On 05/11/2015 02:00 PM, Bruce Momjian wrote: I think we now know that our inaction didn't serve us well. The question is how can we identify chronic problems and get resources involved sooner. I feel we have been "asleep at the wheel" to some extent on this. Here are some options Slow down

[HACKERS] Multi-xacts and our process problem

Multi-xacts were made durable in Postgres 9.3 (released 2013-09-09) to allow primary-key-column-only locks. 1.7 years later, we are still dealing with bugs related to this feature. Obviously, something is wrong. There were many 9.3 minor releases containing multi-xacts fixes, and these fixes hav

Re: [HACKERS] multixacts woes

On 05/11/2015 10:24 AM, Josh Berkus wrote: In terms of adding a new GUC in 9.5: can't we take a stab at auto-tuning this instead of adding a new GUC? We already have a bunch of freezing GUCs which fewer than 1% of our user base has any idea how to set. That is a documentation problem not a u

Re: [HACKERS] LOCK TABLE Permissions

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, May 12, 2015 at 4:01 AM, Stephen Frost wrote: > > * Michael Paquier (michael.paqu...@gmail.com) wrote: > >> On Mon, May 11, 2015 at 10:32 PM, Stephen Frost wrote: > >> > Now for a blast from the past... This came up again on IRC rece

Re: [HACKERS] Disabling trust/ident authentication configure option

On Thu, May 7, 2015 at 4:57 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Thu, May 7, 2015 at 11:02 AM, Stephen Frost wrote: >> > I realize it's not going to be popular, but I'd love to have 'trust' >> > only allowed if a command-line option is passed to the postma

Re: [HACKERS] LOCK TABLE Permissions

On Tue, May 12, 2015 at 4:01 AM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> On Mon, May 11, 2015 at 10:32 PM, Stephen Frost wrote: >> > Now for a blast from the past... This came up again on IRC recently and >> > reminded me that I ran into the same issue a co

Re: [HACKERS] LOCK TABLE Permissions

All, * Stephen Frost (sfr...@snowman.net) wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > if (lockmode == AccessShareLock) > > > aclresult = pg_class_aclcheck(reloid, GetUserId(), > > > ACL_SELECT); > > > + else i

Re: [HACKERS] deparsing utility commands

On 5/8/15 3:29 PM, Alvaro Herrera wrote: >> Here is a complete version. Barring serious problems, I intend to >> commit this on Monday. I have reviewed and tested this patch and everything looks good to me. It also looks like you added better coverage for schema DDL, which is a welcome addition.

[HACKERS] Re: [BUGS] BUG #13148: Unexpected deferred EXCLUDE constraint violation on derived table

On Mon, May 11, 2015 at 9:47 AM, Andres Freund wrote: > On 2015-05-10 16:01:53 -0400, Tom Lane wrote: >> The cause of the problem seems to be that the UPDATE performs a HOT update >> of the new tuple, leaving in this case a dead tuple at (0,2) that is HOT >> updated by (0,3). When unique_key_rech

Re: [HACKERS] a fast bloat measurement tool (was Re: Measuring relation free space)

At 2015-05-11 19:15:47 +0200, and...@anarazel.de wrote: > > TBH, I'd rather not touch unrelated things right now. We're pretty > badly behind... OK. That patch is independent; just ignore it. > I don't really care how it's named, as long as it makes clear that > it's not an exact measurement. No

Re: [HACKERS] LOCK TABLE Permissions

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Mon, May 11, 2015 at 10:32 PM, Stephen Frost wrote: > > Now for a blast from the past... This came up again on IRC recently and > > reminded me that I ran into the same issue a couple years back. Updated > > patch includes the refactoring

Re: [HACKERS] LOCK TABLE Permissions

On Mon, May 11, 2015 at 10:32 PM, Stephen Frost wrote: > Now for a blast from the past... This came up again on IRC recently and > reminded me that I ran into the same issue a couple years back. Updated > patch includes the refactoring suggested and includes documentation. > > Barring objections

Re: [HACKERS] Postgres GSSAPI Encryption

Stephen Frost writes: > Robbie, > > * Robbie Harwood (rharw...@redhat.com) wrote: > >> We'd I think also want a new kind of HBA entry (probably something along >> the lines of `hostgss` to contrast with `hostssl`), but I'm not sure >> what we'd want to do for the counterpart of `hostnossl` (`host

Re: [HACKERS] Use outerPlanState() consistently in executor code

On Mon, May 4, 2015 at 1:23 PM, Robert Haas wrote: > I fixed several whitespace errors, reverted the permissions changes > you included Sorry about the permission changes - didn't notice that bite. Thanks, Qingqing -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] multixacts woes

Robert Haas wrote: > OK, I have made this change. Barring further trouble reports, this > completes the multixact work I plan to do for the next release. Many thanks for all the effort here -- much appreciated. > 2. The recent changes adjust things - for good reason - so that the > safe thresho

Re: [HACKERS] multixacts woes

Josh Berkus wrote: > In terms of adding a new GUC in 9.5: can't we take a stab at auto-tuning > this instead of adding a new GUC? We already have a bunch of freezing > GUCs which fewer than 1% of our user base has any idea how to set. If you have development resources to pour onto 9.5, I think i

Re: [HACKERS] multixacts woes

On 05/11/2015 09:54 AM, Robert Haas wrote: > OK, I have made this change. Barring further trouble reports, this > completes the multixact work I plan to do for the next release. Here > is what is outstanding: > > 1. We might want to introduce a GUC to control the point at which > member offset u

Re: [HACKERS] a fast bloat measurement tool (was Re: Measuring relation free space)

Hi, On 2015-05-11 16:57:08 +0530, Abhijit Menon-Sen wrote: > I've attached an updated patch for pgstatbloat, as well as a patch to > replace two uses of BuildTupleFromCStrings() elsewhere in pgstattuple. TBH, I'd rather not touch unrelated things right now. We're pretty badly behind... > I've ma

Re: [HACKERS] pg_upgrade: quote directory names in delete_old_cluster script

On Wed, Apr 29, 2015 at 10:52:45PM -0400, Bruce Momjian wrote: > On Mon, Feb 16, 2015 at 05:03:45PM -0500, Bruce Momjian wrote: > > > All of our makefiles use single quotes, so effectively the only > > > character we don't support in directory paths is the single quote itself. > > > > This seems t

Re: [HACKERS] multixacts woes

On Mon, May 11, 2015 at 10:11 AM, Noah Misch wrote: > On Mon, May 11, 2015 at 08:29:05AM -0400, Robert Haas wrote: >> Given your concerns, and the need to get a fix for this out the door >> quickly, what I'm inclined to do for the present is go bump the >> threshold from 25% of MaxMultiXact to 50%

[HACKERS] Re: [BUGS] BUG #13148: Unexpected deferred EXCLUDE constraint violation on derived table

Hi, On 2015-05-10 16:01:53 -0400, Tom Lane wrote: > The cause of the problem seems to be that the UPDATE performs a HOT update > of the new tuple, leaving in this case a dead tuple at (0,2) that is HOT > updated by (0,3). When unique_key_recheck() is invoked for (0,2), it > believes, correctly, t

Re: [HACKERS] initdb start server recommendation

On Fri, May 1, 2015 at 10:14:13AM -0400, Bruce Momjian wrote: > Currently initdb outputs suggested text on starting the server: > > Success. You can now start the database server using: > > /u/pgsql/bin/postgres -D /u/pgsql/data > or > /u/pgsql/bin/pg_ctl -D

Re: [HACKERS] Streaming replication and WAL archive interactions

On 05/08/2015 04:21 PM, Heikki Linnakangas wrote: On 04/22/2015 10:07 AM, Michael Paquier wrote: On Wed, Apr 22, 2015 at 3:38 PM, Heikki Linnakangas wrote: I feel that the best approach is to archive the last, partial segment, but with the .partial suffix. I don't see any plausible real-wold s

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

I wrote: > Etsuro Fujita writes: >> On 2015/05/11 8:50, Tom Lane wrote: >>> I wonder if we should instead add a "ScanState*" field and expect the >>> core code to set that up (ExecOpenScanRelation could do it with minor >>> API changes...). >> Sorry, I don't understand clearly what you mean, but

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

Etsuro Fujita writes: > On 2015/05/11 8:50, Tom Lane wrote: >> In particular, I find the addition of "void *fdw_state" to ExecRowMark >> to be pretty questionable. That does not seem like a good place to keep >> random state. (I realize that WHERE CURRENT OF keeps some state in >> ExecRowMark, b

Re: [HACKERS] tzdata and 9.4.2, etc.

On Mon, May 11, 2015 at 10:13 AM, Thom Brown wrote: >> We are now three tzdata changes behind. There are bugs in pg_dump >> which create real restore errors for people using PostGIS, one of our >> most popular extensions. >> >> Can we please wrap and ship 9.4.2, etc., and do it soon? > > +1 I'm

Re: [HACKERS] tzdata and 9.4.2, etc.

On 4 May 2015 at 22:42, David Fetter wrote: > Folks, > > We are now three tzdata changes behind. There are bugs in pg_dump > which create real restore errors for people using PostGIS, one of our > most popular extensions. > > Can we please wrap and ship 9.4.2, etc., and do it soon? +1 -- Thom

Re: [HACKERS] multixacts woes

On Mon, May 11, 2015 at 08:29:05AM -0400, Robert Haas wrote: > Given your concerns, and the need to get a fix for this out the door > quickly, what I'm inclined to do for the present is go bump the > threshold from 25% of MaxMultiXact to 50% of MaxMultiXact without > changing anything else. +1 >

Re: [HACKERS] LOCK TABLE Permissions

All, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > if (lockmode == AccessShareLock) > > aclresult = pg_class_aclcheck(reloid, GetUserId(), > > ACL_SELECT); > > + else if (lockmode == RowExclusiveLock) > > + aclresult =

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

On 2015/05/11 8:50, Tom Lane wrote: > Etsuro Fujita writes: >> [ EvalPlanQual-v6.patch ] > > I've started to study this in a little more detail, and I'm not terribly > happy with some of the API decisions in it. Thanks for taking the time to review the patch! > In particular, I find the additio

Re: [HACKERS] "unaddressable bytes" in BRIN

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > What I think this means is that during an index build > brin_minmax_add_value() called numeric_lt() which detoasted one of its > input values; later, brin_doinsert() inserts a tuple containing the > value, but it tries to use more bytes than were

Re: [HACKERS] multixacts woes

On Mon, May 11, 2015 at 12:56 AM, Noah Misch wrote: > On Sun, May 10, 2015 at 09:17:58PM -0400, Robert Haas wrote: >> On Sun, May 10, 2015 at 1:40 PM, Noah Misch wrote: >> > I don't know whether this deserves prompt remediation, but if it does, I >> > would >> > look no further than the hard-cod

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

On Sun, May 10, 2015 at 11:07 PM, Andres Freund wrote: > On 2015-05-10 22:51:33 -0400, Robert Haas wrote: >> > And there's definitely some things >> > around that pretty much only still exist because changing them would >> > break too much stuff. >> >> Such as what? > > Without even thinking about

Re: [HACKERS] a fast bloat measurement tool (was Re: Measuring relation free space)

Hi Andres. I've attached an updated patch for pgstatbloat, as well as a patch to replace two uses of BuildTupleFromCStrings() elsewhere in pgstattuple. I've made the changes you mentioned in your earlier mail, except that I have not changed the name pending further suggestions about what would be