Re: [HACKERS] Documentation fixes for pg_visibility

On Thu, Jun 23, 2016 at 1:46 PM, Michael Paquier wrote: > On Thu, Jun 23, 2016 at 1:42 PM, Michael Paquier > wrote: >> While looking at the module I found two mistakes in the docs: >> pg_visibility_map and pg_visibility *not* taking in input

Re: [HACKERS] Documentation fixes for pg_visibility

On Thu, Jun 23, 2016 at 1:42 PM, Michael Paquier wrote: > While looking at the module I found two mistakes in the docs: > pg_visibility_map and pg_visibility *not* taking in input a block > number are SRFs, and return a set of records. The documentation is > just

[HACKERS] Documentation fixes for pg_visibility

Hi, While looking at the module I found two mistakes in the docs: pg_visibility_map and pg_visibility *not* taking in input a block number are SRFs, and return a set of records. The documentation is just listing them with "returns record". A patch is attached. Thanks, -- Michael

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

On 23 June 2016 at 11:22, Tom Lane wrote: > While working on that, I noticed what seems to me to be a minor bug. > The behavior that I'd expect (and that I documented) for a deserialization > function is that it just allocates its result in the current, short-lived > memory

Re: [HACKERS] Hash Indexes

On Wed, Jun 22, 2016 at 8:48 PM, Robert Haas wrote: > On Wed, Jun 22, 2016 at 5:14 AM, Amit Kapila wrote: >> We can do it in the way as you are suggesting, but there is another thing >> which we need to consider here. As of now, the patch tries to

Re: [HACKERS] Hash Indexes

On Wed, Jun 22, 2016 at 8:44 PM, Robert Haas wrote: > On Wed, Jun 22, 2016 at 5:10 AM, Amit Kapila wrote: >>> >>> I think this is basically correct, although I don't find it to be as >>> clear as I think it could be. It seems very clear that any

Re: [HACKERS] Questionabl description in datatype.sgml

On Sat, Jun 18, 2016 at 11:58:58AM -0400, Tom Lane wrote: > Tatsuo Ishii writes: > > In "8.13.2. Encoding Handling" > > > > When using binary mode to pass query parameters to the server > > and query results back to the client, no character set conversion > >

Re: [HACKERS] sslmode=require fallback

On Thu, Jun 16, 2016 at 10:42:56AM +0200, Magnus Hagander wrote: > However, if this is the expected behavior, the documentation at https:// > www.postgresql.org/docs/current/static/libpq-ssl.html should be updated to > make this more clear. It should be made clear that the existence of

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

David Rowley writes: > I've attached my proposed patch for the user defined aggregate docs. I whacked this around some more and pushed it. While working on that, I noticed what seems to me to be a minor bug. The behavior that I'd expect (and that I documented) for

Re: [HACKERS] how is the WAL receiver process stopped and restarted when the network connection is broken and then restored?

On 22 June 2016 at 23:52, Rui Hai Jiang wrote: > Hello, > > I have one Primary server and one Standby server. They are doing streaming > replication well. > > I did some testing. I broke the network connection between them for a few > minutes, and then restored the network. I

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

On 23 June 2016 at 08:53, Tom Lane wrote: > I wrote: >> David Rowley writes: >>> I've gone and implemented the dummy argument approach for >>> deserialization functions. > >> How do you feel about the further idea of locking down the signatures

Re: [HACKERS] MultiXactId error after upgrade to 9.3.4

Robert Haas wrote: > I see the patch, but I don't see much explanation of why the patch is > correct, which I think is pretty scary in view of the number of > mistakes we've already made in this area. The comments just say: > > + * A tuple that has HEAP_XMAX_IS_MULTI and HEAP_XMAX_LOCK_ONLY but

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

I wrote: > David Rowley writes: >> I've gone and implemented the dummy argument approach for >> deserialization functions. > How do you feel about the further idea of locking down the signatures > to be exactly "serialize(internal) returns bytea" and

Re: [HACKERS] Reference to UT1

On Mon, Jun 6, 2016 at 03:53:41PM +1200, Thomas Munro wrote: > Hi > > The manual[1] says "Technically,PostgreSQL uses UT1 rather than UTC > because leap seconds are not handled." I'm certainly no expert on > this stuff but it seems to me that we are using POSIX time[2] or Unix > time, not UT1.

Re: [HACKERS] Requesting external_pid_file with postgres -C when not initialized lead to coredump

alain radix writes: > Another effect of the patch is that it become possible to start a cluster > with external_pid_file='' in postgresql.conf > It would have that same behavior as many other parameters. I'd still be inclined to do that with something along the lines of -

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

David Rowley writes: > I've gone and implemented the dummy argument approach for > deserialization functions. How do you feel about the further idea of locking down the signatures to be exactly "serialize(internal) returns bytea" and "deserialize(bytea, internal)

Re: [HACKERS] Question and suggestion about application binary compatibility policy

On Mon, May 30, 2016 at 03:04:24AM +, Tsunakawa, Takayuki wrote: > Hello, > > I'd like to ask you about the policy of application binary compatibility. > And have a suggestion as well. > > QUESTION > == > > My customer asked me if the

Re: [HACKERS] Requesting external_pid_file with postgres -C when not initialized lead to coredump

