Re: Updated macOS start scripts

> On Nov 15, 2017, at 11:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >>> On Nov 15, 2017, at 8:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> The stuff in contrib/start-scripts/osx/ does not, as

Re: Updated macOS start scripts

> On Nov 15, 2017, at 8:32 AM, Tom Lane wrote: > > The stuff in contrib/start-scripts/osx/ does not, as far as I know, > work at all on any recent release of macOS, because SystemStarter > is long gone. I propose replacing it with the attached, which > I've tested on

Re: Updated macOS start scripts

> On Nov 15, 2017, at 1:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> I have tested this on 10.11.6. I had no trouble following the instructions >> in the README and everything worked as described. >> As fa

Re: Updated macOS start scripts

> On Nov 28, 2017, at 11:17 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> Upon further review, I have noticed that `pg_ctl stop` does not work once >> the org.postgresql.postgres service has been started. I was tr

Re: pgindent run?

> On Nov 28, 2017, at 11:51 AM, Robert Haas wrote: > > If nobody minds too much, I'd like to update typedefs.list and > pgindent the whole tree again. We've generally done a pretty good job > with pgindenting patches as they are committed this cycle, but we're > starting

Re: Updated macOS start scripts

> On Nov 15, 2017, at 12:02 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > >> On Nov 15, 2017, at 11:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Mark Dilger <hornschnor...@gmail.com> writes: >>>> On Nov 15, 2017, at 8:3

Re: pgindent run?

> On Nov 28, 2017, at 2:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >>> On Nov 28, 2017, at 12:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I think that'd be taking it too far, especially given tha

Re: pgindent run?

> On Nov 28, 2017, at 12:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> I have no objection, but if the community intends to keep everything >> indented per project standards, why is there no git hook to r

Re: Updated macOS start scripts

> On Nov 28, 2017, at 1:22 PM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> wrote: > > On 11/28/17 14:07, Mark Dilger wrote: >> Upon further review, I have noticed that `pg_ctl stop` does not work once >> the org.postgresql.postgres service has been

Re: Code cleanup patch submission for extended_stats.c

> On Nov 25, 2017, at 2:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> It looks to me like Alvaro introduced this in the original version of the >> file which >> was created in commit 7b504eb282ca

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Nov 25, 2017, at 3:33 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> > wrote: > > > > On 11/25/2017 10:01 PM, Mark Dilger wrote: >> >>> On Nov 18, 2017, at 12:28 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> >>> wrote

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Nov 18, 2017, at 12:28 PM, Tomas Vondra > wrote: > > Hi, > > Attached is an updated version of the patch, adopting the psql describe > changes introduced by 471d55859c11b. > > regards > > -- > Tomas Vondra http://www.2ndQuadrant.com >

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Nov 18, 2017, at 12:28 PM, Tomas Vondra > wrote: > > Hi, > > Attached is an updated version of the patch, adopting the psql describe > changes introduced by 471d55859c11b. > > regards > > -- > Tomas Vondra http://www.2ndQuadrant.com >

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Nov 18, 2017, at 12:28 PM, Tomas Vondra > wrote: > > Hi, > > Attached is an updated version of the patch, adopting the psql describe > changes introduced by 471d55859c11b. > > regards > > -- > Tomas Vondra http://www.2ndQuadrant.com >

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Nov 18, 2017, at 12:28 PM, Tomas Vondra > wrote: > > Hi, > > Attached is an updated version of the patch, adopting the psql describe > changes introduced by 471d55859c11b. Hi Tomas, In src/backend/statistics/dependencies.c, you have introduced a comment:

Code cleanup patch submission for extended_stats.c

