Re: [HACKERS] Bug in to_timestamp().

On 13.06.2016 18:52, amul sul wrote: Hi, It's look like bug in to_timestamp() function when format string has more whitespaces compare to input string, see below: Ex.1: Two white spaces before HH24 whereas one before input time string postgres=# SELECT TO_TIMESTAMP('2016-06-13 15:43:36',

Re: [HACKERS] 10.0

> On Jun 18, 2016, at 5:48 PM, Josh Berkus wrote: > > On 06/16/2016 11:01 PM, Craig Ringer wrote: >> >> I thought about raising this, but I think in the end it's replacing one >> confusing and weird versioning scheme for another confusing and weird >> versioning scheme. >>

Re: [HACKERS] parallel.c is not marked as test covered

On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote: >> although I fear we >> might be getting to a level of tinkering with parallel query that >> starts to look more like feature development. > > Personally, I'm +1 for such tinkering if it makes the feature either more >

Re: [HACKERS] 10.0

On Monday, June 20, 2016, Mark Dilger wrote: > > > On Jun 18, 2016, at 5:48 PM, Josh Berkus > wrote: > > > > On 06/16/2016 11:01 PM, Craig Ringer wrote: > >> > >> I thought about raising this, but I think in the end it's replacing one >

Re: [HACKERS] Bug in to_timestamp().

On 20.06.2016 16:36, Tom Lane wrote: Robert Haas writes: On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote: I think a space in the format string should skip a whitespace character in the input string, but not a non-whitespace character. It's

Re: [HACKERS] 10.0

> On Jun 20, 2016, at 8:53 AM, Mark Dilger wrote: > > > This is not a plea for keeping the three part versioning system. It's just > a plea not to have a 2 part versioning system masquerading as a three > part versioning system, or vice versa. To clarify my concern,

Re: [HACKERS] New design for FK-based join selectivity estimation

Tomas Vondra writes: > OK, thanks. The one thing we haven't done is testing the performance, to > see how this fares. So I've repeated the tests I've done on the original > version of the patch here Hmm. I'm not that excited about these results, for a couple of

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

We're really quickly running out of time to get this done before beta2. Please don't commit anything that's going to break the tree because we only have about 72 hours before the wrap, but if it's correct then it should go in. Isn't late now? Or wait to beta2 is out? -- Teodor Sigaev

Re: [HACKERS] 10.0

> > In practical effect that is exactly what your proposal does. You just feel > better because you defined when B is allowed to change even though it never > should happen based upon our project policy. And any rare exception can > justifiably be called a bug fix because, face it, it would

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

Teodor Sigaev writes: >> We're really quickly running out of time to get this done before >> beta2. Please don't commit anything that's going to break the tree >> because we only have about 72 hours before the wrap, but if it's >> correct then it should go in. > Isn't late

Re: [HACKERS] parallel.c is not marked as test covered

On Mon, Jun 20, 2016 at 1:26 AM, Amit Kapila wrote: > I have done analysis on this and didn't found any use case where passing > CURSOR_OPT_PARALLEL_OK in exec_stmt_execsql() can help in parallelizing the > queries. Basically, there seems to be three ways in which

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger wrote: > > > On Jun 20, 2016, at 8:53 AM, Mark Dilger > wrote: > > > > > > This is not a plea for keeping the three part versioning system. It's > just > > a plea not to have a 2 part versioning

[HACKERS] Actuall row count of Parallel Seq Scan in EXPLAIN ANALYZE .

Hi all, My colleague noticed that the output of EXPLAIN ANALYZE doesn't work fine for parallel seq scan. postgres(1)=# explain analyze verbose select count(*) from pgbench_accounts ; QUERY PLAN

Re: [HACKERS] Actuall row count of Parallel Seq Scan in EXPLAIN ANALYZE .

On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada wrote: > > Hi all, > > My colleague noticed that the output of EXPLAIN ANALYZE doesn't work > fine for parallel seq scan. > > postgres(1)=# explain analyze verbose select count(*) from pgbench_accounts ; >