Hi Tom, The actual fix do the job for preventing coredump. Effectively, reporting "" instead of (null) would be more consistent with the values found in pg_settings. Another effect of the patch is that it become possible to start a cluster with external_pid_file='' in postgresql.conf It would

[HACKERS] [HITB-Announce] HITB2016AMS Videos & GSEC Singapore Voting

Videos from the 7th annual HITB Security Conference are being released this week! HITBSecConf Youtube channel: http://youtube.com/hitbsecconf Talks from the #HITB2016AMS CommSec track have already been uploaded and linked to their individual presentations:

Re: [HACKERS] Precedence of new phrase search tsquery operator

Attached patch changes a precedences of operations to |, &, <->, | in ascending order. BTW, it simplifies a bit a code around printing and parsing of tsquery. |, &, <->, ! of course -- Teodor Sigaev E-mail: teo...@sigaev.ru

[HACKERS] how is the WAL receiver process stopped and restarted when the network connection is broken and then restored?

Hello, I have one Primary server and one Standby server. They are doing streaming replication well. I did some testing. I broke the network connection between them for a few minutes, and then restored the network. I found the both the WAL sender and WAL receiver were stopped and the restarted.

Re: [HACKERS] Requesting external_pid_file with postgres -C when not initialized lead to coredump

alain radix writes: > Here is a new patch with postmaster.c modification so that it check about a > empty string instead of a null pointer. Why should we adopt this, when there is already a better (more complete) fix in git? I'm not sold on the wisdom of modifying the

Re: [HACKERS] Hash Indexes

On Wed, Jun 22, 2016 at 5:14 AM, Amit Kapila wrote: > We can do it in the way as you are suggesting, but there is another thing > which we need to consider here. As of now, the patch tries to finish the > split if it finds split-in-progress flag in either old or new

Re: [HACKERS] Requesting external_pid_file with postgres -C when not initialized lead to coredump

Yes Michael, You're right, I aw this yesterday but couldn't make a patch. Here is a new patch with postmaster.c modification so that it check about a empty string instead of a null pointer. The meaning is no more to avoid a core dump as you've done a change for that but to have the same result

Re: [HACKERS] Hash Indexes

On Wed, Jun 22, 2016 at 5:10 AM, Amit Kapila wrote: >> > Insertion will happen by scanning the appropriate bucket and needs to >> > retain pin on primary bucket to ensure that concurrent split doesn't >> > happen, >> > otherwise split might leave this tuple unaccounted.

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On Wed, Jun 22, 2016 at 3:57 PM, Etsuro Fujita wrote: > On 2016/06/22 18:16, Ashutosh Bapat wrote: > >> On Wed, Jun 22, 2016 at 2:26 PM, Etsuro Fujita >> > wrote: >> > > I think we could address

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On 2016/06/22 18:16, Ashutosh Bapat wrote: On Wed, Jun 22, 2016 at 2:26 PM, Etsuro Fujita > wrote: I think we could address this in another way once we support deparsing subqueries; rewrite the remote query into

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On 2016/06/22 18:14, Ashutosh Bapat wrote: > I wonder whether such a whole-row-var would arise from the nullable side >> of a join? I guess not. Not that I'm saying we shouldn't account for that >> case at all since any and every whole-row-var in the targetlist currently >> gets that treatment,

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On Wed, Jun 22, 2016 at 2:26 PM, Etsuro Fujita wrote: > On 2016/06/22 17:11, Amit Langote wrote: > >> I wonder whether such a whole-row-var would arise from the nullable side >> of a join? I guess not. Not that I'm saying we shouldn't account for that >> case at all

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

I wonder whether such a whole-row-var would arise from the nullable side > of a join? I guess not. Not that I'm saying we shouldn't account for that > case at all since any and every whole-row-var in the targetlist currently > gets that treatment, even those that are known non-nullable. Couldn't

Re: [HACKERS] Hash Indexes

On Tue, Jun 21, 2016 at 9:33 PM, Robert Haas wrote: > > On Thu, Jun 16, 2016 at 3:28 AM, Amit Kapila wrote: > >> Incomplete splits can be completed either by vacuum or insert as both > >> needs exclusive lock on bucket. If vacuum finds

Re: [HACKERS] Hash Indexes

On Tue, Jun 21, 2016 at 9:26 PM, Robert Haas wrote: > > On Tue, May 10, 2016 at 8:09 AM, Amit Kapila wrote: > > > Once the split operation has set the split-in-progress flag, it will begin scanning bucket (N+1)/2. Every time it finds a tuple that

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On 2016/06/22 17:11, Amit Langote wrote: I wonder whether such a whole-row-var would arise from the nullable side of a join? I guess not. Not that I'm saying we shouldn't account for that case at all since any and every whole-row-var in the targetlist currently gets that treatment, even those

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On 2016/06/21 20:42, Ashutosh Bapat wrote: > On Tue, Jun 21, 2016 at 4:36 PM, Amit Langote wrote: >> On 2016/06/21 16:27, Rushabh Lathia wrote: >>> >>> And as above documentation clearly says that IS NULL and IS NOT NULL do >> not >>> always return inverse results for row-valued expressions. So