Michael Paquier writes:
> On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck
> wrote:
>> If I clean this up some, maintain styleguide, what is the likely hood of
>> getting this included in the redhat packages, since redhat ships a
On Wed, Jun 21, 2017 at 10:52:50PM -0700, Noah Misch wrote:
> On Thu, Jun 15, 2017 at 09:04:44AM +0100, Simon Riggs wrote:
> > On 15 June 2017 at 02:59, Noah Misch wrote:
> >
> > > Formally, the causative commit is the one that removed the superuser()
> > > test,
> > > namely
On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck
wrote:
> I've got a requirement for enabling FIPS support in our environment.
> Looking at postgresql's be-secure-openssl.c and mucking with it, it seems
> fairly straight forward to just add a few ifdefs and
On Fri, Jun 23, 2017 at 11:48 PM, Thomas Munro
wrote:
> Apply the patch after first applying a small bug fix for replication
> lag tracking[4]. Then:
That bug fix was committed, so now causal-reads-v17.patch can be
applied directly on top of master.
> 1. Set up
I've got a requirement for enabling FIPS support in our environment.
Looking at postgresql's be-secure-openssl.c and mucking with it, it seems
fairly straight forward to just add a few ifdefs and enable fips with a new
configure flag and a new postgresql.conf configuration setting.
If I clean
On Fri, Jun 23, 2017 at 8:18 PM, Bruce Momjian wrote:
> On Fri, Jun 23, 2017 at 08:10:17AM +0530, Amit Kapila wrote:
>> On Wed, Jun 21, 2017 at 10:03 PM, Bruce Momjian wrote:
>> > On Wed, Jun 21, 2017 at 07:49:21PM +0530, Amit Kapila wrote:
>> >> On Tue, Jun
On Fri, Jun 23, 2017 at 8:47 PM, Sergey Burladyan wrote:
> Bruce Momjian writes:
>
>> On Wed, Jun 21, 2017 at 07:49:21PM +0530, Amit Kapila wrote:
>> > On Tue, Jun 20, 2017 at 7:24 PM, Amit Kapila
>> > wrote:
>> > > Hmm. I think
On Thu, Jun 22, 2017 at 6:54 AM, Andres Freund wrote:
> On 2017-06-21 00:57:32 -0700, jasrajd wrote:
>> We are also seeing contention on the walwritelock and repeated writes to the
>> same offset if we move the flush outside the lock in the Azure environment.
>> pgbench
Peter Eisentraut writes:
> Do you want to take a look at move those elog calls around a bit? That
> should do it.
It would be a good idea to have some clarity on *why* that should do it.
Looking at the original report's log, but without having actually
On 6/21/17 22:47, Peter Eisentraut wrote:
> On 6/20/17 22:44, Noah Misch wrote:
>>> A patch has been posted, and it's being reviewed. Next update Monday.
>>
>> This PostgreSQL 10 open item is past due for your status update. Kindly send
>> a status update within 24 hours, and include a date for
On 6/22/17 03:26, Masahiko Sawada wrote:
> Thank you for the patch. Some comment and question.
> DropSubscriptionRelState requests ExclusiveLock but why is it not
> ShareRowExclusiveLock?
fixed
> I test DROP SUBSCIPTION case but even with this patch, "tuple
> concurrently updated" is still
On 6/23/17 16:15, Andres Freund wrote:
> On 2017-06-23 13:26:58 -0400, Alvaro Herrera wrote:
>> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have
>> some elog(DEBUG1) calls with the slot spinlock held. That's probably
>> uncool.
>
> It definitely is not cool, rather daft
Alvaro, all,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Yugo Nagata wrote:
>
> > I tried to make it. Patch attached.
> >
> > It is easy and simple. Although I haven't tried for autovacuum worker,
> > I confirmed I can change other process' parameters without affecting others.
> > Do
On 6/23/17 16:10, Peter Eisentraut wrote:
>> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have
>> some elog(DEBUG1) calls with the slot spinlock held. That's probably
>> uncool.
> Removing the call you pointed out doesn't make a difference, but it's
> possibly something
On Sat, Jun 24, 2017 at 6:07 AM, Simon Riggs wrote:
> On 23 June 2017 at 08:18, Simon Riggs wrote:
>> On 23 June 2017 at 06:45, Thomas Munro wrote:
>>
>>> I discovered a thinko in the new replication lag interpolation
Peter Geoghegan writes:
> On Fri, Jun 23, 2017 at 11:32 AM, Peter Eisentraut
> wrote:
>> 1) Associate by name only. That is, you can create a database with any
>> COLLATION "foo" that you want, and it's only checked when you first
>> connect to or
On Sat, Jun 24, 2017 at 5:07 AM, Alvaro Herrera
wrote:
> Yugo Nagata wrote:
>
>> I tried to make it. Patch attached.
>>
>> It is easy and simple. Although I haven't tried for autovacuum worker,
>> I confirmed I can change other process' parameters without affecting
On Fri, Jun 23, 2017 at 11:32 AM, Peter Eisentraut
wrote:
> It's something I hope to address soon.
I hope you do. I think that we'd realize significant benefits by
having ICU become the defacto standard collation provider, that most
users get without even
I wrote:
>> One question that I've got is why the ICU portion refuses to load
>> any entries unless is_encoding_supported_by_icu(GetDatabaseEncoding()).
>> Surely this is completely wrong? I should think that what we load into
>> pg_collation ought to be independent of template1's encoding, the
Peter Eisentraut writes:
> On 6/23/17 13:26, Alvaro Herrera wrote:
>> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have
>> some elog(DEBUG1) calls with the slot spinlock held. That's probably
>> uncool.
> I can reproduce the issue with
I wrote:
> One question that I've got is why the ICU portion refuses to load
> any entries unless is_encoding_supported_by_icu(GetDatabaseEncoding()).
> Surely this is completely wrong? I should think that what we load into
> pg_collation ought to be independent of template1's encoding, the same
On 2017-06-23 13:26:58 -0400, Alvaro Herrera wrote:
> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have
> some elog(DEBUG1) calls with the slot spinlock held. That's probably
> uncool.
It definitely is not cool, rather daft even (it's probably me who wrote
that). No idea
On 6/23/17 13:26, Alvaro Herrera wrote:
> Albe Laurenz wrote:
>> Peter Eisentraut wrote:
>>> On 6/21/17 09:02, Albe Laurenz wrote:
2017-06-21 14:55:12.033 CEST [23124] LOG: could not send data to client:
Broken pipe
2017-06-21 14:55:12.033 CEST [23124] FATAL: connection to client
Yugo Nagata wrote:
> I tried to make it. Patch attached.
>
> It is easy and simple. Although I haven't tried for autovacuum worker,
> I confirmed I can change other process' parameters without affecting others.
> Do you want this in PG?
One advantage of this gadget is that you can signal
Peter Eisentraut writes:
> We also allow the same column more than once in an index. We probably
> don't have to be more strict here.
There actually are valid uses for the same column more than once in
an index, eg if you use a different operator class for each
On 6/23/17 13:14, Alvaro Herrera wrote:
> Andres Freund wrote:
>> On 2017-06-23 13:05:21 -0400, Alvaro Herrera wrote:
>>> Tom Lane wrote:
Peter Eisentraut writes:
> Any thoughts about keeping datumAsEqual() as a first check? I did some
> light
On 6/23/17 11:15, Tatsuo Ishii wrote:
>> For clarity, I personally perfer to keep all the source text file
>> in the repository, especially so that we can detect changes of
>> them. But since we decide that at least most of them not to be
>> there (from a reason of license), I just don't see a
On 6/23/17 09:54, Tom Lane wrote:
>> However, I can use same expression more than once in partition key.
>
> ... and so, I can't get excited about extending it to expressions.
> Where would you stop --- for example, are i and (i) equal? What
> about (i) and (case when true then i else j end)?
On 6/23/17 06:11, sanyam jain wrote:
> I'm trying to create something like pg_recvlogical.c in java using
> pgjdbc.Its working for small transactions but when i do a big
> transaction client throws below exception:
What does the server log say? If nothing interesting, turn up debugging.
--
On 6/22/17 23:10, Peter Geoghegan wrote:
> On Thu, Jun 22, 2017 at 7:10 PM, Tom Lane wrote:
>> Is there some way I'm missing, or is this just a not-done-yet feature?
>
> It's a not-done-yet feature.
It's something I hope to address soon.
The main definitional challenge is
On 2017-06-23 19:21:57 +0100, Simon Riggs wrote:
> On 23 June 2017 at 08:23, Simon Riggs wrote:
> > On 23 June 2017 at 08:21, Andres Freund wrote:
> >> On 2017-06-07 10:17:31 -0700, Andres Freund wrote:
> >>> On 2017-05-08 09:12:13 -0400, Tom Lane
On 23 June 2017 at 08:23, Simon Riggs wrote:
> On 23 June 2017 at 08:21, Andres Freund wrote:
>> On 2017-06-07 10:17:31 -0700, Andres Freund wrote:
>>> On 2017-05-08 09:12:13 -0400, Tom Lane wrote:
>>> > Simon Riggs writes:
>>> >
On 23 June 2017 at 08:18, Simon Riggs wrote:
> On 23 June 2017 at 06:45, Thomas Munro wrote:
>
>> I discovered a thinko in the new replication lag interpolation code
>> that can cause a strange number to be reported occasionally.
>
> Thanks,
On Fri, Jun 23, 2017 at 12:31:40PM -0400, Tom Lane wrote:
> icu_to_uchar() and icu_from_uchar(), and perhaps other places, are
> touchingly naive about integer overflow hazards in buffer size
> calculations. I call particular attention to this bit in
> icu_from_uchar():
>
> len_result =
On 21 June 2017 at 15:18, Simon Riggs wrote:
> On 21 June 2017 at 16:15, Yugo Nagata wrote:
>> On Wed, 21 Jun 2017 19:08:35 +0530
>> Kuntal Ghosh wrote:
>>
>>> On Wed, Jun 21, 2017 at 6:05 PM, Yugo Nagata
Albe Laurenz wrote:
> Peter Eisentraut wrote:
> > On 6/21/17 09:02, Albe Laurenz wrote:
> >> 2017-06-21 14:55:12.033 CEST [23124] LOG: could not send data to client:
> >> Broken pipe
> >> 2017-06-21 14:55:12.033 CEST [23124] FATAL: connection to client lost
> >> 2017-06-21 14:55:17.032 CEST
Andres Freund wrote:
> On 2017-06-23 13:05:21 -0400, Alvaro Herrera wrote:
> > Tom Lane wrote:
> > > Peter Eisentraut writes:
> > > > Any thoughts about keeping datumAsEqual() as a first check? I did some
> > > > light performance tests, but it was inconclusive.
On 2017-06-23 13:05:21 -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Peter Eisentraut writes:
> > > Any thoughts about keeping datumAsEqual() as a first check? I did some
> > > light performance tests, but it was inconclusive.
> >
> > Seems like it would
Tom Lane wrote:
> Peter Eisentraut writes:
> > Any thoughts about keeping datumAsEqual() as a first check? I did some
> > light performance tests, but it was inconclusive.
>
> Seems like it would tend to be a win if, in fact, the values are
> usually equal. If
Masahiko Sawada wrote:
> On Fri, Jun 23, 2017 at 3:31 PM, Michael Paquier
> wrote:
> > On Fri, Jun 23, 2017 at 3:17 PM, Amit Langote
> > wrote:
> >> Initially, I had naively set wal_consistency_check = all before running
> >> make
icu_to_uchar() and icu_from_uchar(), and perhaps other places, are
touchingly naive about integer overflow hazards in buffer size
calculations. I call particular attention to this bit in
icu_from_uchar():
len_result = UCNV_GET_MAX_BYTES_FOR_STRING(len_uchar,
Sergey Burladyan writes:
> 1. create master
> 2. create standby from it
> 3. create unlogged table and hash index like:
> create unlogged table test (id int primary key, v text);
> create index on test using hash (id);
> 3. stop master
> 4. promote standby
>
> now, if you
Bruce Momjian writes:
> On Wed, Jun 21, 2017 at 07:49:21PM +0530, Amit Kapila wrote:
> > On Tue, Jun 20, 2017 at 7:24 PM, Amit Kapila
> > wrote:
> > > Hmm. I think we need something that works with lesser effort because
> > > not all users will be as
> For clarity, I personally perfer to keep all the source text file
> in the repository, especially so that we can detect changes of
> them. But since we decide that at least most of them not to be
> there (from a reason of license), I just don't see a reason to
> keep only the rest even without
On Fri, 23 Jun 2017 09:54:17 -0400
Tom Lane wrote:
> Yugo Nagata writes:
> > When we create a range partitioned table, we cannot use
> > a column more than once in the partition key.
>
> > postgres=# create table t (i int) partition by range(i,i);
> >
On Thu, 22 Jun 2017 14:08:30 +0900
Michael Paquier wrote:
> On Thu, Jun 22, 2017 at 1:52 PM, Yugo Nagata wrote:
> > On Thu, 22 Jun 2017 12:05:19 +0900
> > Michael Paquier wrote:
> >> signal-able). Different thought, but
On Fri, Jun 23, 2017 at 08:10:17AM +0530, Amit Kapila wrote:
> On Wed, Jun 21, 2017 at 10:03 PM, Bruce Momjian wrote:
> > On Wed, Jun 21, 2017 at 07:49:21PM +0530, Amit Kapila wrote:
> >> On Tue, Jun 20, 2017 at 7:24 PM, Amit Kapila
> >> wrote:
> >> >
Tomas Vondra writes:
> It would be really great if you could explain why BitmapScans are
> dubious, instead of just labeling them as dubious. (I guess you mean
> Bitmap Heap Scans, right?)
The two things I'm aware of are (a) the assumption you noted, that
fetching
Peter Eisentraut writes:
> Any thoughts about keeping datumAsEqual() as a first check? I did some
> light performance tests, but it was inconclusive.
Seems like it would tend to be a win if, in fact, the values are
usually equal. If they're usually not, then
Hi,
On 6/23/17 10:38 AM, Teodor Sigaev wrote:
1. Table AM with a 6-byte TID.
2. Table AM with a custom locator format, which could be TID-like.
3. Table AM with no locators.
Currently TID has its own type in system catalog. Seems, it's possible
that storage claims type of TID which it uses.
Yugo Nagata writes:
> When we create a range partitioned table, we cannot use
> a column more than once in the partition key.
> postgres=# create table t (i int) partition by range(i,i);
> ERROR: column "i" appears more than once in partition key
AFAIK, that's just a
> "Noah" == Noah Misch writes:
Noah> This PostgreSQL 10 open item is past due for your status update.
Noah> Kindly send a status update within 24 hours,
oops, sorry! I forgot to include a date in the last one, and in fact a
personal matter delayed things anyway. I
Hi all,
Per bug #14706, it has been discussed the possibility to remove the
transformation of opaque functions happening for example when
declaring a trigger:
https://www.postgresql.org/message-id/cab7npqtc-7u1k2vz3qlxvsyaxbvncrc9zmuvyf4-wuzj8zf...@mail.gmail.com
As far as I can see, the
On 6/20/17 00:10, Andres Freund wrote:
> On 2017-06-20 11:52:10 +0900, Tatsuo Ishii wrote:
>> If my understanding is correct, it would not be easy to fix, no?
>>
>>> We might be able to refine that, but there is a general problem that
>>> without an index and an operator class, we are just doing
On Wed, May 24, 2017 at 3:58 PM, Thomas Munro
wrote:
>> On Mon, May 22, 2017 at 4:10 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>>> I'm wondering about status of this patch and how can I try it out?
>
> I ran into a problem while doing this, and it may take a
On 06/23/2017 12:11 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 06/22/2017 10:24 AM, Tom Lane wrote:
>>> That earlier request is still valid. Also, if you can reproduce the
>>> symptom that lorikeet just showed and get a stack trace from the
>>>
Peter Eisentraut wrote:
> On 6/21/17 09:02, Albe Laurenz wrote:
>> 2017-06-21 14:55:12.033 CEST [23124] LOG: could not send data to client:
>> Broken pipe
>> 2017-06-21 14:55:12.033 CEST [23124] FATAL: connection to client lost
>> 2017-06-21 14:55:17.032 CEST [23133] LOG: logical replication
Hi,
I'm trying to create something like pg_recvlogical.c in java using pgjdbc.Its
working for small transactions but when i do a big transaction client throws
below exception:
org.postgresql.util.PSQLException: Database connection failed when reading from
copy
at
Thanks for the review again.
On 2017/06/22 19:55, Ashutosh Bapat wrote:
> On Thu, Jun 15, 2017 at 4:06 PM, Amit Langote
> wrote:
>>
>> Anyway, I tried to implement the refactoring in patch 0002, which is not
>> all of the patch 0001 that Jeevan posted. Please take
1. Table AM with a 6-byte TID.
2. Table AM with a custom locator format, which could be TID-like.
3. Table AM with no locators.
Currently TID has its own type in system catalog. Seems, it's possible that
storage claims type of TID which it uses. Then, AM could claim it too, so the
core based
> On 23 Jun 2017, at 00:08, Andres Freund wrote:
>
> Hi,
>
> At pgcon some people were talking about the difficulty of instrumenting
> the time actually spent waiting for lwlocks and related measurements.
> I'd mentioned that linux these days provides infrastructure to
On Fri, Jun 23, 2017 at 3:01 AM, Thomas Munro
wrote:
> On Thu, Jun 22, 2017 at 4:29 AM, Kuntal Ghosh
> wrote:
>> On Wed, Jun 21, 2017 at 7:52 PM, Dilip Kumar wrote:
>>> On Wed, Jun 21, 2017 at 7:47 PM, Kuntal
On Fri, Jun 23, 2017 at 3:25 PM, Michael Paquier
wrote:
> On Thu, Jun 22, 2017 at 6:10 AM, Andres Freund wrote:
>> We've not heard any complaints about this afaik, but it's not something
>> that's easily diagnosable as being a problem. Therefore I
On 23 June 2017 at 08:01, Ashutosh Bapat
wrote:
> The way we have designed our syntax, we don't have a way to tell that
> p3 comes after p2 and they have no gap between those. But I don't
> think that's your question. What you are struggling with is a way to
>
On Fri, Jun 23, 2017 at 3:31 PM, Michael Paquier
wrote:
> On Fri, Jun 23, 2017 at 3:17 PM, Amit Langote
> wrote:
>> Initially, I had naively set wal_consistency_check = all before running
>> make installcheck and then had to wait for a
On 23 June 2017 at 08:21, Andres Freund wrote:
> On 2017-06-07 10:17:31 -0700, Andres Freund wrote:
>> On 2017-05-08 09:12:13 -0400, Tom Lane wrote:
>> > Simon Riggs writes:
>> > > So rearranged code a little to keep it lean.
>> >
>> > Didn't you break
On 2017-06-07 10:17:31 -0700, Andres Freund wrote:
> On 2017-05-08 09:12:13 -0400, Tom Lane wrote:
> > Simon Riggs writes:
> > > So rearranged code a little to keep it lean.
> >
> > Didn't you break it with that? As it now stands, the memcpy will
> > copy the nonzero
On 23 June 2017 at 06:45, Thomas Munro wrote:
> I discovered a thinko in the new replication lag interpolation code
> that can cause a strange number to be reported occasionally.
Thanks, will review.
--
Simon Riggshttp://www.2ndQuadrant.com/
On Fri, 23 Jun 2017 15:57:54 +0900
Yugo Nagata wrote:
> Hi,
>
> When we create a range partitioned table, we cannot use
> a column more than once in the partition key.
>
> postgres=# create table t (i int) partition by range(i,i);
> ERROR: column "i" appears more than
On Fri, Jun 23, 2017 at 6:58 AM, Amit Langote
wrote:
> On 2017/06/22 20:48, amul sul wrote:
>> Hi,
>>
>> While working on the another patch, I came across the case where
>> I need an auto generated partition for a mutil-column range partitioned
>> table having
Hi,
When we create a range partitioned table, we cannot use
a column more than once in the partition key.
postgres=# create table t (i int) partition by range(i,i);
ERROR: column "i" appears more than once in partition key
However, I can use same expression more than once in partition key.
On Fri, Jun 23, 2017 at 2:58 AM, Alvaro Herrera
wrote:
> Ashutosh Bapat wrote:
>> On Mon, Jun 5, 2017 at 8:22 AM, atorikoshi
>> wrote:
>> > Hi,
>> >
>> > I found below formula to compute selectivities, but
>> > I think the last
On 2017/06/23 6:28, Alvaro Herrera wrote:
Ashutosh Bapat wrote:
On Mon, Jun 5, 2017 at 8:22 AM, atorikoshi
wrote:
Hi,
I found below formula to compute selectivities, but
I think the last Probability 'P(b=?)' should be 'P(c=?)'.
P(a=?,b=?,c=?) =
On Fri, Jun 23, 2017 at 3:17 PM, Amit Langote
wrote:
> Initially, I had naively set wal_consistency_check = all before running
> make installcheck and then had to wait for a long time to confirm that WAL
> generated by the gin test indeed caused consistency check
On Thu, Jun 22, 2017 at 6:10 AM, Andres Freund wrote:
> We've not heard any complaints about this afaik, but it's not something
> that's easily diagnosable as being a problem. Therefore I suspect we
> should fix and backpatch this?
Agreed. I have just poked at this problem
On 2017/06/23 15:07, Michael Paquier wrote:
> On Fri, Jun 23, 2017 at 2:56 PM, Masahiko Sawada
> wrote:
>> Thank you for updating the patch. It looks good to me.
>> BTW I'm inclined to have a regression test case where doing 'make
>> check' to the streaming replication
On Fri, Jun 23, 2017 at 2:56 PM, Masahiko Sawada wrote:
> Thank you for updating the patch. It looks good to me.
> BTW I'm inclined to have a regression test case where doing 'make
> check' to the streaming replication environment with
> wal_consistency_check on standby
On 2017/06/23 13:42, amul sul wrote:
> On Fri, Jun 23, 2017 at 6:58 AM, Amit Langote wrote:
>> On 2017/06/22 20:48, amul sul wrote:
>>> This happened because of UNBOUNDED handling, where it is a negative infinite
>>> if it is in FROM clause. Wondering can't we explicitly treat this as
>>> a
78 matches
Mail list logo