Re: [HACKERS] Actuall row count of Parallel Seq Scan in EXPLAIN ANALYZE .

On Mon, Jun 20, 2016 at 12:47 PM, Amit Langote < langote_amit...@lab.ntt.co.jp> wrote: > > On 2016/06/20 15:42, Amit Kapila wrote: > > > >> > >> After spent time to investigate this behaviour, ISTM that the problem > >> is nloops of Parallel Seq Scan. > >> Parallel Seq Scan is done only once, but

Re: [HACKERS] Actuall row count of Parallel Seq Scan in EXPLAIN ANALYZE .

On Mon, Jun 20, 2016 at 3:42 PM, Amit Kapila wrote: > On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada > wrote: >> >> Hi all, >> >> My colleague noticed that the output of EXPLAIN ANALYZE doesn't work >> fine for parallel seq scan. >> >>

Re: [HACKERS] Actuall row count of Parallel Seq Scan in EXPLAIN ANALYZE .

Hi, 2016-06-20 15:42 GMT+09:00 Amit Kapila : > On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada > wrote: >> >> Hi all, >> >> My colleague noticed that the output of EXPLAIN ANALYZE doesn't work >> fine for parallel seq scan. >> >> postgres(1)=#

Re: [HACKERS] Parallelized polymorphic aggs, and aggtype vs aggoutputtype

On 18 June 2016 at 05:45, Tom Lane wrote: > The situation is much direr as far as serialize/deserialize are concerned. > These basically don't work at all for polymorphic transtypes: if you try > to declare "deserialize(bytea) returns anyarray", the type system won't > let

Re: [HACKERS] Actuall row count of Parallel Seq Scan in EXPLAIN ANALYZE .

On 2016/06/20 15:42, Amit Kapila wrote: > On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada > wrote: >> >> Hi all, >> >> My colleague noticed that the output of EXPLAIN ANALYZE doesn't work >> fine for parallel seq scan. >> [ ... ] >> For example, the above result shows,

Re: [HACKERS] Actuall row count of Parallel Seq Scan in EXPLAIN ANALYZE .

On Mon, Jun 20, 2016 at 12:24 PM, Masahiko Sawada wrote: > > > In following case, it look to me that no one collect the tuple. > But it's obviously incorrect, this query collects a tuple(aid = 10) actually. > > postgres(1)=# explain analyze verbose select * from

Re: [HACKERS] Bug in to_timestamp().