Hackers, Alvaro, In src/backend/statistics/extended_stats.c, in statext_store, there is a section: Datum values[Natts_pg_statistic_ext]; boolnulls[Natts_pg_statistic_ext]; boolreplaces[Natts_pg_statistic_ext]; memset(nulls, 1, Natts_pg_statistic_ext *

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Nov 18, 2017, at 12:28 PM, Tomas Vondra > wrote: > > Hi, > > Attached is an updated version of the patch, adopting the psql describe > changes introduced by 471d55859c11b. > > regards > > -- > Tomas Vondra http://www.2ndQuadrant.com >

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Dec 13, 2017, at 12:07 AM, Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2017-07-17 12:54:31 -0700, Mark Dilger wrote: >> These types provide a 4-byte datatype for storing real-world second >> precision timestamps, as occur in many log files. &

Re: Boolean partitions syntax

> On Dec 12, 2017, at 10:32 PM, Amit Langote > wrote: > > On 2017/12/12 15:39, Amit Langote wrote: >> On 2017/12/12 15:35, Amit Langote wrote: >>> Works for me, updated patch attached. >> >> Oops, attached the old one with the last email. >> >> Updated one

Re: WIP: BRIN multi-range indexes

> On Nov 18, 2017, at 12:45 PM, Tomas Vondra > wrote: > > Hi, > > Apparently there was some minor breakage due to duplicate OIDs, so here > is the patch series updated to current master. > > regards > > -- > Tomas Vondra

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Nov 27, 2017, at 8:47 AM, Tomas Vondra <tomas.von...@2ndquadrant.com> > wrote: > > Hi, > > Attached is an updated version of the patch series, fixing the issues > reported by Mark Dilger: > > 1) Fix fabs() issue in histogram.c. > > 2) Do not

Re: WIP: BRIN multi-range indexes

> On Dec 19, 2017, at 5:16 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> > wrote: > > > > On 12/19/2017 08:38 PM, Mark Dilger wrote: >> >>> On Nov 18, 2017, at 12:45 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> >>> wrote: >>

Re: WIP: BRIN multi-range indexes

> On Dec 19, 2017, at 5:16 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> > wrote: > > > > On 12/19/2017 08:38 PM, Mark Dilger wrote: >> >>> On Nov 18, 2017, at 12:45 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> >>> wrote: >>

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Dec 19, 2017, at 4:31 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> > wrote: > > Hi, > > On 12/19/2017 08:17 PM, Mark Dilger wrote: >> >> I tested your latest patches on my mac os x laptop and got one test >> failure due to the

Re: Updated macOS start scripts

> On Nov 15, 2017, at 8:32 AM, Tom Lane wrote: > > The stuff in contrib/start-scripts/osx/ does not, as far as I know, > work at all on any recent release of macOS, because SystemStarter > is long gone. I propose replacing it with the attached, which > I've tested on

dsa_allocate could not find 4 free pages

Hackers, I'm getting the error in $subject and am only posting here because (a) the comments in src/backend/utils/mmgr/dsa.c circa line 720 suggest that this is a bug, and (b) the DSA code appears to be fairly new to the postgresql project, and perhaps not fully debugged. I am running against

Re: Speeding up pg_upgrade

> On Dec 8, 2017, at 9:21 AM, Stephen Frost <sfr...@snowman.net> wrote: > > Mark, > > * Mark Dilger (hornschnor...@gmail.com) wrote: >>> On Dec 7, 2017, at 10:24 PM, Bruce Momjian <br...@momjian.us> wrote: >>> I think the big problem with two-stage p

Re: dsa_allocate could not find 4 free pages

> On Dec 5, 2017, at 4:07 PM, Thomas Munro <thomas.mu...@enterprisedb.com> > wrote: > > On Wed, Dec 6, 2017 at 9:35 AM, Mark Dilger <hornschnor...@gmail.com> wrote: >>> On Dec 5, 2017, at 11:25 AM, Thomas Munro <thomas.mu...@enterprisedb.com> >>&g

Re: WIP: a way forward on bootstrap data

> On May 6, 2018, at 12:08 PM, John Naylor <jcnay...@gmail.com> wrote: > > On 5/7/18, Mark Dilger <hornschnor...@gmail.com> wrote: >> Hackers, >> >> Have you already considered and rejected the idea of having >> genbki.pl/Catalog.pm define constants

genbki.pl not quoting keywords in postgres.bki output

Hackers, There are not yet any examples in the postgres sources where this oversight causes problems, but in genbki.pl, where it makes the decision whether to quote a token: # Quote value if needed. We need not quote values that satisfy # the "id" pattern in bootscanner.l,

Re: Windows build broken starting at da9b580d89903fee871cf54845ffa2b26bda2e11

> On May 15, 2018, at 8:58 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> My best guess at the moment is: > >> diff --git a/src/backend/utils/init/globals.c >> b/src/backend/utils/init/globals.c >>

