Re: [HACKERS] patch: function xmltable

2017-01-24 21:38 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > > * SELECT (xmltable(..)).* + regress tests > > * compilation and regress tests without --with-libxml > > Thanks. I just realized that this is doing more work than necessary -- > ?? I don't

Re: [HACKERS] pgbench more operators & functions

Hello Tom, I concur that this is expanding pgbench's expression language well beyond what anybody has shown a need for. As for the motivation, I'm assuming that pgbench should provide features

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Hi Alvaro, Am 24.01.2017 um 19:36 schrieb Alvaro Herrera: Tobias Oberstein wrote: I am benchmarking IOPS, and while doing so, it becomes apparent that at these scales it does matter _how_ IO is done. The most efficient way is libaio. I get 9.7 million/sec IOPS with low CPU load. Using any

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Hi Andres, Using pread instead of lseek+read halfes the syscalls. I really don't understand what you are fighting here .. Sure, there's some overhead. And as I said upthread, I'm much less against this change than Tom. What I'm saying is that your benchmarks haven't shown a benefit in a

Re: [HACKERS] pgbench more operators & functions

As it stands right now you haven't provided enough context for this patch and only the social difficulty of actually marking a patch rejected has prevented its demise in its current form - because while it has interesting ideas its added maintenance burden for -core without any in-core usage.

Re: [HACKERS] PATCH: recursive json_populate_record()

Nikita Glukhov writes: > On 25.01.2017 23:58, Tom Lane wrote: >> I think you need to take a second look at the code you're producing >> and realize that it's not so clean either. This extract from >> populate_record_field, for example, is pretty horrid: > But what if we

Re: [HACKERS] patch: function xmltable

