On Thu, Jun 23, 2016 at 3:50 PM, Michael Paquier
wrote:
> On Wed, Jun 15, 2016 at 4:52 PM, Kyotaro HORIGUCHI
> wrote:
>> Hello,
>
> Sorry for the late reply, Horiguchi-san. I have finally been able to
> put some mind power into that.
>
>> This is somewhat artificial but the same situation could b
On Wed, Jun 15, 2016 at 4:52 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
Sorry for the late reply, Horiguchi-san. I have finally been able to
put some mind power into that.
> This is somewhat artificial but the same situation could be made
> also in the nature. The exact condition for this is replayin
> From: Bruce Momjian [mailto:br...@momjian.us]
> We have this text in src/tools/RELEASE_CHANGES:
> ...
> This is saying running against a mismatched minor version should be fine
> for a binary.
Thanks for a good rationale.
> I know this thread is old but it bounced around a lot of ideas. I thi
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 a block
>> number are SRFs, and return a set of records
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 listing them with "returns record"
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
docs-visibility
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 context, since it will
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 finish the
>> split if it finds split-in-progres
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 operation
>>> which potentially changes the order
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
> > is performed, so the s
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
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 a deserialization
function is t
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 found the both the
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
>> to be exactly "serialize(internal) returns bytea"
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
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 "deserialize(bytea,
> internal) returns intern
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.
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
- if (external_pid_
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) returns internal", and removing p
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 followi
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 hav
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:
http://conference.hitb.org/hitbsecconf
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
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.
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 semantics of
external_pid_f
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 bucket. We
> need to lock bot
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 w
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.
>>
>> What do you mean by
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
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>
> I think we could address this in another way once we support
>> deparsing subqueries
On 2016/06/22 18:16, Ashutosh Bapat wrote:
On Wed, Jun 22, 2016 at 2:26 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
I think we could address this in another way once we support
deparsing subqueries; rewrite the remote query into something that
wouldn't need the CA
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, ev
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 since any and every whole-row
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 w
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 split-in-progress
flag on a
> >> bucket then it will complet
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 properly
belongs in bucket N+1, it will insert th
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 th
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 nee
37 matches
Mail list logo