Windows build broken starting at da9b580d89903fee871cf54845ffa2b26bda2e11

Hackers, There was a bug report sent by Hao Lee about Windows build breakage, "BUG #15167: error C2365: 'errcode' : redefinition; previous definition" https://www.postgresql.org/message-id/152446498404.19807.4659286570762153837%40wrigleys.postgresql.org Heikki was the only person who responded

Re: Windows build broken starting at da9b580d89903fee871cf54845ffa2b26bda2e11

> On May 15, 2018, at 9:29 AM, Stephen Frost <sfr...@snowman.net> wrote: > > Greetings, > > * Mark Dilger (hornschnor...@gmail.com) wrote: >>> On May 15, 2018, at 8:58 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Mark Dilger <hornschnor...@gma

Re: Windows build broken starting at da9b580d89903fee871cf54845ffa2b26bda2e11

> On May 15, 2018, at 10:20 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >>>> If none of the animals >>>> are configured to detect this bug, perhaps the community needs another >>>> Windows an

Re: Windows build broken starting at da9b580d89903fee871cf54845ffa2b26bda2e11

> On May 15, 2018, at 9:54 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> I'm curious why the Windows build farm members did not pick this up. Or >> perhaps they did? (I don't get emails about that.) > > Th

Re: Auto-partitioning in PostgreSQL 10

> On Jun 25, 2018, at 3:00 AM, zafiirah jumeen wrote: > > Hello, > > I was trying to do auto partitioning in PostgreSQL 10. > First of all, I created 2 tables t_dossier_bac_history_insert_table and > t_dossier_bac_history_sensor_collections. > And then, I created a trigger which would

Re: Parallel Aggregates for string_agg and array_agg

> On May 1, 2018, at 2:11 PM, Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2018-05-01 14:09:39 -0700, Mark Dilger wrote: >> I don't care which order the data is in, as long as x[i] and y[i] are >> matched correctly. It sounds like t

Re: Parallel Aggregates for string_agg and array_agg

> On Mar 27, 2018, at 7:58 AM, Tom Lane wrote: > > David Rowley writes: >> On 27 March 2018 at 13:26, Alvaro Herrera wrote: >>> synchronized_seqscans is another piece of precedent in the area, FWIW. > >> This is true.

Re: A space-efficient, user-friendly way to store categorical data

> On Feb 12, 2018, at 5:08 PM, Andrew Kane wrote: > > Thanks everyone for the feedback. The current enum implementation requires > you to create a new type and add labels outside a transaction prior to an > insert. > > -- on table creation > CREATE TYPE city AS ENUM ();

Re: A space-efficient, user-friendly way to store categorical data

> On Feb 12, 2018, at 6:35 PM, Tom Lane wrote: > > Andrew Kane writes: >> Thanks everyone for the feedback. The current enum implementation requires >> you to create a new type and add labels outside a transaction prior to an >> insert. > > Right ...

Re: A space-efficient, user-friendly way to store categorical data

about why you would not just use the enumeration type that postgres already supplies. Mark Dilger

Re: WIP: BRIN multi-range indexes

> BTW while working on the regression tests, I've noticed that brin.sql > fails to test a couple of minmax opclasses (e.g. abstime/reltime). Is > that intentional or is that something we should fix eventually? I believe abstime/reltime are deprecated. Perhaps nobody wanted to bother adding test

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Feb 24, 2018, at 2:01 PM, Tomas Vondra > wrote: > Sadly, this patch series does not seem to move forward very much, and > I'm not sure how to change that :-/ I'll take a look at the new patch set this evening. I have been using your previous version of

Re: [HACKERS] Constifying numeric.c's local vars

no comments explaining it in the file, and the conversation in this thread never got into any details about it either. Mark Dilger

Re: [HACKERS] Constifying numeric.c's local vars

> This patch got committed as c1898c3e1e235ae35b4759d233253eff221b976a > on Sun Sep 10 16:20:41 2017 -0700, but I've only just gotten around to > reviewing it. > > I believe this is wrong and should be reverted, at least in part. > > The NumericVar struct has the field 'digits' as non-const: >

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Feb 24, 2018, at 2:01 PM, Tomas Vondra > wrote: > > Hi, > > Attached is an updated version of the patch, fixing some minor bitrot > and duplicate OIDs. The three patches apply cleanly, compile, and pass check-world. You might consider using PointerGetDatum