Tom Lane wrote: > I don't necessarily have an opinion yet. I would like to see more than > just an unsupported assertion about what Oracle's behavior is. Also, > how should FM mode affect this? I can supply what Oracle 12.1 does: SQL> SELECT to_timestamp('2016-06-13 15:43:36', ' /MM/DD

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On 19/06/16 13:02, Michael Paquier wrote: > On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote: >> On 19/06/16 12:28, Michael Paquier wrote: >>> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier >>> Or in short the attached. >> >> The code looks good to me but why no

Re: [HACKERS] parallel.c is not marked as test covered

On Thu, Jun 16, 2016 at 8:20 AM, Robert Haas wrote: > > On Wed, Jun 15, 2016 at 10:48 PM, Amit Kapila wrote: > > exec_stmt_execsql() is used to execute SQL statements insider plpgsql which > > includes dml statements as well, so probably you wanted

Re: [HACKERS] Bug in to_timestamp().

On Mon, Jun 20, 2016 at 8:19 AM, Robert Haas wrote: > On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas > wrote: > > On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane wrote: > >> amul sul writes: > >>> It's look like

Re: [HACKERS] Parallelized polymorphic aggs, and aggtype vs aggoutputtype

On 20 June 2016 at 19:06, David Rowley wrote: > On 18 June 2016 at 05:45, Tom Lane wrote: >> A possible solution is to give deserialize an extra dummy argument, along >> the lines of "deserialize(bytea, internal) returns internal", thereby >>

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

Thank you for useful suggestions. PFA patch, I have tried to cover all the points mentioned. Regards, Muhammad Asif Naeem On Wed, Apr 6, 2016 at 9:06 PM, Robert Haas wrote: > On Wed, Apr 6, 2016 at 3:32 AM, Asif Naeem wrote: > >> Oh, I see. I think

Re: [HACKERS] Bug in to_timestamp().

On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote: > On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane wrote: >> amul sul writes: >>> It's look like bug in to_timestamp() function when format string has more >>> whitespaces compare to

Re: [HACKERS] Bug in to_timestamp().

Robert Haas writes: > On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote: >> I think a space in the format string should skip a whitespace >> character in the input string, but not a non-whitespace character. >> It's my understanding that these

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger wrote: >> In practical effect that is exactly what your proposal does. You just feel >> better because you defined when B is allowed to change even though it never >> should happen based upon our project policy. And any

Re: [HACKERS] New design for FK-based join selectivity estimation

Tomas Vondra writes: > On 06/18/2016 06:52 PM, Tom Lane wrote: >> I concur, actually, but I feel that it's out of scope for this >> particular patch, which is only trying to replace the functionality >> that was committed previously. If you want to come up with a

[HACKERS] pager_min_lines tab completion

I have just noticed that when I added the pager_min_lines psetting to psql in 9.5, I omitted to add it to the relevant piece of tab-complete.c. If no-one objects I propose to remedy that shortly and backpatch it. cheers andrew -- Sent via pgsql-hackers mailing list

Re: [HACKERS] 10.0

> On Jun 20, 2016, at 9:38 AM, David G. Johnston > wrote: > > On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger wrote: > > > On Jun 20, 2016, at 8:53 AM, Mark Dilger wrote: > > > > > > This is not a plea for keeping

Re: [HACKERS] 10.0

> On Jun 20, 2016, at 11:06 AM, Joshua D. Drake wrote: > > On 06/20/2016 10:45 AM, Mark Dilger wrote: > >>> Now maybe you have some other idea in mind, but I don't quite >>> understand what it is. >> >> I do, indeed, and here it is: >> >> When considering whether to

Re: [HACKERS] 10.0

> On Jun 20, 2016, at 9:43 AM, Robert Haas wrote: > > On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger wrote: >>> In practical effect that is exactly what your proposal does. You just feel >>> better because you defined when B is allowed to change

Re: [HACKERS] 10.0

Mark Dilger wrote: > When considering whether to *back port* a change, we typically do so > on the basis that bug fixes are back ported, features are not. In my > proposed versioning scheme, you could back port any feature that is > compatible with the old version, and bump the middle number to

Re: [HACKERS] parallel.c is not marked as test covered

On Mon, Jun 20, 2016 at 3:29 PM, David G. Johnston wrote: > The entire theory here looks whacked - and seems to fall into the "GUCs > controlling results" bucket of undesirable things. As far as I can see, this entire email is totally wrong and off-base, because the

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 20, 2016 at 3:33 PM, Andres Freund wrote: >> I'm not sure what to do about this: this part of the heap_update() >> logic has been like this forever, and I assume that if it were easy to >> refactor this away, somebody would have done it by now. > > Well, I think

Re: [HACKERS] 10.0

Robert Haas writes: > On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston > wrote: >> 10.x is the desired output. > 10.x is the output that some people desire. A significant number of > people, including me, would prefer to stick with the

Re: [HACKERS] 10.0

Alvaro Herrera writes: > Tom Lane wrote: >> If we were going to do it like that, I would argue for "every ten years >> like clockwork", e.g. 10.0.x is next after 9.9.x. But in point of fact, >> Robert, you already made your case for that approach and nobody else >>

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 4:20 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston >> wrote: >>> 10.x is the desired output. > >> 10.x is the output that some people desire. A

Re: [HACKERS] forcing a rebuild of the visibility map

Andres Freund writes: > I also don't see why it's a good idea to have knowledge about how to > truncate the visibility map outside of visibilitymap.c. Having that in a > contrib module just seems like a modularity violation. That seems like a pretty good argument.

Re: [HACKERS] parallel.c is not marked as test covered

Robert Haas writes: > On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote: >> Personally, I'm +1 for such tinkering if it makes the feature either more >> controllable or more understandable. After reading the comments at the >> head of nodeGather.c,

Re: [HACKERS] 10.0

> On Jun 20, 2016, at 1:00 PM, David G. Johnston > wrote: > > On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger wrote: > > > Do you have a problem with the human form and machine forms of the version > > number being different in this respect?

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston wrote: > 10.x is the desired output. 10.x is the output that some people desire. A significant number of people, including me, would prefer to stick with the current three-part versioning scheme, possibly with some

Re: [HACKERS] Reviewing freeze map code

On 2016-06-20 16:10:23 -0400, Robert Haas wrote: > What exactly is the point of all of that already_marked stuff? Preventing the old tuple from being locked/updated by another backend, while unlocking the buffer. > I > mean, suppose we just don't do any of that before we go off to do >

Re: [HACKERS] 10.0

Tom Lane wrote: > Robert Haas writes: > > On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston > > wrote: > >> 10.x is the desired output. > > > 10.x is the output that some people desire. A significant number of > > people, including me, would

Re: [HACKERS] parallel.c is not marked as test covered

On Mon, Jun 20, 2016 at 4:03 PM, Robert Haas wrote: > On Mon, Jun 20, 2016 at 3:29 PM, David G. Johnston > wrote: > > The entire theory here looks whacked - and seems to fall into the "GUCs > > controlling results" bucket of undesirable things.

Re: [HACKERS] 10.0

On 06/20/2016 01:41 PM, Alvaro Herrera wrote: Tom Lane wrote: Robert Haas writes: On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston wrote: If we were going to do it like that, I would argue for "every ten years like clockwork", e.g.

Re: [HACKERS] parallel.c is not marked as test covered

On Mon, Jun 20, 2016 at 1:13 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote: >>> Personally, I'm +1 for such tinkering if it makes the feature either more >>> controllable or more

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger wrote: > > > Do you have a problem with the human form and machine forms of the > version number being different in this respect? I don't - for me the > decision of a choice for the human form is not influenced by the fact

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 4:14 PM, Robert Haas wrote: > On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston > wrote: > > 10.x is the desired output. > > 10.x is the output that some people desire. A significant number of > people, including me,

Re: [HACKERS] forcing a rebuild of the visibility map

On 2016-06-18 11:56:51 -0400, Tom Lane wrote: > Michael Paquier writes: > > On Sat, Jun 18, 2016 at 6:53 AM, Robert Haas wrote: > >> Andres, do you want to explain the nature of your concern further? > > > I am not in his mind, but my guess is

Re: [HACKERS] parallel.c is not marked as test covered

Alvaro Herrera writes: > Tom Lane wrote: >> This seems like pretty good evidence that we should remove the "ignored" >> marking for the random test, and maybe remove that functionality from >> pg_regress altogether. We could probably adjust the test to decrease >> its

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 21, 2016 at 9:21 AM, Andres Freund wrote: > > On 2016-06-21 08:59:13 +0530, Amit Kapila wrote: > > Can we consider to use some strategy to avoid deadlocks without releasing > > the lock on old page? Consider if we could have a mechanism such that > >

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake wrote: > Or we could adopt the very reasonable and practical policy of: > > The current versioning scheme isn't broke, so we aren't going to fix it. Yeah, no kidding. We had a perfectly good consensus to keep this at 9.6

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 4:55 PM, Tom Lane wrote: > No, the argument for it was that we'd no longer have to have the annual > discussions about "is it 10.0 yet?". WHAT annual argument? Did anyone even argue that any 9.x release prior to 9.6 deserved to be called 10.0? Maybe

Re: [HACKERS] forcing a rebuild of the visibility map

On Mon, Jun 20, 2016 at 4:57 PM, Tom Lane wrote: > Andres Freund writes: >> I also don't see why it's a good idea to have knowledge about how to >> truncate the visibility map outside of visibilitymap.c. Having that in a >> contrib module just seems like a

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger wrote: > > > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake > wrote: > > > > On 06/20/2016 10:45 AM, Mark Dilger wrote: > > > >>> Now maybe you have some other idea in mind, but I don't quite > >>>

[HACKERS] [sqlsmith] OOM crash in plpgsql_extra_checks_check_hook

Just had a parallel worker of a memory-starved instance of sqlsmith crash. plpgsql_extra_checks_check_hook forgot to check the result of its malloc call here: Core was generated by `postgres: bgworker: parallel worker for PID 5905 '. Program terminated with signal SIGSEGV,

Re: [HACKERS] [sqlsmith] OOM crash in plpgsql_extra_checks_check_hook

Andreas Seltenreich writes: > Just had a parallel worker of a memory-starved instance of sqlsmith > crash. plpgsql_extra_checks_check_hook forgot to check the result of > its malloc call here: Good catch, will fix. Thanks! regards, tom lane --

Re: [HACKERS] 10.0

Hi, I recently bumped into http://semver.org/ It can be interesting to participants of this discussion. Especially motivation for minor version (middle number). Best, Grazvydas On Mon, Jun 20, 2016 at 9:30 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Mon, Jun 20, 2016

Re: [HACKERS] 10.0

> On Jun 20, 2016, at 11:30 AM, David G. Johnston > wrote: > > On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger wrote: > > > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake > > wrote: > > > > On 06/20/2016 10:45 AM,

Re: [HACKERS] parallel.c is not marked as test covered

On Mon, Jun 20, 2016 at 12:06 PM, Robert Haas wrote: > On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote: > >> although I fear we > >> might be getting to a level of tinkering with parallel query that > >> starts to look more like feature development. >

Re: [HACKERS] Reviewing freeze map code

On 2016-06-15 08:56:52 -0400, Robert Haas wrote: > Yikes: heap_update() sets the tuple's XMAX, CMAX, infomask, infomask2, > and CTID without logging anything or clearing the all-visible flag and > then releases the lock on the heap page to go do some more work that > might even ERROR out. Only if

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 1:48 PM, Mark Dilger wrote: > > > On Jun 20, 2016, at 9:38 AM, David G. Johnston < > david.g.johns...@gmail.com> wrote: > > > > On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger > wrote: > > > > > On Jun 20, 2016, at 8:53 AM,

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On 19/06/16 13:02, Michael Paquier wrote: > On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote: >> On 19/06/16 12:28, Michael Paquier wrote: >>> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier >>> Or in short the attached. >> >> The code looks good to me but why no

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 3:07 PM, Gražvydas Valeika wrote: > Hi, > > I recently bumped into http://semver.org/ > > It can be interesting to participants of this discussion. > > Especially motivation for minor version (middle number). > > ​While we appreciate the comment this

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, May 24, 2016 at 09:23:27AM -0500, Jim Nasby wrote: > On 5/16/16 2:36 AM, Bruce Momjian wrote: > >Right. I am thinking of writing some docs about how to avoid downtime > >for upgrades of various types. > > If there's some magic sauce to shrink pg_upgrade downtime to near 0 I think > folks

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 20, 2016 at 07:40:53PM -0400, Robert Haas wrote: > On Mon, May 16, 2016 at 3:36 AM, Bruce Momjian wrote: > > On Sun, May 15, 2016 at 03:23:52PM -0500, Jim Nasby wrote: > >> 2) There's no ability at all to revert, other than restore a backup. That > >> means if you

Re: [HACKERS] parallel.c is not marked as test covered

On 6/19/16 5:55 PM, Tom Lane wrote: Depending on what the percentage actually is, maybe we could treat this like the "random" test, and allow a failure to be disregarded overall? But that doesn't seem very nice either, in view of our increasing reliance on automated testing. If "random" were

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

Peter Eisentraut writes: > On 6/20/16 10:29 PM, Tom Lane wrote: >> What I would want to know is whether this specific change is actually a >> good idea. In particular, I'm concerned about the possible security >> implications of exposing primary_conninfo ---

Re: [HACKERS] parallel.c is not marked as test covered

Peter Eisentraut writes: > On 6/19/16 5:55 PM, Tom Lane wrote: >> Depending on what the percentage actually is, maybe we could treat >> this like the "random" test, and allow a failure to be disregarded >> overall? But that doesn't seem very nice either, in view

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 21, 2016 at 1:03 AM, Andres Freund wrote: > > On 2016-06-15 08:56:52 -0400, Robert Haas wrote: > > Yikes: heap_update() sets the tuple's XMAX, CMAX, infomask, infomask2, > > and CTID without logging anything or clearing the all-visible flag and > > then releases

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila wrote: > Some others ways could be: > > Before releasing the lock on buffer containing old tuple, clear the VM and > visibility info from page and WAL log it. I think this could impact > performance depending on how frequently

Re: [HACKERS] Reviewing freeze map code

On 2016-06-21 08:59:13 +0530, Amit Kapila wrote: > Can we consider to use some strategy to avoid deadlocks without releasing > the lock on old page? Consider if we could have a mechanism such that > RelationGetBufferForTuple() will ensure that it always returns a new buffer > which has

Re: [HACKERS] parallel.c is not marked as test covered

On Tue, Jun 21, 2016 at 1:24 AM, Robert Haas wrote: > > On Mon, Jun 20, 2016 at 1:13 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote: > >>> Personally, I'm +1

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 21, 2016 at 9:08 AM, Thomas Munro wrote: > > On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila wrote: > > On Tue, Jun 21, 2016 at 1:03 AM, Andres Freund wrote: > >> Well, I think generally nobody seriously looked

[HACKERS] Missing checks when malloc returns NULL...

Hi all, While auditing the code, I got surprised that there are a couple of code paths that do nothing for this error handling: - pg_regress and isolationtester use malloc extensively, in case of failure those would just crash crash. I think that it matters for buildfarm members that are under

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 21, 2016 at 9:16 AM, Thomas Munro wrote: > > On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila wrote: > > Some others ways could be: > > > > Before releasing the lock on buffer containing old tuple, clear the VM and > > visibility

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Mon, Jun 20, 2016 at 11:26 PM, Vik Fearing wrote: > On 19/06/16 13:02, Michael Paquier wrote: >> On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote: >>> On 19/06/16 12:28, Michael Paquier wrote: On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

Michael Paquier writes: > On Tue, Jun 21, 2016 at 9:58 AM, Tatsuo Ishii wrote: >> Even there seems to be ongoing discussions on changing version number >> while in the beta period (and which definitely requires initdb). Why >> not changing system

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Tue, Jun 21, 2016 at 12:06 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 6/20/16 10:29 PM, Tom Lane wrote: >>> What I would want to know is whether this specific change is actually a >>> good idea. In particular, I'm concerned

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila wrote: > On Tue, Jun 21, 2016 at 1:03 AM, Andres Freund wrote: >> Well, I think generally nobody seriously looked at actually refactoring >> heap_update(), even though that'd be a good idea. But in this

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

>> Thanks, this looks good. Could you please add it to the next commitfest >> so that it doesn't get lost and also so I can do an official review of it? > > Yes, I just did that. That's too late for 9.6 anyway with beta2 close by. Even there seems to be ongoing discussions on changing version

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Tue, Jun 21, 2016 at 11:29 AM, Tom Lane wrote: > Michael Paquier writes: >> On Tue, Jun 21, 2016 at 9:58 AM, Tatsuo Ishii wrote: >>> Even there seems to be ongoing discussions on changing version number >>> while in the

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

Michael Paquier writes: > On Tue, Jun 21, 2016 at 11:29 AM, Tom Lane wrote: >> What I would want to know is whether this specific change is actually a >> good idea. In particular, I'm concerned about the possible security >> implications of

Re: [HACKERS] Parallel query and temp_file_limit

Peter Geoghegan writes: > On Wed, May 18, 2016 at 3:40 AM, Robert Haas wrote: >> What I'm tempted to do is trying to document that, as a point of >> policy, parallel query in 9.6 uses up to (workers + 1) times the >> resources that a single session might

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Tue, Jun 21, 2016 at 9:58 AM, Tatsuo Ishii wrote: >>> Thanks, this looks good. Could you please add it to the next commitfest >>> so that it doesn't get lost and also so I can do an official review of it? >> >> Yes, I just did that. That's too late for 9.6 anyway with

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On 6/20/16 10:29 PM, Tom Lane wrote: What I would want to know is whether this specific change is actually a good idea. In particular, I'm concerned about the possible security implications of exposing primary_conninfo --- might it not contain a password, for example? That would have been my

Re: [HACKERS] ERROR: ORDER/GROUP BY expression not found in targetlist

Hi, I ran tpc-h's queries on this version and it's successful. The error is fixed. commit 705ad7f3b523acae0ddfdebd270b7048b2bb8029 Author: Tom Lane Date: Sun Jun 19 13:11:40 2016 -0400 Regards, Tatsuro Yamada NTT OSS Center On 2016/06/18 1:26, Robert Haas wrote: On

[HACKERS] Cleanup in contrib/postgres_fdw/deparse.c

Hi, Here is a small patch to remove an unnecessary return from deparseFromExprForRel in contrib/postgres_fdw/deparse.c. Best regards, Etsuro Fujita pg-fdw-deparse-cleanup.patch Description: application/download -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Parallelized polymorphic aggs, and aggtype vs aggoutputtype

On 18 June 2016 at 09:29, Tom Lane wrote: > So at this point my proposal is: > > 1. Add an OID-list field to Aggref holding the data types of the > user-supplied arguments. This can be filled in parse analysis since it > won't change thereafter. Replace calls to

Push down join with PHVs (WAS: Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116)

On 2016/06/17 21:45, Robert Haas wrote: On Thu, Jun 16, 2016 at 10:44 PM, Etsuro Fujita wrote: On 2016/06/16 22:00, Robert Haas wrote: On Thu, Jun 16, 2016 at 7:05 AM, Etsuro Fujita wrote: ISTM that a robuster solution to this is to

Re: [HACKERS] Should XLogInsert() be done only inside a critical section?

On 20/04/16 23:44, Tom Lane wrote: Over in <17456.1460832...@sss.pgh.pa.us> I speculated about whether we should be enforcing that WAL insertion happen only inside critical sections. We don't currently, and a survey of the backend says that there are quite a few calls that aren't inside

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 4:08 PM, Robert Haas wrote: > On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake > wrote: >> Or we could adopt the very reasonable and practical policy of: >> >> The current versioning scheme isn't broke, so we aren't going to

Re: [HACKERS] parallel.c is not marked as test covered

On Mon, Jun 20, 2016 at 4:52 PM, David G. Johnston wrote: > Internal or external I do think the number and type of flags described here, > for the purposes described, seems undesirable from an architectural > standpoint. Well, that seems like a bold statement to me,

Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 5:36 PM, David G. Johnston wrote: >> Yeah, no kidding. We had a perfectly good consensus to keep this at >> 9.6 on pgsql-advocacy, and then later we had a revised consensus to >> retitle it to 10.0, > > If -advocacy had changed their mind

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 20, 2016 at 4:24 PM, Andres Freund wrote: > On 2016-06-20 16:10:23 -0400, Robert Haas wrote: >> What exactly is the point of all of that already_marked stuff? > > Preventing the old tuple from being locked/updated by another backend, > while unlocking the buffer. >

Re: [HACKERS] Reviewing freeze map code

On 2016-06-20 17:55:19 -0400, Robert Haas wrote: > On Mon, Jun 20, 2016 at 4:24 PM, Andres Freund wrote: > > On 2016-06-20 16:10:23 -0400, Robert Haas wrote: > >> What exactly is the point of all of that already_marked stuff? > > > > Preventing the old tuple from being

Re: [HACKERS] 10.0

On 06/20/2016 02:14 PM, Merlin Moncure wrote: On Mon, Jun 20, 2016 at 4:08 PM, Robert Haas wrote: On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake wrote: Or we could adopt the very reasonable and practical policy of: The current versioning

  1   2   >