2017-01-25 23:33 GMT+01:00 Andres Freund : > On 2017-01-25 22:51:37 +0100, Pavel Stehule wrote: > > 2017-01-25 22:40 GMT+01:00 Andres Freund : > > > > I afraid when I cannot to reuse a SRF infrastructure, I have to > > > reimplement > > > > it partially :(

Re: [HACKERS] Checksums by default?

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 2:23 PM, Stephen Frost wrote: > > Yet, our default is to have them disabled and *really* hard to enable. > > First of all, that could be fixed by further development. I'm certainly all for doing

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

Ashutosh Bapat writes: > On Wed, Jan 25, 2017 at 10:54 AM, Michael Paquier > wrote: >> On Wed, Jan 25, 2017 at 12:46 AM, Tom Lane wrote: >>> Here's an updated patch with doc changes. Aside from that one, >>> I

Re: [HACKERS] Speedup twophase transactions

> We are talking about the recovery/promote code path. Specifically this > call to KnownPreparedRecreateFiles() in PrescanPreparedTransactions(). > > We write the files to disk and they get immediately read up in the > following code. We could not write the files to disk and read >

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

On 2016/11/30 17:29, Etsuro Fujita wrote: On 2016/11/23 20:28, Rushabh Lathia wrote: I wrote: How about inserting that before the out param **retrieved_attrs, like this? static void deparseExplicitTargetList(List *tlist, bool is_returning,

Re: [HACKERS] pgbench more operators & functions

Bonjour Michaël, Hello Robert, Let's mark this Returned with Feedback and move on. We've only got a week left in the CommitFest anyhow and there are lots of other things that still need work (and which actually have been revised to match previous feedback). Done as such, let's move on.

Re: [HACKERS] Substantial bloat in postgres_fdw regression test runtime

Ashutosh Bapat writes: > On Thu, Nov 3, 2016 at 1:58 PM, Jeevan Chalke > wrote: >> Attached patch with test-case modification. > I verified that this patch indeed bring the time down to 2 to 3 > seconds from 10 seconds. Thanks

Re: [HACKERS] pgbench more operators & functions

Hello Tom, I concur that this is expanding pgbench's expression language well beyond what anybody has shown a need for. As for the motivation, I'm assuming that pgbench should provide features necessary to implement benchmarks, so I'm adding operators that appear in standard benchmark

Re: [HACKERS] PostgreSQL 8.2 installation error on Windows 2016 server

Hi Aaron, Thank you so much for the information. Regards, Shruti Rawal -Original Message- From: Aaron W. Swenson [mailto:titanof...@gentoo.org] Sent: Tuesday, January 24, 2017 8:22 PM To: Shruti Rawal Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] PostgreSQL 8.2 installation

Re: [HACKERS] sequence data type

Here is an updated patch that allows changing the sequence type. This was clearly a concern for reviewers, and the presented use cases seemed convincing. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From

Re: [HACKERS] patch: function xmltable

Tom Lane wrote: > Andres Freund writes: > > On 2017-01-24 21:32:56 -0300, Alvaro Herrera wrote: > >> XMLTABLE is specified by the standard to return multiple rows ... but > >> then as far as my reading goes, it is only supposed to be supported in > >> the range table (FROM

Re: [HACKERS] COPY as a set returning function

On Mon, Oct 31, 2016 at 04:45:40PM -0400, Corey Huinker wrote: > Attached is a patch that implements copy_srf(). > > The function signature reflects cstate more than it reflects the COPY > options (filename+is_program instead of FILENAME or PROGRAM, etc) The patch as it stands needs a rebase.

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

I am responding both of your emails together. > Perhaps I don't understand it. Many opclass are defined for > btree. But since (ordinary) btree handles only one-dimentional, > totally-orderable sets, geometric types even point don't fit > it. Even if we relaxed it by removing EPSILON,

Re: [HACKERS] multivariate statistics (v19)

Michael Paquier wrote: > On Wed, Jan 4, 2017 at 11:35 AM, Tomas Vondra > wrote: > > Attached is v22 of the patch series, rebased to current master and fixing > > the reported bug. I haven't made any other changes - the issues reported by > > Petr are mostly minor,

Re: [HACKERS] Radix tree for character conversion

HI, I patched 4 patchset and run "make", but I got failed. Is this a bug or my mistake ? I'm sorry if I'm wrong. [$(TOP)]$ patch -p1 < ../0001-Add-missing-semicolon.patch [$(TOP)]$ patch -p1 < ../0002-Correct-reference-resolution-syntax.patch [$(TOP)]$ patch -p1 <

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Mon, Jan 23, 2017 at 6:37 PM, Jim Nasby wrote: > I'm not sure the default GUC setting of 0 makes sense. If you've loaded the > module, presumably you want it to be running. I think it'd be nice if the GUC > had a -1 setting that meant to use checkpoint_timeout.

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

On Wed, Jan 25, 2017 at 6:43 PM, Vitaly Burovoy wrote: > On 1/23/17, Haribabu Kommi wrote: > > The patch is split into two parts. > > 1. Macaddr8 datatype support > > 2. Contrib module support. > > Hello, > > I'm sorry for the delay. > The

Re: [HACKERS] simplify sequence test

On 25/01/17 03:48, Peter Eisentraut wrote: > We maintain a separate test output file sequence_1.out because the > log_cnt value can vary if there is a checkpoint happening at the right > time. So we have to maintain two files because of a one character > difference. I propose the attached patch

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

On Wed, Jan 25, 2017 at 10:54 AM, Michael Paquier wrote: > On Wed, Jan 25, 2017 at 12:46 AM, Tom Lane wrote: >> I wrote: >>> Michael Paquier writes: The table of Pseudo-Types needs to be updated as well with unknown

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Tue, Jan 24, 2017 at 5:07 AM, Jim Nasby wrote: > I took a look at this again, and it doesn't appear to be working for me. The > library is being loaded during startup, but I don't see any further activity > in the log, and I don't see an autoprewarm file in $PGDATA.

Re: [HACKERS] Improvements in psql hooks for variables

Hello, The patch works fine on applying on latest master branch and testing it for various variables as listed in PsqlSettings struct. I will post further comments on patch soon. Thank you, Rahila Syed On Wed, Jan 25, 2017 at 1:33 AM, Tom Lane wrote: > "Daniel Verite"

Re: [HACKERS] Substantial bloat in postgres_fdw regression test runtime

On Thu, Nov 3, 2016 at 1:58 PM, Jeevan Chalke wrote: > > On Wed, Nov 2, 2016 at 10:09 PM, Tom Lane wrote: >> >> In 9.6, "make installcheck" in contrib/postgres_fdw takes a shade >> under 3 seconds on my machine. In HEAD, it's taking 10

Re: [HACKERS] COPY as a set returning function

On Wed, Jan 25, 2017 at 02:37:57PM +0900, Michael Paquier wrote: > On Mon, Dec 5, 2016 at 2:10 PM, Haribabu Kommi > wrote: > > On Tue, Nov 1, 2016 at 7:45 AM, Corey Huinker > > wrote: > >> > >> Attached is a patch that implements copy_srf(). >

[HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Commit 1574783b4ced0356fbc626af1a1a469faa6b41e1 gratifyingly removed hard-coded superuser checks from assorted functions, which makes it possible to GRANT EXECUTE ON FUNCTION pg_catalog.whatever() to unprivileged users if the DBA so desires. However, the functions in genfile.c still have

Re: [HACKERS] Performance improvement for joins where outer side is unique

David Rowley wrote: > On 19 January 2017 at 11:06, David Rowley > wrote: > > Old patch no longer applies, so I've attached a rebased patch. This > > also re-adds a comment line which I mistakenly removed. > > (meanwhile Andres commits

Re: [HACKERS] COPY as a set returning function

On Wed, Jan 25, 2017 at 06:16:16AM -0800, David Fetter wrote: > On Mon, Oct 31, 2016 at 04:45:40PM -0400, Corey Huinker wrote: > > Attached is a patch that implements copy_srf(). > > > > The function signature reflects cstate more than it reflects the COPY > > options (filename+is_program instead

Re: [HACKERS] PoC: Grouped base relation

David Rowley wrote: > On 20 January 2017 at 00:22, Antonin Houska wrote: > > Sorry, it was my thinko - I somehow confused David's CROSS JOIN example with > > this one. If one side of the join clause is unique and the other becomes > > unique due

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Reading 0001_track_root_lp_v9.patch again: > +/* > + * We use the same HEAP_LATEST_TUPLE flag to check if the tuple's t_ctid > field > + * contains the root line pointer. We can't use the same > + * HeapTupleHeaderIsHeapLatest macro because that also checks for > TID-equality > + * to decide

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

I tend to agree. But in the past when this came up people pointed out you could equally do things this way and still grant all the access you wanted using SECURITY DEFINER. Arguably that's a better approach because then instead of auditing the entire monitor script you only need to audit this one

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Wed, Jan 25, 2017 at 11:30 AM, Greg Stark wrote: > I tend to agree. But in the past when this came up people pointed out > you could equally do things this way and still grant all the access > you wanted using SECURITY DEFINER. Arguably that's a better approach > because then

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Tue, Jan 24, 2017 at 1:49 AM, Claudio Freire wrote: > On Fri, Jan 20, 2017 at 6:24 AM, Masahiko Sawada > wrote: >> On Thu, Jan 19, 2017 at 8:31 PM, Claudio Freire >> wrote: >>> On Thu, Jan 19, 2017 at 6:33 AM, Anastasia

Re: [HACKERS] COPY as a set returning function

David Fetter wrote: > @@ -562,7 +563,6 @@ CopyGetData(CopyState cstate, void *databuf, int minread, > int maxread) >errmsg("could not read from > COPY file: %m"))); > break; > case COPY_OLD_FE: > - >

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

On Wed, Jan 25, 2017 at 2:49 PM, Tom Lane wrote: > I looked at the 0002 patch, and while the code is probably OK, I am > dissatisfied with this API spec: > > + * If copy is TRUE, the slot receives a copied tuple that will stay valid > + * regardless of future manipulations of

Re: [HACKERS] safer node casting

Hi Peter, On 2016-12-31 12:08:22 -0500, Peter Eisentraut wrote: > RestrictInfo *rinfo = castNode(RestrictInfo, lfirst(lc)); Are you planning to add this / update this patch? Because I really would have liked this a number of times already... I can update it according to my suggestions (to

Re: [HACKERS] Checksums by default?

On Thu, Jan 26, 2017 at 9:14 AM, Peter Geoghegan wrote: > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: >> As it is, there are backup solutions which *do* check the checksum when >> backing up PG. This is no longer, thankfully, some hypothetical

Re: [HACKERS] safer node casting

Andres Freund writes: > On 2016-12-31 12:08:22 -0500, Peter Eisentraut wrote: >> RestrictInfo *rinfo = castNode(RestrictInfo, lfirst(lc)); > Are you planning to add this / update this patch? Because I really would > have liked this a number of times already... I can update

Re: [HACKERS] Checksums by default?

On 2017-01-26 09:19:28 +0900, Michael Paquier wrote: > On Thu, Jan 26, 2017 at 9:14 AM, Peter Geoghegan wrote: > > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: > >> As it is, there are backup solutions which *do* check the checksum when > >> backing

Re: [HACKERS] Checksums by default?

On Thu, Jan 26, 2017 at 9:22 AM, Andres Freund wrote: > On 2017-01-26 09:19:28 +0900, Michael Paquier wrote: >> On Thu, Jan 26, 2017 at 9:14 AM, Peter Geoghegan wrote: >> > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: >> >> As it

Re: [HACKERS] Checksums by default?

On Wed, Jan 25, 2017 at 7:19 PM, Michael Paquier wrote: > On Thu, Jan 26, 2017 at 9:14 AM, Peter Geoghegan wrote: >> On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: >>> As it is, there are backup solutions which *do* check

Re: [HACKERS] Checksums by default?

On 2017-01-25 19:30:08 -0500, Stephen Frost wrote: > * Peter Geoghegan (p...@heroku.com) wrote: > > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: > > > As it is, there are backup solutions which *do* check the checksum when > > > backing up PG. This is no longer,

Re: [HACKERS] Checksums by default?

* Andres Freund (and...@anarazel.de) wrote: > On 2017-01-25 19:30:08 -0500, Stephen Frost wrote: > > * Peter Geoghegan (p...@heroku.com) wrote: > > > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: > > > > As it is, there are backup solutions which *do* check the

Re: [HACKERS] Checksums by default?

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > That would be enough. It should also be rare enough that there would > not be that many pages to track when looking at records from the > backup start position to minimum recovery point. It could be also > simpler, though more

Re: [HACKERS] patch: function xmltable

2017-01-25 15:07 GMT+01:00 Alvaro Herrera : > Tom Lane wrote: > > Andres Freund writes: > > > On 2017-01-24 21:32:56 -0300, Alvaro Herrera wrote: > > >> XMLTABLE is specified by the standard to return multiple rows ... but > > >> then as far as my

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 3:17 PM, Stephen Frost wrote: > > Your email is 'pg_ls_dir & friends', which I took to imply at *least* > > pg_read_file() and pg_read_binary_file(), and it's not unreasonable to > > think you may

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-01-25 16:52:38 -0500, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > > > Preventing people from calling functions by denying the ability to > > > meaningfully GRANT EXECUTE on those functions doesn't actually

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

Peter Geoghegan writes: > I should have already specifically pointed out that the original > discussion on what became 0002-* is here: > postgr.es/m/7256.1476711...@sss.pgh.pa.us > As I said already, the general idea seems uncontroversial. I looked at the 0002 patch, and while

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

[ in the service of closing out this thread... ] Peter Geoghegan writes: > Finally, 0003-* is a Valgrind suppression borrowed from my parallel > CREATE INDEX patch. It's self-explanatory. Um, I didn't find it all that self-explanatory. Why wouldn't we want to avoid writing

Re: [HACKERS] Checksums by default?

On Wed, Jan 25, 2017 at 6:30 PM, Stephen Frost wrote: > I hope to discuss it further after we have the ability to turn it off > easily. I think we should have the ability to flip it in BOTH directions easily. >> Second, really hard to enable is a relative term. I accept

Re: [HACKERS] Checksums by default?

* Peter Geoghegan (p...@heroku.com) wrote: > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: > > As it is, there are backup solutions which *do* check the checksum when > > backing up PG. This is no longer, thankfully, some hypothetical thing, > > but something which

Re: [HACKERS] Checksums by default?

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Thu, Jan 26, 2017 at 9:14 AM, Peter Geoghegan wrote: > > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: > >> As it is, there are backup solutions which *do* check the checksum when > >> backing

Re: [HACKERS] Checksums by default?

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 7:19 PM, Michael Paquier > wrote: > > On Thu, Jan 26, 2017 at 9:14 AM, Peter Geoghegan wrote: > >> On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: > >>>

Re: [HACKERS] Checksums by default?

On Thu, Jan 26, 2017 at 9:32 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Wed, Jan 25, 2017 at 7:19 PM, Michael Paquier >> wrote: >> > On Thu, Jan 26, 2017 at 9:14 AM, Peter Geoghegan wrote: >> >>

Re: [HACKERS] pdf versus single-html

On 1/21/17 6:29 AM, Erik Rijkers wrote: > It might even be good to include such a single-file html in the Makefile > as an option. > > I'll give it a try but has anyone done this work already, perhaps? Already exists: doc/src/sgml$ make postgres.html -- Peter Eisentraut

Re: [HACKERS] COPY as a set returning function

On Wed, Jan 25, 2017 at 12:23:23PM -0500, Corey Huinker wrote: > > Feel free to mark it returned as feedback. The concept didn't > generate as much enthusiasm as I had hoped, so I think the right > thing to do now is scale it back to a patch that makes > CopyFromRawFields() externally visible so

Re: [HACKERS] Logical Replication WIP

On 1/22/17 8:11 PM, Petr Jelinek wrote: > 0001 - Changes the libpqrcv_connect to use async libpq api so that it > won't get stuck forever in case of connect is stuck. This is preexisting > bug that also affects walreceiver but it's less visible there as there > is no SQL interface to initiate

Re: [HACKERS] logical-replication.sgml improvements

On 1/20/17 11:00 AM, Erik Rijkers wrote: > logical-replication.sgml.diff changes Committed, thanks! -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Checksums by default?

On Wed, Jan 25, 2017 at 12:02 AM, Jim Nasby wrote: > I'm not completely grokking your second paragraph, but I would think that an > average user would love got get a heads-up that their hardware is failing. Sure. If the database runs fast enough with checksums enabled,

Re: [HACKERS] Logical Replication WIP

On 1/23/17 11:19 AM, Fujii Masao wrote: > The copyright in each file that the commit of logical rep added needs to > be updated. I have fixed that. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

[HACKERS] [FEATURE PATCH] pg_stat_statements with plans

Hello psql-hackers! TL:DR; We extended the functionality of pg_stat_statements so it can track worst and best case execution plans. Based on a suggestion of my colleague Arne Scheffer, Marius Timmer and I extended pg_stat_statements so it can also record execution plans, whenever the

Re: [HACKERS] Checksums by default?

On Sat, Jan 21, 2017 at 11:57 AM, Andres Freund wrote: > On 2017-01-21 11:39:18 +0100, Magnus Hagander wrote: >> Is it time to enable checksums by default, and give initdb a switch to turn >> it off instead? > > -1 - the WAL overhead is quite massive, and in contrast to the

Re: [HACKERS] Declarative partitioning vs. information_schema

On Wed, Jan 25, 2017 at 1:04 PM, Peter Eisentraut wrote: > On 1/18/17 2:32 PM, Robert Haas wrote: >> Unless we can find something official, I suppose we should just >> display BASE TABLE in that case as we do in other cases. I wonder if >> the schema needs some

Re: [HACKERS] COPY as a set returning function

On Wed, Jan 25, 2017 at 11:57 AM, Alvaro Herrera wrote: > David Fetter wrote: > > > @@ -562,7 +563,6 @@ CopyGetData(CopyState cstate, void *databuf, int > minread, int maxread) > >errmsg("could not read > from COPY file:

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans

On 25 January 2017 at 17:34, Julian Markwort wrote: > Analogous to this, a bad_plan is saved, when the time has been exceeded by a > factor greater than 1.1 . ...and the plan differs? Probably best to use some stat math to calculate deviation, rather than fixed

Re: [HACKERS] Declarative partitioning vs. information_schema

On 1/18/17 2:32 PM, Robert Haas wrote: > Unless we can find something official, I suppose we should just > display BASE TABLE in that case as we do in other cases. I wonder if > the schema needs some broader revision; for example, are there > information_schema elements intended to show

Re: [HACKERS] COPY as a set returning function

On Wed, Jan 25, 2017 at 1:10 PM, David Fetter wrote: > On Wed, Jan 25, 2017 at 12:23:23PM -0500, Corey Huinker wrote: > > > > Feel free to mark it returned as feedback. The concept didn't > > generate as much enthusiasm as I had hoped, so I think the right > > thing to do now

Re: [HACKERS] patch: function xmltable

2017-01-25 22:40 GMT+01:00 Andres Freund : > Hi, > > > > > I'll try to explain my motivation. Please, check it and correct me > if I > > > am > > > > wrong. I don't keep on my implementation - just try to implement > XMLTABLE > > > > be consistent with another behave and be

Re: [HACKERS] patch: function xmltable

On 2017-01-25 22:51:37 +0100, Pavel Stehule wrote: > 2017-01-25 22:40 GMT+01:00 Andres Freund : > > > I afraid when I cannot to reuse a SRF infrastructure, I have to > > reimplement > > > it partially :( - mainly for usage in "ROWS FROM ()" > > > > The TableExpr implementation

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Hi, On 2017-01-25 16:52:38 -0500, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: > > Preventing people from calling functions by denying the ability to > > meaningfully GRANT EXECUTE on those functions doesn't actually stop > > them from delegating those functions to

Re: [HACKERS] Checksums by default?

On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost wrote: > As it is, there are backup solutions which *do* check the checksum when > backing up PG. This is no longer, thankfully, some hypothetical thing, > but something which really exists and will hopefully keep users from >

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

(Adding Robert in CC.) On Thu, Jan 26, 2017 at 4:34 AM, Wang Hao wrote: > An unlogged table has an initialization fork. The initialization fork does > not have an BM_PERMANENT flag when get a buffer. > In checkpoint (not shutdown or end of recovery), it will not write to disk.

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On 2017-01-25 18:04:09 -0500, Stephen Frost wrote: > Andres, > > * Andres Freund (and...@anarazel.de) wrote: > > On 2017-01-25 16:52:38 -0500, Stephen Frost wrote: > > > * Robert Haas (robertmh...@gmail.com) wrote: > > > > Preventing people from calling functions by denying the ability to > > > >

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

Peter Geoghegan writes: > It means "another call to tuplesort_gettupleslot", but I believe that > it would be safer (more future-proof) to actually specify "the slot > contents may be invalidated by any subsequent manipulation of the > tuplesort's state" instead. WFM. >> There

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane wrote: > Please. You might want to hit the existing ones with a separate patch, > but it doesn't much matter; I'd be just as happy with a patch that did > both things. Got it. -- Peter Geoghegan -- Sent via pgsql-hackers

Re: [HACKERS] Radix tree for character conversion

On Tue, Jan 10, 2017 at 8:22 PM, Kyotaro HORIGUCHI wrote: > [...patch...] Nobody has showed up yet to review this patch, so I am giving it a shot. The patch file sizes are scary at first sight, but after having a look: 36 files changed, 1411 insertions(+),

Re: [HACKERS] Speedup twophase transactions

On Thu, Jan 26, 2017 at 4:09 PM, Nikhil Sontakke wrote: >>I look at this patch from you and that's present for me: >>https://www.postgresql.org/message-id/CAMGcDxf8Bn9ZPBBJZba9wiyQq->Qk5uqq=vjomnrnw5s+fks...@mail.gmail.com > >> --- a/src/backend/access/transam/xlog.c >>

Re: [HACKERS] logical decoding of two-phase transactions

>> >> Yes, that’s also possible but seems to be less flexible restricting us to >> some >> specific GID format. >> >> Anyway, I can measure WAL space overhead introduced by the GID’s inside >> commit records >> to know exactly what will be the cost of such approach. > > Stas, > > Have you

Re: [HACKERS] Speedup twophase transactions

>I look at this patch from you and that's present for me: >https://www.postgresql.org/message-id/CAMGcDxf8Bn9ZPBBJZba9wiyQq->Qk5uqq=vjomnrnw5s+fks...@mail.gmail.com > --- a/src/backend/access/transam/xlog.c > +++ b/src/backend/access/transam/xlog.c > @@ -9573,6 +9573,7 @@

Re: [HACKERS] Radix tree for character conversion

On Wed, Jan 25, 2017 at 7:18 PM, Ishii Ayumi wrote: > I patched 4 patchset and run "make", but I got failed. > Is this a bug or my mistake ? > I'm sorry if I'm wrong. > > [$(TOP)]$ patch -p1 < ../0001-Add-missing-semicolon.patch > [$(TOP)]$ patch -p1 <

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-01-25 18:04:09 -0500, Stephen Frost wrote: > > Robert's made it clear that he'd like to have a blanket rule that we > > don't have superuser checks in these code paths if they can be GRANT'd > > at the database level, which goes beyond

Re: [HACKERS] pg_hba_file_settings view patch

On Thu, Jan 26, 2017 at 2:32 AM, Tom Lane wrote: > The way I'd be inclined to make the individual reporting changes is like > > if (!EnableSSL) > +{ > - ereport(LOG, > + ereport(elevel, >

Re: [HACKERS] Checksums by default?

On 26 January 2017 at 01:58, Thomas Munro wrote: > > I don't know how comparable it is to our checksum technology, but > MySQL seems to have some kind of checksums on table data, and you can > find public emails, blogs etc lamenting corrupted databases by >

Re: [HACKERS] Checksums by default?

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 7:37 PM, Andres Freund wrote: > > On 2017-01-25 19:30:08 -0500, Stephen Frost wrote: > >> * Peter Geoghegan (p...@heroku.com) wrote: > >> > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost

Re: [HACKERS] Speedup twophase transactions

>> The question remains whether saving off a few fsyncs/reads for these >> long-lived prepared transactions is worth the additional code churn. >> Even if we add code to go through the KnownPreparedList, we still will >> have to go through the other on-disk 2PC transactions anyways. So, >> maybe

Re: [HACKERS] sequence data type

On Wed, Jan 25, 2017 at 11:53 PM, Peter Eisentraut wrote: > Here is an updated patch that allows changing the sequence type. This > was clearly a concern for reviewers, and the presented use cases seemed > convincing. I have been torturing this patch and it

Re: [HACKERS] Speedup twophase transactions

On Thu, Jan 26, 2017 at 1:38 PM, Nikhil Sontakke wrote: >> We should really try to do things right now, or we'll never come back >> to it. 9.3 (if my memory does not fail me?) has reduced the time to do >> promotion by removing the need of the end-of-recovery checkpoint,

Re: [HACKERS] Checksums by default?

On Wed, Jan 25, 2017 at 1:22 PM, Peter Geoghegan wrote: > I understand that my experience with storage devices is unusually > narrow compared to everyone else here. That's why I remain neutral on > the high level question of whether or not we ought to enable checksums > by

Re: [HACKERS] pgbench more operators & functions

Fabien, * Fabien COELHO (coe...@cri.ensmp.fr) wrote: > I think that there is a misunderstanding, most of which being my fault. No worries, it happens. :) > I have really tried to do everything that was required from > committers, including revising the patch to match all previous > feedback.

Re: [HACKERS] Checksums by default?

On Thu, Jan 26, 2017 at 2:28 PM, Stephen Frost wrote: > Sadly, without having them enabled by default, there's not a huge corpus > of example cases to draw from. > > There have been a few examples already posted about corruption failures > with PG, but one can't say with

Re: [HACKERS] Speedup twophase transactions

On Wed, Jan 25, 2017 at 11:55 PM, Nikhil Sontakke wrote: >> We are talking about the recovery/promote code path. Specifically this >> call to KnownPreparedRecreateFiles() in PrescanPreparedTransactions(). >> >> We write the files to disk and they get immediately read up

Re: [HACKERS] Checksums by default?

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 25, 2017 at 6:30 PM, Stephen Frost wrote: > > I hope to discuss it further after we have the ability to turn it off > > easily. > > I think we should have the ability to flip it in BOTH directions easily. Presumably

Re: [HACKERS] Checksums by default?

Peter, * Peter Geoghegan (p...@heroku.com) wrote: > On Wed, Jan 25, 2017 at 1:22 PM, Peter Geoghegan wrote: > > I understand that my experience with storage devices is unusually > > narrow compared to everyone else here. That's why I remain neutral on > > the high level question

Re: [HACKERS] COPY as a set returning function

> > >> I don't understand why do we have all these checks. Can't we just pass >> the values to COPY and let it apply the checks? That way, when COPY is >> updated to support multibyte escape chars (for example) we don't need to >> touch this code. Together with removing the unneeded braces that

Re: [HACKERS] logical decoding of two-phase transactions

On 5 January 2017 at 20:43, Stas Kelvich wrote: > >> On 5 Jan 2017, at 13:49, Simon Riggs wrote: >> >> Surely in this case the master server is acting as the Transaction >> Manager, and it knows the mapping, so we are good? >> >> I guess if you

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Wed, Jan 25, 2017 at 8:22 PM, Stephen Frost wrote: > Apparently we disagree about what is a 'reasonable manner'. Yes. I think that a "reasonable manner" should mean "what the DBA thinks is reasonable", whereas you apparently think it should mean "what the DBA thinks is

  1   2   >