Re: Facility for detecting insecure object naming

> On Aug 8, 2018, at 7:47 AM, Tom Lane wrote: > > Isaac Morland writes: >> On 8 August 2018 at 09:58, Tom Lane wrote: >>> When the security team was discussing this issue before, we speculated >>> about ideas like inventing a function trust mechanism, so that attacks >>> based on search path

Re: Facility for detecting insecure object naming

> On Aug 15, 2018, at 9:02 AM, Robert Haas wrote: > > On Tue, Aug 14, 2018 at 5:14 PM, Mark Dilger wrote: >> I think you are interpreting the problem too broadly. This is basically >> just a privilege escalation attack vector. > > Hmm. Well, I think you're i

Re: Undocumented(?) limits on regexp functions

> On Aug 14, 2018, at 10:01 AM, Tels wrote: > > Moin Andrew, > > On Tue, August 14, 2018 9:16 am, Andrew Gierth wrote: >>> "Tom" == Tom Lane writes: >> Should these limits: >> a) be removed >> >> Tom> Doubt it --- we could use the "huge" request variants, maybe, but >> Tom>

Re: Facility for detecting insecure object naming

> On Aug 14, 2018, at 8:00 AM, Robert Haas wrote: > > On Wed, Aug 8, 2018 at 1:58 PM, Tom Lane wrote: >> I'm not sold on #2 either. That path leads to, for example, >> s/=/OPERATOR(pg_catalog.=)/g everywhere, which is utterly catastrophic >> to both readability and portability of your SQL

Re: Facility for detecting insecure object naming

> On Aug 15, 2018, at 9:27 PM, Tom Lane wrote: > > Mark Dilger writes: >> Go ahead and define some new lexical scope mechanism. I'm probably >> going to move into the 21st century with you and use it. (I mostly >> use "my", not "local&q

Re: Use C99 designated initializers for some structs

> On Aug 29, 2018, at 1:51 PM, David Steele wrote: > > On 8/29/18 5:14 AM, Peter Eisentraut wrote: >> On 29/08/2018 12:13, Peter Eisentraut wrote: >>> Here is a patch to change some struct initializations to use C99-style >>> designated initializers. These are just a few particularly

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Mar 3, 2018, at 2:40 PM, Tomas Vondra wrote: > > An updated patch version, fixing the breakage caused by fd1a421fe6 > twiddling with pg_proc. Hi Tomas! Reviewing the sgml documentation, I think something like the following should be added: diff --git

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Mar 3, 2018, at 2:40 PM, Tomas Vondra wrote: > > An updated patch version, fixing the breakage caused by fd1a421fe6 > twiddling with pg_proc. Hi Tomas, thanks again for this most useful patch! Perhaps this is intentional, but there seems to be a place in

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

> On Apr 9, 2018, at 10:26 AM, Joshua D. Drake wrote: > We have plenty of YEARS of people not noticing this issue I disagree. I have noticed this problem, but blamed it on other things. For over five years now, I have had to tell customers not to use thin provisioning,

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

> On Apr 9, 2018, at 12:13 PM, Andres Freund wrote: > > Hi, > > On 2018-04-09 15:02:11 -0400, Robert Haas wrote: >> I think the simplest technological solution to this problem is to >> rewrite the entire backend and all supporting processes to use >> O_DIRECT everywhere.

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

> On Apr 9, 2018, at 1:43 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > > > > On 04/09/2018 10:25 PM, Mark Dilger wrote: >> >>> On Apr 9, 2018, at 12:13 PM, Andres Freund <and...@anarazel.de> wrote: >>> >>> Hi, >>&g

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

> On Apr 9, 2018, at 2:25 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > > > > On 04/09/2018 11:08 PM, Andres Freund wrote: >> Hi, >> >> On 2018-04-09 13:55:29 -0700, Mark Dilger wrote: >>> I can also imagine a master and standby

Re: WIP: a way forward on bootstrap data

