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)
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
-
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
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
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.
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
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
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
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
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
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
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,
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
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
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.
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
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
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:
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
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
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
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
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
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
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
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
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.
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
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
> >
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
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
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
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
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
34 matches
Mail list logo