Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Sat, Nov 19, 2016 at 6:45 PM, Robert Haas wrote: >> What do you think about new argument with default vs. GUC? I guess >> that the GUC might be a lot less of a foot-gun. We might even give it >> a suitably scary name, to indicate that it will make the server PANIC. >> (I gather that you don't c

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Fri, Nov 18, 2016 at 6:51 PM, Peter Geoghegan wrote: > On Thu, Nov 17, 2016 at 12:04 PM, Peter Geoghegan wrote: >>> Hm, if we want that - and it doesn't seem like a bad idea - I think we >>> should be make it available without recompiling. >> >> I suppose, provided it doesn't let CORRUPTION el

Re: [HACKERS] [sqlsmith] Crash on GUC serialization

Robert Haas writes: > On Sat, Nov 19, 2016 at 12:31 PM, Tom Lane wrote: >> Thanks for the report! Looks like the serialization code has overlooked >> the fact that string-valued GUCs can be NULL. Surprising we didn't >> find that before ... > Why do we allow this, anyway? I think it simplifie

Re: [HACKERS] [sqlsmith] Crash on GUC serialization

On Sat, Nov 19, 2016 at 12:31 PM, Tom Lane wrote: > Andreas Seltenreich writes: >> sqlsmith just made a GUC that tricks the serialization code into >> dereferencing a nullpointer. Here's a recipe: > > Thanks for the report! Looks like the serialization code has overlooked > the fact that string

Re: [HACKERS] [PATCH] pgpassfile connection option

All, * Robert Haas (robertmh...@gmail.com) wrote: > You could do something like that, I guess, but I think it might be a > good idea to wait and see if anyone else has opinions on (1) the > desirability of the basic feature, (2) the severity of the security > hazard it creates, and (3) your propos

Re: [HACKERS] Improvements in psql hooks for variables

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > In reviewing this patch, I also noticed that it's set up to assume a > > 'true' result when a variable can't be parsed by ParseVariableBool. > > I suppose that's meant to be backwards-compatible with the current > behavior: Ah, g

Re: [HACKERS] Improvements in psql hooks for variables

Stephen Frost writes: > In reviewing this patch, I also noticed that it's set up to assume a > 'true' result when a variable can't be parsed by ParseVariableBool. I suppose that's meant to be backwards-compatible with the current behavior: regression=# \timing foo unrecognized value "foo" for "\

Re: [HACKERS] Improvements in psql hooks for variables

Daniel, * Daniel Verite (dan...@manitou-mail.org) wrote: > I'm attaching v3 of the patch with error reporting for > FETCH_COUNT as mentioned upthread, and rebased > on the most recent master. Just fyi, there seems to be some issues with this patch because setting my PROMPT1 and PROMPT2 variables

Re: [HACKERS] Hash tables in dynamic shared memory

I reviewed the dht-v2.patch and found that it is in excellent shape. Benchmarking shows that this performs somewhat faster than dynahash which is surprising because it is doing DSA address translations on the fly. One area where this could run faster is to reduce the amount of time when the hash

[HACKERS] Bogus use of *-expansion in UPDATE

You get an odd result if you write "something.*" in an UPDATE's source expressions: regression=# create table t1 (f1 int, f2 int, f3 int); CREATE TABLE regression=# update t1 set f1 = t1.*; ERROR: UPDATE target count mismatch --- internal error The reason for that is that we use transformTargetL

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

Stephen Frost writes: > Let's create a new data type for this which supports old and new types, > add what casts make sense, and call it a day. Changing the data type > name out from under people is not helping anyone. +1. I do not think changing behavior for the existing type name is going to

Re: [HACKERS] possible optimizations - pushing filter before aggregation

Douglas Doole writes: > For min, you should be able to pre-filter =, < , and <=. In all cases the > pre-filter would be <=. For max it would be =, > , >= becoming >=. Doesn't really seem worth the trouble to me, given that those are pretty unselective filter conditions. If you could push down an

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

* Shay Rojansky (r...@roji.org) wrote: > > > > > As I said before, Npgsql for one loads data types by name, not by OID. > >>> > So this would definitely cause breakage. > >>> > >>> Why would that cause breakage? > >> > >> Well, the first thing Npgsql does when it connects to a new database, is > >>

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Sat, 19 Nov 2016 18:59:49 +0100 Gilles Darold wrote: > Le 19/11/2016 à 16:22, Karl O. Pinc a écrit : > > Hi Gilles, > > > > On Tue, 15 Nov 2016 15:15:52 -0600 > > "Karl O. Pinc" wrote: > > > >>> On Mon, 7 Nov 2016 23:29:28 +0100 > >>> Gilles Darold wrote: > - Do not write curren

Re: [HACKERS] [sqlsmith] Crash on GUC serialization

Michael Paquier writes: > On Sat, Nov 19, 2016 at 9:31 AM, Tom Lane wrote: >> Thanks for the report! Looks like the serialization code has overlooked >> the fact that string-valued GUCs can be NULL. Surprising we didn't >> find that before ... > I was half-way through it when you sent your ema

Re: [HACKERS] [BUG?] pg_event_trigger_ddl_commands() error with ALTER TEXT SEARCH CONFIGURATION

On Thu, Nov 17, 2016 at 1:17 PM, Alvaro Herrera wrote: > It's a bug. You're right that we need to handle the object class > somewhere. Perhaps I failed to realize that tsconfigs could get > altered. It seems to me that the thing to be careful of here is how a new OBJECT_TSCONFIGURATIONMAP shoul

Re: [HACKERS] [sqlsmith] Crash on GUC serialization

On Sat, Nov 19, 2016 at 9:51 AM, Andreas Seltenreich wrote: > Michael Paquier writes: > >> [2. text/plain; fix-guc-string-eval.patch] > > I'm afraid taking care of the length computation is not sufficient. > ISTM like it'll still try to serialize the NULL pointer later on in > serialize_variable:

Re: [HACKERS] possible optimizations - pushing filter before aggregation

> > In above case wondering if we could do this > > Min(a) = 2 is the condition, generate condition *"a <= 2"* and push it > down as scan key. Since pushed down condition is lossy one for us ( it > gives values < 2), finally do a recheck of *"Min(a) = 2"*. > > For Max(a) = 2 we can have *"a >=2"*,

Re: [HACKERS] Patch to implement pg_current_logfile() function

Le 19/11/2016 à 16:22, Karl O. Pinc a écrit : > Hi Gilles, > > On Tue, 15 Nov 2016 15:15:52 -0600 > "Karl O. Pinc" wrote: > >>> On Mon, 7 Nov 2016 23:29:28 +0100 >>> Gilles Darold wrote: - Do not write current_logfiles when log_collector is activated but log_destination doesn't cont

Re: [HACKERS] [sqlsmith] Crash on GUC serialization

Michael Paquier writes: > [2. text/plain; fix-guc-string-eval.patch] I'm afraid taking care of the length computation is not sufficient. ISTM like it'll still try to serialize the NULL pointer later on in serialize_variable: ,[ guc.c:9108 ] | case PGC_STRING: | { | struct config_st

Re: [HACKERS] [sqlsmith] Crash on GUC serialization

On Sat, Nov 19, 2016 at 9:31 AM, Tom Lane wrote: > Andreas Seltenreich writes: >> sqlsmith just made a GUC that tricks the serialization code into >> dereferencing a nullpointer. Here's a recipe: > > Thanks for the report! Looks like the serialization code has overlooked > the fact that string-

Re: [HACKERS] pg_dump -s -b

* Tom Lane (t...@sss.pgh.pa.us) wrote: > IMO, blobs are data, so those behaviors are correct. The docs should > be fixed to match the code. Works for me. Thoughts on the attached? Thanks! Stephen diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml new file mode 100644 in

Re: [HACKERS] [sqlsmith] Crash on GUC serialization

Andreas Seltenreich writes: > sqlsmith just made a GUC that tricks the serialization code into > dereferencing a nullpointer. Here's a recipe: Thanks for the report! Looks like the serialization code has overlooked the fact that string-valued GUCs can be NULL. Surprising we didn't find that be

Re: [HACKERS] Mail thread references in commits

My solution requires that everything have an issue. E.g., hackers becomes a tracker. Sincerely, Jd On Nov 19, 2016 09:04, "Tom Lane" wrote: > "Joshua D. Drake" writes: > > I wonder if now is the time (again) to consider an issue tracker. > > That would make the problem at hand worse, not bett

Re: [HACKERS] pg_dump -s -b

Stephen Frost writes: > To wit, our docs specifically say: > > Include large objects in the dump. This is the default behavior except > when --schema, --table, or --schema-only is specified, so the -b switch > is only useful to add large objects to selective dumps. > Clearly, this is an

[HACKERS] pg_dump -s -b

All, While reviewing and considering the patch to add the --no-blobs option to pg_dump, which I entirely agree with, I came across our claim that passing -b to pg_dump would cause blobs to be output, regardless of other options set. To wit, our docs specifically say: Include large objects i

Re: [HACKERS] Mail thread references in commits

"Joshua D. Drake" writes: > I wonder if now is the time (again) to consider an issue tracker. That would make the problem at hand worse, not better, because you'd get nothing at all for cases that were too trivial to make an issue tracker entry for, or that the committer couldn't be bothered to g

Re: [HACKERS] Mail thread references in commits

Andrew Dunstan writes: > On 11/19/2016 10:11 AM, Stephen Frost wrote: >> That's actually not the case if we use a hash, because the client could >> figure out what the hash is before sending it. > The fact that it could possibly be done is not a good reason for doing > it. Quite. I will *not*

Re: [HACKERS] Mail thread references in commits

On 11/17/2016 01:02 PM, Andrew Dunstan wrote: I love seeing references to email threads in commit messages. It would make them a lot friendlier though if a full http URL were included instead of just a Message-ID, i.e. instead of put . I kno

Re: [HACKERS] How to change order sort of table in HashJoin

Man Trieu writes: > As in the example below, i think the plan which hash table is created on > testtbl2 (the fewer tuples) should be choosen. The planner usually prefers to hash on the table that has a flatter MCV histogram, since a hash table with many key collisions will be inefficient. You mi

Re: [HACKERS] Patch to implement pg_current_logfile() function

Hi Gilles, On Tue, 15 Nov 2016 15:15:52 -0600 "Karl O. Pinc" wrote: > > On Mon, 7 Nov 2016 23:29:28 +0100 > > Gilles Darold wrote: > > > - Do not write current_logfiles when log_collector is activated > > > but log_destination doesn't contained stderr or csvlog. This was > > > creating an

Re: [HACKERS] Mail thread references in commits

On 11/19/2016 10:11 AM, Stephen Frost wrote: * Magnus Hagander (mag...@hagander.net) wrote: On Nov 19, 2016 15:33, "Andrew Dunstan" wrote: I can think of at least one scenario where you might not easily have access to any invented ID - you're the author and you have mailing list me-too turn

Re: [HACKERS] Mail thread references in commits

* Magnus Hagander (mag...@hagander.net) wrote: > On Nov 19, 2016 15:33, "Andrew Dunstan" wrote: > > I can think of at least one scenario where you might not easily have > access to any invented ID - you're the author and you have mailing list > me-too turned off, so you don't have anything that th

Re: [HACKERS] Mail thread references in commits

On Nov 19, 2016 15:33, "Andrew Dunstan" wrote: > > > > On 11/19/2016 07:36 AM, Stephen Frost wrote: >> >> Magnus, >> >> * Magnus Hagander (mag...@hagander.net) wrote: >>> >>> On Sat, Nov 19, 2016 at 1:07 AM, Stephen Frost wrote: * Magnus Hagander (mag...@hagander.net) wrote: > >

Re: [HACKERS] [GENERAL] How to change order sort of table in HashJoin

On Sat, Nov 19, 2016 at 12:46 AM, Man Trieu wrote: > Hi Experts, > > As in the example below, i think the plan which hash table is created on > testtbl2 (the fewer tuples) should be choosen. > Because creating of hash table should faster in testtbl2. But it did not. > > I have tried to change the

Re: [HACKERS] Mail thread references in commits

On 11/19/2016 07:36 AM, Stephen Frost wrote: Magnus, * Magnus Hagander (mag...@hagander.net) wrote: On Sat, Nov 19, 2016 at 1:07 AM, Stephen Frost wrote: * Magnus Hagander (mag...@hagander.net) wrote: It would make the URLs actually short, but as mentioned upthread, that wouldn't work at a

Re: [HACKERS] possible optimizations - pushing filter before aggregation

On Sat, Nov 19, 2016 at 8:59 AM, Pavel Stehule wrote: > > > >> SELECT MIN(a) m FROM >>(SELECT a FROM t WHERE a=2) AS v(a) >> >> The subquery is going to return an intermediate result of: >> >> V:A >> --- >> 2 >> >> And the minimum of that is 2, which is the wrong answer. >> > > yes, you have

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Sat, 19 Nov 2016 12:58:47 +0100 Gilles Darold wrote: > All patches you've submitted on tha v13 patch have been applied and > are present in attached v14 of the patch. I have not included the > patches about GUC changes because I'm not sure that adding a new file > (include/utils/guc_values.h)

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

On Mon, Nov 14, 2016 at 9:44 PM, Dilip Kumar wrote: >> Also, what if we abandoned the idea of pushing qual evaluation all the >> way down into the heap and just tried to do HeapKeyTest in SeqNext >> itself? Would that be almost as fast, or would it give up most of the >> benefits? > This we can d

[HACKERS] [sqlsmith] Crash on GUC serialization

Hi, sqlsmith just made a GUC that tricks the serialization code into dereferencing a nullpointer. Here's a recipe: --8<---cut here---start->8--- set min_parallel_relation_size to 0; set max_parallel_workers_per_gather to 2; set force_parallel_mode to on; begin

Re: [HACKERS] Mail thread references in commits

Magnus, * Magnus Hagander (mag...@hagander.net) wrote: > On Sat, Nov 19, 2016 at 1:07 AM, Stephen Frost wrote: > > * Magnus Hagander (mag...@hagander.net) wrote: > > > It would make the URLs actually short, but as mentioned upthread, that > > > wouldn't work at all if offline. So it'd be a tradeo

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On 11/18/16 12:38 PM, David Steele wrote: > On 11/14/16 4:29 AM, Michael Paquier wrote: >> On Mon, Nov 14, 2016 at 6:10 PM, Kyotaro HORIGUCHI >>> If I'm not missing something, at the worst we have a checkpoint >>> after a checkpointer restart that should have been supressed. Is >>> it worth pickin

Re: [HACKERS] Patch to implement pg_current_logfile() function

Le 16/11/2016 à 17:38, Karl O. Pinc a écrit : > On Mon, 7 Nov 2016 23:29:28 +0100 > Gilles Darold wrote: > >> Here is the v13 of the patch, ... > Attached is a doc patch to apply on top of v13. > > It adds a lot more detail regards just what is > in the current_logfiles file and when it's > in cur

Re: [HACKERS] Mail thread references in commits

On Sat, Nov 19, 2016 at 1:07 AM, Stephen Frost wrote: > Magnus, > > * Magnus Hagander (mag...@hagander.net) wrote: > > It would make the URLs actually short, but as mentioned upthread, that > > wouldn't work at all if offline. So it'd be a tradeoff between those, but > > so are pretty much all ot