> On Apr 25, 2018, at 1:00 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, Apr 25, 2018 at 3:44 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >> There still seems to be a lot of boilerplate in the .dat files >> that could be eliminated. T

Re: WIP: a way forward on bootstrap data

> On Apr 25, 2018, at 1:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Apr 25, 2018 at 3:44 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >>> There still seems to be a lot of boilerplate in t

Re: WIP: a way forward on bootstrap data

>> + textprosrc BKI_DEFAULT("${proname}") BKI_FORCE_NOT_NULL; >> >>> That one I kinda like. >> >> Agreed, this seems more compelling. However, I think we need more than >> one compelling example to justify the additional infrastructure. > > I'll look for more.

Re: [HACKERS] [PATCH] kNN for SP-GiST

> On Sep 18, 2018, at 3:58 PM, Alexander Korotkov > wrote: > > On Mon, Sep 17, 2018 at 12:42 PM Andrey Borodin wrote: >>> 17 сент. 2018 г., в 2:03, Alexander Korotkov >>> написал(а): >>> >>> Also, it appears to me that it's OK to be a single patch >> >> +1, ISTM that these 6 patches

Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel

> On Oct 9, 2018, at 12:22 PM, Andres Freund wrote: > > In-Reply-To: <20180928223240.kgwc4czzzekrp...@alap3.anarazel.de> > > Hi, > > As discussed below (at [1]), I think we should remove $subject. I plan > to do so, unless somebody protests soon-ish. I thought it'd be better > to call

Re: FETCH FIRST clause PERCENT option

> On Aug 16, 2018, at 7:34 AM, Andres Freund wrote: > > Hi, > > On 2018-08-16 17:27:45 +0300, Surafel Temesgen wrote: >> FETCH FIRST with PERCENT option is SQL standard that state limit count to >> be specified in a percentage in addition to specify it in exact count and >> listed as one of

Re: FETCH FIRST clause PERCENT option

> On Sep 20, 2018, at 5:29 PM, Andres Freund wrote: > > Hi, > > On 2018-09-20 17:06:36 -0700, Mark Dilger wrote: >> I should think that spilling anything to a tuplestore would only be needed >> if the query contains an ORDER BY expression. If you query >>

Re: FETCH FIRST clause PERCENT option

> On Sep 25, 2018, at 5:07 AM, Surafel Temesgen wrote: > > hey > > On 9/21/18, Mark Dilger wrote: > >> Surafel, there are no regression tests that I can see in your patch. It >> would help if you added some, as then I could precisely what behavior you

Re: FETCH FIRST clause PERCENT option

> On Sep 25, 2018, at 8:08 AM, Mark Dilger wrote: > > > >> On Sep 25, 2018, at 5:07 AM, Surafel Temesgen wrote: >> >> hey >> >> On 9/21/18, Mark Dilger wrote: >> >>> Surafel, there are no regression tests that I can see in yo

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: not tested Spec compliant: not tested Documentation:not tested Patch applies cleanly on master

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested Sorry about the prior review; I neglected to select all the appropriate

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote: > > David Rowley writes: >> As far as I can see the patch is ready to go, but I'll defer to Mark, >> who's also listed on the reviewer list for this patch. > > Mark, are you planning to do further review on this patch? > I'd like to move it

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote: > > David Rowley writes: >> As far as I can see the patch is ready to go, but I'll defer to Mark, >> who's also listed on the reviewer list for this patch. > > Mark, are you planning to do further review on this patch? > I'd like to move it

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

> On Jan 27, 2019, at 12:04 PM, Mark Dilger wrote: > > > >> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote: >> >> David Rowley writes: >>> As far as I can see the patch is ready to go, but I'll defer to Mark, >>> who's also listed on the re

Re: more unconstify use

> On Feb 7, 2019, at 12:14 AM, Peter Eisentraut > wrote: > > Here is a patch that makes more use of unconstify() by replacing casts > whose only purpose is to cast away const. Also a preliminary patch to > remove casts that were useless to begin with. > > -- > Peter Eisentraut

Is it safe to ignore the return value of SPI_finish and SPI_execute?

Hackers, most places that use SPI_connect ... SPI_finish check the return value of SPI_finish and elog if it failed. There are a few places that do not, and it is unclear to me why this is safe. SPI_finish appears to be needed to clean up memory contexts. Examples can be found in:

