On Thu, Jul 20, 2017 at 3:13 PM, Julien Rouhaud wrote:
> On Thu, Jul 20, 2017 at 5:44 AM, Peter Geoghegan wrote:
>> On Wed, Jul 19, 2017 at 8:33 PM, Craig Ringer wrote:
>>> That's silly, so here's a patch to teach pageinspect how to decode infomasks
>>> to a human readable array of flag names.
>
Finally, I added new TAP test library PsqlSession.
At Tue, 18 Jul 2017 18:12:13 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170718.181213.206979369.horiguchi.kyot...@lab.ntt.co.jp>
> > * How about some regression test cases? You couldn't really exercise
> > cross-session invalid
On Thu, Jul 20, 2017 at 12:30 AM, Robert Haas wrote:
>
>> This suggests that partitioning is not a suitable strategy for this query,
>> but then may be partition wise should not be picked for such a case to
>> aggravate the performance issue.
>
> In the unpartitioned case, and in the partitioned c
On Fri, Jul 7, 2017 at 9:33 AM, Michael Paquier
wrote:
> On Fri, Jul 7, 2017 at 4:31 PM, Kuntal Ghosh
> wrote:
>> On Fri, Jul 7, 2017 at 7:49 AM, Michael Paquier
>> wrote:
>> I don't have any more inputs on this patch and it looks good to me.
>> So, I'm moving the status to ready for committer.
On 2017/07/20 15:05, Ashutosh Bapat wrote:
> On Wed, Jul 19, 2017 at 9:54 AM, Rafia Sabih
> wrote:
>>
>> Partition information:
>> Type of partitioning - single column range partition
>> Tables partitioned - Lineitem and orders
>>
>> Lineitem -
>> Partition key = l_orderkey
>> No of partitions = 1
On Thu, Jul 20, 2017 at 5:44 AM, Peter Geoghegan wrote:
> On Wed, Jul 19, 2017 at 8:33 PM, Craig Ringer wrote:
>> That's silly, so here's a patch to teach pageinspect how to decode infomasks
>> to a human readable array of flag names.
>>
>> Example:
>>
>> SELECT t_infomask, t_infomask2, flags
>>
On 2017-07-20 05:52, Masahiko Sawada wrote:
On Thu, Jul 20, 2017 at 8:24 AM, Stephen Frost
wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
"Joshua D. Drake" writes:
> At PGConf US Philly last week I was talking with Jim and Jan about
> performance. One of the items that came up is that PostgreS
On Wed, Jul 19, 2017 at 9:54 AM, Rafia Sabih
wrote:
>
> Partition information:
> Type of partitioning - single column range partition
> Tables partitioned - Lineitem and orders
>
> Lineitem -
> Partition key = l_orderkey
> No of partitions = 18
>
> Orders -
> Partition key = o_orderkey
> No of par
>
> On 19 July 2017 at 20:26, Neha Sharma
> wrote:
>
>> Hi,
>>
>> I am getting FailedAssertion while executing the attached
>> script.However,I am not able to produce the core dump for the same,the
>> script runs in background and takes around a day time to produce the
>> mentioned error.
>>
>> "T
On Fri, Jun 2, 2017 at 4:16 AM, Tom Lane wrote:
> I don't think it does really. The thing about a <> semijoin is that it
> will succeed unless *every* join key value from the inner query is equal
> to the outer key value (or is null). That's something we should consider
> to be of very low proba
On 19 July 2017 at 20:26, Neha Sharma wrote:
> Hi,
>
> I am getting FailedAssertion while executing the attached script.However,I
> am not able to produce the core dump for the same,the script runs in
> background and takes around a day time to produce the mentioned error.
>
> "TRAP: FailedAssert
On 19 July 2017 at 16:34, Tatsuo Ishii wrote:
> Now that we are going to have logical replication in PostgreSQL 10, I
> have started thinking how Pgpool-II can deal with it. For example, the
> logical replication does not replicate DDLs. Isn't it convenient for
> users to do it automatically in P
On 20/07/2017 04:24, Tom Lane wrote:
> I wrote:
>> Ah. I don't feel like trawling the archives for the discussion right now,
>> but I believe this was an intentional change to make the behavior more
>> consistent.
>
> Oh ... a quick look in the commit log finds the relevant discussion:
> https://
On Wed, Jul 19, 2017 at 8:33 PM, Craig Ringer wrote:
> That's silly, so here's a patch to teach pageinspect how to decode infomasks
> to a human readable array of flag names.
>
> Example:
>
> SELECT t_infomask, t_infomask2, flags
> FROM heap_page_items(get_raw_page('test1', 0)),
> LATERAL hea
On 20 July 2017 at 11:33, Craig Ringer wrote:
> Hi
>
> Whenever I'm debugging some kind of corruption incident, possible
> visibility bug, etc, I always land up staring at integer infomasks or using
> a SQL helper function to decode them.
>
> That's silly, so here's a patch to teach pageinspect h
Hi
Whenever I'm debugging some kind of corruption incident, possible
visibility bug, etc, I always land up staring at integer infomasks or using
a SQL helper function to decode them.
That's silly, so here's a patch to teach pageinspect how to decode
infomasks to a human readable array of flag nam
On Thu, Jul 20, 2017 at 2:02 PM, Robert Haas wrote:
> On Wed, Jul 19, 2017 at 7:45 PM, Thomas Munro
> wrote:
>> Isn't this the same as the issue reported here?
>>
>> https://www.postgresql.org/message-id/flat/CAEepm%3D270ze2hVxWkJw-5eKzc3AB4C9KpH3L2kih75R5pdSogg%40mail.gmail.com
>
> Hmm, possibly
On Wed, Jul 19, 2017 at 7:57 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> My argument for the importance of index bloat to the more general
>> bloat problem is simple: any bloat that accumulates, that cannot be
>> cleaned up, will probably accumulate until it impacts performance
>> quite noti
Peter Geoghegan writes:
> My argument for the importance of index bloat to the more general
> bloat problem is simple: any bloat that accumulates, that cannot be
> cleaned up, will probably accumulate until it impacts performance
> quite noticeably.
But that just begs the question: *does* it accu
On Thu, Jul 20, 2017 at 8:24 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> "Joshua D. Drake" writes:
>> > At PGConf US Philly last week I was talking with Jim and Jan about
>> > performance. One of the items that came up is that PostgreSQL can't run
>> > full throttle for l
On 2017/07/19 23:36, Tom Lane wrote:
Etsuro Fujita writes:
* Modified rewrite_targetlist(), which is a new function added to
preptlist.c, so that we do const-simplification to junk TLEs that
AddForeignUpdateTargets() added, as that API allows the FDW to add junk
TLEs containing non-Var expressi
I wrote:
> Ah. I don't feel like trawling the archives for the discussion right now,
> but I believe this was an intentional change to make the behavior more
> consistent.
Oh ... a quick look in the commit log finds the relevant discussion:
https://www.postgresql.org/message-id/flat/9b4ea968-753f
On Wed, Jul 19, 2017 at 3:54 PM, Alvaro Herrera
wrote:
>> Index bloat is a general problem that B-Trees have in all other major
>> systems, but I think that PostgreSQL has a tendency to allow indexes
>> to become progressively more bloated over time, in a way that it often
>> can never recover fro
Julien Rouhaud writes:
> On 20/07/2017 03:34, Tom Lane wrote:
>> Works for me. Please describe exactly what misbehavior you're seeing.
> Here's a simple test case, last \p still show the query buffer:
Ah. I don't feel like trawling the archives for the discussion right now,
but I believe this
On Wed, Jul 19, 2017 at 7:45 PM, Thomas Munro
wrote:
> On Thu, Jul 20, 2017 at 7:00 AM, Robert Haas wrote:
>> I think the problem is that the row count estimates for the child
>> joins seem to be totally bogus:
>>
>> -> Hash Semi Join (cost=309300.53..491665.60 rows=1 width=12)
>> (actual time=
On 20/07/2017 03:34, Tom Lane wrote:
> Julien Rouhaud writes:
>> Unless I miss something, \r isn't working anymore,
>
> Works for me. Please describe exactly what misbehavior you're seeing.
> What libreadline or libedit version are you using?
>
I have libreadline 7.0_p3.
Here's a simple test
Julien Rouhaud writes:
> Unless I miss something, \r isn't working anymore,
Works for me. Please describe exactly what misbehavior you're seeing.
What libreadline or libedit version are you using?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Hello,
Unless I miss something, \r isn't working anymore, since
exec_command_print() fallback to display previous_buf if query_buf has
been freed.
Trivial patch to fix issue (free both buffers in exec_command_reset())
attached.
Regards.
--
Julien Rouhaud
diff --git a/src/bin/psql/command.c b/s
On Thu, Jul 20, 2017 at 7:00 AM, Robert Haas wrote:
> I think the problem is that the row count estimates for the child
> joins seem to be totally bogus:
>
> -> Hash Semi Join (cost=309300.53..491665.60 rows=1 width=12)
> (actual time=10484.422..15945.851 rows=1523493 loops=3)
> Hash Cond: (l1
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> "Joshua D. Drake" writes:
> > At PGConf US Philly last week I was talking with Jim and Jan about
> > performance. One of the items that came up is that PostgreSQL can't run
> > full throttle for long periods of time. The long and short is that no
> > mat
On Tue, Jul 18, 2017 at 12:49 PM, David Fetter wrote:
> On Tue, Jul 18, 2017 at 01:36:32PM +0200, david.tu...@linuxbox.cz wrote:
>> Hi,
>>
>> some users and me used hstore - hstore for example storing only changed
>> rows in trigger like:
>>
>> hsore(NEW) - hstore(OLD)
>>
>> There isn't same opera
On 07/19/2017 03:29 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> At PGConf US Philly last week I was talking with Jim and Jan about
>> performance. One of the items that came up is that PostgreSQL can't run
>> full throttle for long periods of time. The long and short is that no
>> matter
Peter Geoghegan wrote:
> Index bloat is a general problem that B-Trees have in all other major
> systems, but I think that PostgreSQL has a tendency to allow indexes
> to become progressively more bloated over time, in a way that it often
> can never recover from [1].
Interesting assertion. Many
"Joshua D. Drake" writes:
> At PGConf US Philly last week I was talking with Jim and Jan about
> performance. One of the items that came up is that PostgreSQL can't run
> full throttle for long periods of time. The long and short is that no
> matter what, autovacuum can't keep up. This is what
On Wed, Jul 19, 2017 at 3:11 PM, Joshua D. Drake wrote:
> The good news is, PostgreSQL is not doing half bad against 128 connections
> with only 16vCPU. The bad news is we more than doubled our disk size without
> getting reuse or bloat under control. The concern here is that under heavy
> write l
Hello,
At PGConf US Philly last week I was talking with Jim and Jan about
performance. One of the items that came up is that PostgreSQL can't run
full throttle for long periods of time. The long and short is that no
matter what, autovacuum can't keep up. This is what I have done:
Machine:
1
On 14/07/17 13:29, Michael Paquier wrote:
On Fri, Jul 14, 2017 at 12:16 PM, Álvaro Hernández Tortosa
wrote:
If the parameter authmethod would rather be "authmethods", i.e., a list,
I think it would be significantly more flexible.
Yes, but the handling of a list becomes messier if there
Ashutosh Sharma writes:
> Here are the list of macros and variables from 'intrpvar.h' file that
> are just defined in perl module but not in plperl on Windows,
> #ifdef PERL_USES_PL_PIDSTATUS
> PERLVAR(I, pidstatus, HV *) /* pid-to-status mappings for waitpid */
> #endif
> #ifdef PERL_SA
On Wed, Jul 19, 2017 at 10:08 PM, Alvaro Herrera
wrote:
> So let's step back a bit,
> get a patch that works for the case where the types match on both sides
> of the FK, then we review that patch; if all is well, we can discuss the
> other problem as a stretch goal.
Agreed. This should be a fu
Alik Khilazhev is submitting a patch about a zipfian random function
for pgbench, and noticed a typo in the documentation about
random_exponential.
Attached is a fix extracted from his patch submission, which could be
applied to head/10/9.6.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.s
Michael Paquier writes:
> On Wed, Jul 19, 2017 at 8:56 PM, Tom Lane wrote:
>> I wonder if it'd be worth the trouble to stick something like this into
>> xlog.c:
>> StaticAssertStmt(sizeof(ControlFileData) <= 512,
>> "pg_control is too large for atomic disk writes");
> +1. Even if it just gets tr
Mark Rofail wrote:
> On Tue, Jul 18, 2017 at 11:14 PM, Alvaro Herrera
> wrote:
> >
> > Why did we add an operator and not a support
> > procedure?
>
> I thought the support procedures were constant within an opclass.
Uhh ... I apologize but I think I was barking at the wrong tree. I was
thinkin
Robert Haas wrote:
> On Wed, Jul 19, 2017 at 8:26 AM, Neha Sharma
> wrote:
> > I am getting FailedAssertion while executing the attached script.However,I
> > am not able to produce the core dump for the same,the script runs in
> > background and takes around a day time to produce the mentioned err
On Tue, Jul 18, 2017 at 2:26 AM, Vik Fearing
wrote:
> On 07/07/2017 02:02 AM, Mark Kirkwood wrote:
>> I'd prefer *not* to see a table and its partitions all intermixed in the
>> same display (especially with nothing indicating which are partitions) -
>> as this will make for unwieldy long lists wh
On Wed, Jul 19, 2017 at 3:26 PM, Mark Dilger wrote:
>> Typically, when you try to store an out-of-range value in PostgreSQL,
>> you get an ERROR, and that's one of the selling points of PostgreSQL.
>> PostgreSQL users regularly beat up other projects for, say, allowing
>> -00-00 to be consider
> On Jul 19, 2017, at 9:53 AM, Robert Haas wrote:
>
> On Mon, Jul 17, 2017 at 6:12 PM, Tom Lane wrote:
>> So, thinking about how that would actually work ... the thing to do in
>> order to preserve existing on-disk values is to alternate between signed
>> and unsigned interpretations of abstime
> On Jul 19, 2017, at 10:23 AM, Robert Haas wrote:
>
> On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane wrote:
>>> Doesn't this plan amount to breaking pg_upgrade compatibility and
>>> hoping that nobody notice?
>>
>> Well, what we'd need to do is document that the type is only meant to be
>> used to
On 20 July 2017 at 05:08, Michael Paquier wrote:
> On Wed, Jul 19, 2017 at 8:59 PM,
>
> Fabrízio de Royes Mello
> > You should add the properly sgml docs for this pg_dumpall change also.
>
> Tests of pg_dump go to src/bin/pg_dump/t/ and tests for objects in
> extensions are in src/test/modules
On Sun, Jul 16, 2017 at 7:23 PM, Stephen Frost wrote:
>> Refusing to improve LDAP for the users who have no choice seems like a very
>> unfriendly thing to do.
>
> I'm fine with improving LDAP in general, but, as I tried to point out,
> having a way to make it easier to integrate PG into an AD env
On Wed, Jul 19, 2017 at 8:59 PM, Fabrízio de Royes Mello
wrote:
> On Wed, Jul 19, 2017 at 3:54 PM, Robins Tharakan wrote:
>> You may want to consider this patch (attached) which additionally has the
>> pg_dumpall changes.
>> It would be great if you could help with the tests though, am unsure how
On Wed, Jul 19, 2017 at 8:56 PM, Tom Lane wrote:
> I wonder if it'd be worth the trouble to stick something like this into
> xlog.c:
>
> /*
> * For reliability's sake, it's critical that pg_control updates
> * be atomic writes. That generally means the active data can't
On Wed, Jul 19, 2017 at 2:29 PM, Mark Rofail wrote:
> On Wed, Jul 19, 2017 at 7:28 PM, Robert Haas wrote:
>>
>> Why do we have to solve that limitation?
>
> Since the regress test labled element_foreing_key fails now that I made the
> RI queries utilise @(anyarray, anyelement), that means it's no
On Wed, Jul 19, 2017 at 12:24 AM, Rafia Sabih
wrote:
> On testing this patch for TPC-H (for scale factor 20) benchmark I found a
> regression for Q21, on head it was taking some 600 seconds and with this
> patch it is taking 3200 seconds. This comparison is on the same partitioned
> database, one
On Wed, Jul 19, 2017 at 3:54 PM, Robins Tharakan wrote:
>
>
> On 18 July 2017 at 23:55, David Fetter wrote:
>>
>> Excellent point about pg_dumpall. I'll see what I can draft up in the
>> next day or two and report back.
>
>
>
> Hi David,
>
> You may want to consider this patch (attached) which a
I wrote:
> Hm. Currently sizeof(struct ControlFileData) = 296, at least on my
> machine. Letting it grow past 512 would be problematic. It's hard
> to see getting to that any time soon, though; we don't add fields
> there often.
I wonder if it'd be worth the trouble to stick something like this
On 18 July 2017 at 23:55, David Fetter wrote:
>
> Excellent point about pg_dumpall. I'll see what I can draft up in the
> next day or two and report back.
Hi David,
You may want to consider this patch (attached) which additionally has the
pg_dumpall changes.
It would be great if you could he
On Wed, Jul 19, 2017 at 10:56 AM, Robert Haas wrote:
>> I strongly agree. I simply don't understand how you can adopt UNDO for
>> MVCC, and yet expect to get a benefit commensurate with the effort
>> without also implementing "retail index tuple deletion" first.
>
> I agree that we need retail ind
Robert Haas writes:
> On Wed, Jul 19, 2017 at 1:35 PM, Tom Lane wrote:
>> Alternatively, we could turn the origin point for abstime into
>> pg_control field, and regard changing it as a reason for a database
>> not being pg_upgrade'able unless it lacks any abstime columns.
> I would be OK with t
On Wed, Jul 19, 2017 at 7:28 PM, Robert Haas wrote:
> Why do we have to solve that limitation?
Since the regress test labled element_foreing_key fails now that I made the
RI queries utilise @(anyarray, anyelement), that means it's not functioning
as it is meant to be.
On Wed, Jul 19, 2017 at 8:05 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Wed, Jul 19, 2017 at 7:00 PM, Robert Haas wrote:
>>> It's interesting that you bring this up. I've also wondered why we
>>> don't use random TLIs. I suppose I'm internally assuming that it's
>>> because the people
On Wed, Jul 19, 2017 at 1:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane wrote:
>>> I'd definitely be on board with just dropping the type altogether despite
>>> Mark's concern.
>
>> Then I vote for that option.
>
> BTW, another possible compromise is t
Justin Pryzby writes:
> ts=# begin; UPDATE eric_enodeb_201707 SET
> (pmhdelayvarbest50pct,pmlicconnecteduserstimecong)=(0,0) ;
> BEGIN
> UPDATE 3
> ts=# begin; UPDATE eric_enodeb_201707 SET (pmhdelayvarbest50pct)=(0) ;
> BEGIN
> ERROR: source for a multiple-column UPDATE item must be a sub-SELEC
Ashutosh Sharma writes:
> On Wed, Jul 19, 2017 at 9:42 PM, Tom Lane wrote:
>> I imagine the route to a solution is to fix things so that the relevant
>> macros are all defined correctly in both cases. But why they aren't
>> already is certainly an interesting question. Have you identified just
Michael Paquier writes:
> On Wed, Jul 19, 2017 at 7:00 PM, Robert Haas wrote:
>> It's interesting that you bring this up. I've also wondered why we
>> don't use random TLIs. I suppose I'm internally assuming that it's
>> because the people who wrote the code are far more brilliant and
>> knowle
On Sat, Jul 15, 2017 at 8:58 PM, Peter Geoghegan wrote:
> To repeat myself, for emphasis: *Not all bloat is equal*.
+1.
> I strongly agree. I simply don't understand how you can adopt UNDO for
> MVCC, and yet expect to get a benefit commensurate with the effort
> without also implementing "retai
On Sat, Jul 15, 2017 at 6:36 PM, Alexander Korotkov
wrote:
> I think in general there are two ways dealing with out index AM API
> limitation. One of them is to extend index AM API.
That's pretty much what I have in mind. I think it's likely that if
we end up with, say, 3 kinds of heap and 12 k
In testing our application with PG10beta2, I discovered that our use of UPDATE
broke, apparently by this commit
|commit 906bfcad7ba7cb3863fe0e2a7810be8e3cd84fbd
|Author: Tom Lane
|Date: Tue Nov 22 15:19:57 2016 -0500
|
|Improve handling of "UPDATE ... SET (column_list) = row_constructor".
On Wed, Jul 19, 2017 at 9:42 PM, Tom Lane wrote:
>
> Ashutosh Sharma writes:
> > Actually the function used for generation of handshake Key i.e HS_KEYp()
> > considers 'sizeof(PerlInterpreter)' to generate the key and somehow the
> > sizeof PerlInterpreter is not uniform in plperl and perl module
On Wed, Jul 19, 2017 at 7:00 PM, Robert Haas wrote:
> On Wed, Jul 19, 2017 at 11:23 AM, Brian Faherty
> wrote:
>> I was working with replication and recovery the other day and noticed that
>> there were scenarios where I could cause multiple servers to enter the same
>> timeline while possibly
Robert Haas writes:
> On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane wrote:
>> I'd definitely be on board with just dropping the type altogether despite
>> Mark's concern.
> Then I vote for that option.
BTW, another possible compromise is to move abstime into a contrib
module; we've always accepted
On Wed, Jul 19, 2017 at 2:25 AM, Michael Paquier
wrote:
> Would we want to improve the error handling of such objects?
+1 for such an improvement.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Wed, Jul 19, 2017 at 8:08 AM, Mark Rofail wrote:
> To summarise, the options we have to solve the limitation of the @>(anyarray
> , anyelement) where it produces the following error: operator does not
> exist: integer[] @> smallint
Why do we have to solve that limitation?
--
Robert Haas
Ente
On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane wrote:
>> Doesn't this plan amount to breaking pg_upgrade compatibility and
>> hoping that nobody notice?
>
> Well, what we'd need to do is document that the type is only meant to be
> used to store dates within say +/- 30 years from current time. As long
On Wed, Jul 19, 2017 at 01:12:02PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jul 17, 2017 at 6:12 PM, Tom Lane wrote:
> >> So, thinking about how that would actually work ... the thing to do in
> >> order to preserve existing on-disk values is to alternate between signed
> >> and u
Robert Haas writes:
> On Mon, Jul 17, 2017 at 6:12 PM, Tom Lane wrote:
>> So, thinking about how that would actually work ... the thing to do in
>> order to preserve existing on-disk values is to alternate between signed
>> and unsigned interpretations of abstimes. That is, right now, abstime
>>
On Wed, Jul 19, 2017 at 8:26 AM, Neha Sharma
wrote:
> I am getting FailedAssertion while executing the attached script.However,I
> am not able to produce the core dump for the same,the script runs in
> background and takes around a day time to produce the mentioned error.
Maybe you should run it
On Wed, Jul 19, 2017 at 11:23 AM, Brian Faherty
wrote:
> Hey hackers,
> I was working with replication and recovery the other day and noticed that
> there were scenarios where I could cause multiple servers to enter the same
> timeline while possibly having divergent data. One such scenario is M
On Wed, Jul 19, 2017 at 12:43 PM, Victor Drobny wrote:
> Let me introduce new function for full text search query creation(which is
> called 'queryto_tsquery'). It takes 'google like' query string and
> translates it to tsquery.
I haven't looked at the code, but that sounds like a neat idea.
--
On Wed, Jul 19, 2017 at 12:12 PM, Tom Lane wrote:
> Ashutosh Sharma writes:
>> Actually the function used for generation of handshake Key i.e HS_KEYp()
>> considers 'sizeof(PerlInterpreter)' to generate the key and somehow the
>> sizeof PerlInterpreter is not uniform in plperl and perl modules in
On Mon, Jul 17, 2017 at 6:12 PM, Tom Lane wrote:
> So, thinking about how that would actually work ... the thing to do in
> order to preserve existing on-disk values is to alternate between signed
> and unsigned interpretations of abstimes. That is, right now, abstime
> is signed with origin 1970
Dear all,
Now Postgres has a few functions to create tsqueries for full text
search. The main one is the to_tsquery function that allows to make
query with any operation. But to make correct query all of the operators
should be specified explicitly. In order to make it easier postgres has
fun
Justin Pryzby writes:
> FYI, I happened across this commit comment:
> 3f902354b08ac788600f0ae54fcbfc1d4e3ea765
> | So, let's accept the removal of the guarantee about
> | the output tuple's rowtype marking, recognizing that this is a API change
> | that could conceivably break third-party ca
FYI, I happened across this commit comment:
3f902354b08ac788600f0ae54fcbfc1d4e3ea765
| So, let's accept the removal of the guarantee about
| the output tuple's rowtype marking, recognizing that this is a API change
| that could conceivably break third-party callers of tupconvert.c. (So,
|
Ashutosh Sharma writes:
> Actually the function used for generation of handshake Key i.e HS_KEYp()
> considers 'sizeof(PerlInterpreter)' to generate the key and somehow the
> sizeof PerlInterpreter is not uniform in plperl and perl modules incase of
> Windows but on Linux it remains same in both t
Hey hackers,
I was working with replication and recovery the other day and noticed
that there were scenarios where I could cause multiple servers to enter the
same timeline while possibly having divergent data. One such scenario is
Master A and Replica B are both on timeline 1. There is an event
On Thu, Jul 13, 2017 at 10:30 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> It would be nice to get to the bottom of why we're getting a version
>> mismatch on Windows, since we're clearly not getting one on Linux.
>
> Yeah, that's what's bothering me: as long as that remains unexplained,
> I d
Hi,
hstore have only key-value pairs, but in json can have same behavior -
only equal objects are removed:
SELECT '{"a": 1, "b": {"c": 2}}'::JSONB - '{"a": 1, "b": {"c": 3}}'::JSONB
'{"b": {"c": 2}}'
SELECT '{"a": 1, "b": {"c": 2}}'::JSONB - '{"a": 2, "b": {"c": 2}}'::JSONB
'{"a": 1}'
Davi
While reviewing Corey's \if patch, I complained that there was some amount
of copy-paste in "psql/command.c".
Here is an attempt at merging some functions which removes 160 lines of
code.
Thank you for the patch. Is this an item for PG11?
Yep.
--
Fabien.
--
Sent via pgsql-hackers mailing
Etsuro Fujita writes:
> * Modified rewrite_targetlist(), which is a new function added to
> preptlist.c, so that we do const-simplification to junk TLEs that
> AddForeignUpdateTargets() added, as that API allows the FDW to add junk
> TLEs containing non-Var expressions to the query's targetlist
Hello Alik,
I am attaching patch v3.
Among other things I fixed small typo in description of
random_exponential function in pgbench.sgml file.
Ok. Probably this typo should be committed separatly and independently.
A few comments about v3:
Patch applies cleanly, compiles, works.
About t
That's not actually a problem as I am reusing an older v4 from Heikki
now for the future, but I wanted to let you know about that first.
Thank you, I'll look into that.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hack
Mark Dilger writes:
>> On Jul 18, 2017, at 9:13 PM, Mark Dilger wrote:
>> There was not much conversation about this, so I went ahead with what
>> I think makes a logical first step. The attached patch removes the tinterval
>> datatype from the sources.
> As predicted, this second patch (which
*To summarise,* the options we have to solve the limitation of the
@>(anyarray , anyelement) where it produces the following error: operator
does not exist: integer[] @> smallint
*Option 1: *Multiple Operators
Have separate operators for every combination of datatypes instead of a
single polymorph
On Tue, Jul 18, 2017 at 11:14 PM, Alvaro Herrera
wrote:
>
> Why did we add an operator and not a support
> procedure?
I thought the support procedures were constant within an opclass. They
implement the mandotary function required of an opclass. I don't see why we
would need to implement new one
On 2017/07/13 21:10, Etsuro Fujita wrote:
Attached is an updated version of the patch.
Here is an updated version of the patch. Changes are:
* Modified rewrite_targetlist(), which is a new function added to
preptlist.c, so that we do const-simplification to junk TLEs that
AddForeignUpdateTar
Now that we are going to have logical replication in PostgreSQL 10, I
have started thinking how Pgpool-II can deal with it. For example, the
logical replication does not replicate DDLs. Isn't it convenient for
users to do it automatically in Pgpool-II? Or even doing it for
TRUNCATE?
Or are they ag
96 matches
Mail list logo