Re: pgindent run next week?

> On May 17, 2019, at 12:10 PM, Tom Lane wrote: > > Andres Freund writes: >> On 2019-05-17 13:47:02 -0400, Tom Lane wrote: >>> I dunno, how far back are you thinking? I've occasionally wished we >>> could reindent all the back branches to match HEAD, but realistically, >>> people carrying

Nitpick about assumptions in indexam and tableam

Hackers, The return value of RegisterSnapshot is being ignored in a few places in indexam.c and tableam.c, suggesting an intimate knowledge of the inner workings of the snapshot manager from these two files. I don't think that is particularly wise, and I don't see a performance justification for

nitpick about poor style in MergeAttributes

Hackers, I have been auditing the v12 source code for places which inappropriately ignore the return value of a function and have found another example which seems to me a fertile source of future bugs. In src/backend/nodes/list.c, list_delete_cell frees the list and returns NIL when you delete

nitpick about useless floating point division in gimme_edge_table

Hackers, The return value of gimme_edge_table is not used anywhere in the core code, so far as I can see. But the value is computed as /* return average number of edges per index */ return ((float) (edge_total * 2) / (float) num_gene); which involves some floating point math. I'm not sure

Re: Is it safe to ignore the return value of SPI_finish and SPI_execute?

On Fri, May 17, 2019 at 6:12 PM Tom Lane wrote: > > Mark Dilger writes: > > most places that use SPI_connect ... SPI_finish check the > > return value of SPI_finish and elog if it failed. There > > are a few places that do not, and it is unclear to me > > why thi

Re: pgindent run next week?

On Wed, May 22, 2019 at 10:07 AM Tom Lane wrote: > > I wrote: > > Hearing no objections, I'll plan on running pgindent tomorrow sometime. > > And done. > > > The new underlying pg_bsd_indent (2.1) is available now from > > https://git.postgresql.org/git/pg_bsd_indent.git > > Please update your

Re: Is it safe to ignore the return value of SPI_finish and SPI_execute?

On Wed, May 22, 2019 at 1:52 PM Tom Lane wrote: > > Mark Dilger writes: > > On Fri, May 17, 2019 at 6:12 PM Tom Lane wrote: > >> One reasonable solution would be to change the callers that got this > >> wrong. Another one would be to reconsider whether the err

Memory bug in dsnowball_lexize

Hackers, In src/backend/snowball/libstemmer/utilities.c, 'create_s' uses malloc (not palloc) to allocate memory, and on memory exhaustion returns NULL rather than throwing an exception. In this same file, 'replace_s' calls 'create_s' and if it gets back NULL, returns the error code -1.

Re: nitpick about poor style in MergeAttributes

On Thu, May 23, 2019 at 7:54 AM Tom Lane wrote: > > Michael Paquier writes: > > On Wed, May 22, 2019 at 06:20:01PM -0700, Mark Dilger wrote: > >> What to do about this is harder to say. In the following > >> patch, I'm just doing what I think is standard for ca

Re: nitpick about poor style in MergeAttributes

On Wed, May 22, 2019 at 10:21 PM Michael Paquier wrote: > > On Wed, May 22, 2019 at 06:20:01PM -0700, Mark Dilger wrote: > > What to do about this is harder to say. In the following > > patch, I'm just doing what I think is standard for callers > > of list_delete_cell,

Re: Memory bug in dsnowball_lexize

On Thu, May 23, 2019 at 8:46 AM Tom Lane wrote: > > Mark Dilger writes: > > In src/backend/snowball/libstemmer/utilities.c, 'create_s' uses > > malloc (not palloc) to allocate memory, and on memory exhaustion > > returns NULL rather than throwing an exception. > > A

Re: fsync failure in durable_unlink ignored in xlog.c?

On Thu, May 23, 2019 at 11:07 AM Tom Lane wrote: > > Andres Freund writes: > > On 2019-05-23 10:46:02 -0700, Mark Dilger wrote: > >> Is this code safe against fsync failures? If so, can I get an explanation > >> that I might put into a code comment patch? > >

ClosePipeStream failure ignored in pg_import_system_collations

Hackers, I only see three invocations of ClosePipeStream in the sources. In two of them, the return value is checked and an error is raised if it failed. In the third, the error (if any) is squashed. I don't know if a pipe stream over "locale -a" could ever fail to close, but it seems sensible

fsync failure in durable_unlink ignored in xlog.c?

Hackers, I have seen other lengthy discussions about fsync semantics, and if this question is being addressed there, this question might not be relevant. Two calls to durable_unlink at log level DEBUG1 are ignoring the return value. Other calls at ERROR and FATAL are likewise ignoring the

Question about BarrierAttach spinlock

Hackers, In src/backend/storage/ipc/barrier.c, BarrierAttach goes to the bother of storing the phase before releasing the spinlock, and then returns the phase. In nodeHash.c, ExecHashTableCreate ignores the phase returned by BarrierAttach, and then immediately calls BarrierPhase to get the phase

Re: ClosePipeStream failure ignored in pg_import_system_collations

On Thu, May 23, 2019 at 3:23 PM Tom Lane wrote: > > Mark Dilger writes: > > I only see three invocations of ClosePipeStream in the sources. > > In two of them, the return value is checked and an error is raised > > if it failed. In the third, the error (if any) is squa

Re: Question about BarrierAttach spinlock

On Thu, May 23, 2019 at 3:44 PM Thomas Munro wrote: > > On Fri, May 24, 2019 at 4:10 AM Mark Dilger wrote: > > In src/backend/storage/ipc/barrier.c, BarrierAttach > > goes to the bother of storing the phase before > > releasing the spinlock, and then returns the phas

Re: nitpick about poor style in MergeAttributes

On Thu, May 23, 2019 at 5:24 PM Michael Paquier wrote: > > On Thu, May 23, 2019 at 08:27:19AM -0700, Mark Dilger wrote: > > On Thu, May 23, 2019 at 7:54 AM Tom Lane wrote: > >> Are we sure that's not just a newly-introduced bug, ie it has not > >> been tested

Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays

On 10/2/19 8:46 AM, Tom Lane wrote: Joe Nelson writes: Isaac Morland wrote: I hope you'll forgive a noob question. Why does the "After" initialization for the boolean array have {0} rather than {false}? I think using a value other than {0} potentially gives the incorrect impression that

Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays

On 10/2/19 11:02 AM, Tom Lane wrote: Mark Dilger writes: On 10/2/19 8:46 AM, Tom Lane wrote: Right. I think that in general it's bad practice for an initializer to not specify all fields/elements of the target. There are numerous locations in the code that raise warnings when -Wmissing

Re: TestLib::command_fails_like enhancement

On 11/8/19 6:33 AM, Andrew Dunstan wrote: On 11/8/19 1:16 AM, Craig Ringer wrote: On Fri, 8 Nov 2019 at 06:28, Mark Dilger mailto:hornschnor...@gmail.com>> wrote: On 10/31/19 10:02 AM, Andrew Dunstan wrote: > > This small patch authored by my colleague

Checking return value of SPI_execute

Hackers, please find attached a patch fixing a problem previously discussed [1] about the code inappropriately ignoring the return value from SPI_execute. I will be adding this to https://commitfest.postgresql.org/26/ shortly. Mark Dilger [1] https://www.postgresql.org/message-id

Re: TestLib::command_fails_like enhancement

or: too many command-line arguments (first is "abc")\E/, 'pg_dump: too many command-line arguments'); but adding more to that cruft just makes it worse. Right? -- Mark Dilger

Re: Patch avoid call strlen repeatedly in loop.

t compared to how long send() takes? A bit more information about the performance problem you are encountering might make it easier to understand the motivation for this patch. -- Mark Dilger

Re: TestLib::command_fails_like enhancement

abstracted into something, perhaps TestLib::run, and then used everywhere that IPC::Run::run currently is used. -- Mark Dilger

Re: Using multiple extended statistics for estimates

ut? If so, can you provide a test example that works differently under your patch? Thanks! -- Mark Dilger diff --git a/src/test/regress/expected/stats_ext.out b/src/test/regress/expected/stats_ext.out index b65228fa07..8e20df25fc 100644 --- a/src/test/regress/expected/stats_ext.out +++ b/src/te

  1   2   3   4   5   6   7   8   9   10   >