Re: [HACKERS] lag(bigint,int,int), etc?

On Tue, Jun 27, 2017 at 10:01 AM, Colin 't Hart wrote: > Hi, > > The following rather contrived example illustrates that lag(), lead() > (and probably other functions) can't automatically cast an integer to > a bigint: > > select lag(sum,1,0) over () from (select

Re: [HACKERS] Pluggable storage

On Tue, Jun 27, 2017 at 4:08 PM, Amit Kapila wrote: > On Thu, Jun 22, 2017 at 8:00 PM, Alexander Korotkov > wrote: > > On Wed, Jun 21, 2017 at 10:47 PM, Robert Haas > wrote: > >> > >> On Mon, Jun 12, 2017 at 9:50 PM,

Re: [HACKERS] CREATE COLLATION definitional questions for ICU

On 6/25/17 11:45, Tom Lane wrote: > * Should not the FROM code path copy the old collation's version? > It seems a little bit weird that "cloning" a collation takes the > liberty of installing a new version. I think this is working correctly. Specifying the version explicitly is really only

Re: [HACKERS] Same expression more than once in partition key

On Fri, Jun 23, 2017 at 4:04 PM, Tom Lane wrote: > 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

Re: [HACKERS] pgjdbc logical replication client throwing exception

Hi, I suspect its happening because of delay in status update by client but even after trying forceUpdateStatus its quitting prematurely. Thanks, Sanyam Jain From: sanyam jain Sent: Tuesday, June 27, 2017 6:47:55 AM To: Peter

Re: [HACKERS] lag(bigint,int,int), etc?

On 27 Jun 2017, at 17:06, Merlin Moncure wrote: > >> On Tue, Jun 27, 2017 at 10:01 AM, Colin 't Hart wrote: >> Hi, >> >> The following rather contrived example illustrates that lag(), lead() >> (and probably other functions) can't automatically cast an

Re: [HACKERS] memory layouts for binary search in nbtree

On Tue, Jun 27, 2017 at 11:04 AM, Andres Freund wrote: > > On 2017-06-27 10:57:15 -0700, Peter Geoghegan wrote: >> I looked at this again recently. I wrote a patch to prove to myself >> that we can fairly easily reclaim 15 bits from every nbtree internal >> page ItemId, and

Re: [HACKERS] Fast promotion not used when doing a recovery_target PITR restore?

On 2017-06-23 10:56:07 +0900, Michael Paquier wrote: > > And even there it might actually be > > a pretty good idea to not force a full checkpoint - getting up fast > > after a crash is kinda important.. > > But not that. Crash recovery is designed to be simple and robust, with > only the

Re: [HACKERS] Reducing pg_ctl's reaction time

I wrote: > Andres Freund writes: >> On 2017-06-26 17:38:03 -0400, Tom Lane wrote: >>> Hm. Take that a bit further, and we could drop the connection probes >>> altogether --- just put the whole responsibility on the postmaster to >>> show in the pidfile whether it's ready for

[HACKERS] Abbreviated keys in nbtree internal pages

Over on the "memory layouts for binary search in nbtree" thread, I described a plausible way of implementing abbreviated keys for nbtree internal pages [1]. I've been going on about this technique for a long time, but the insight that we can do it by reusing an itemId's lp_len field is a new one.

Re: [HACKERS] memory layouts for binary search in nbtree

On 2017-06-27 11:13:38 -0700, Peter Geoghegan wrote: > On Tue, Jun 27, 2017 at 11:04 AM, Andres Freund wrote: > > > > On 2017-06-27 10:57:15 -0700, Peter Geoghegan wrote: > >> I looked at this again recently. I wrote a patch to prove to myself > >> that we can fairly easily

Re: [HACKERS] memory layouts for binary search in nbtree

On Tue, Jun 27, 2017 at 11:05 AM, Andres Freund wrote: >> Did you ever try running a pgbench SELECT benchmark, having modified >> things such that all PKs are on columns that are not of type >> int4/int8, but rather are of type numeric? It's an interesting >> experiment, that

Re: [HACKERS] Fast promotion not used when doing a recovery_target PITR restore?

On Wed, Jun 28, 2017 at 3:44 AM, Andres Freund wrote: > I'm far from convinced by this. By now WAL replay with checkpointer, > bgwriter, etc. active is actually *more* tested than the cases without > it. The likelihood of bugs is higher in the less frequently exercised >

Re: [HACKERS] Reducing pg_ctl's reaction time

Hi, On 2017-06-27 14:59:18 -0400, Tom Lane wrote: > Here's a draft patch for that. I quite like the results --- this seems > way simpler and more reliable than what pg_ctl has done up to now. Yea, I like that too. > However, it's certainly arguable that this is too much change for an >

Re: [HACKERS] Reducing pg_ctl's reaction time

Andres Freund writes: > On 2017-06-27 14:59:18 -0400, Tom Lane wrote: >> If we decide that it has to wait for v11, >> I'd address Jeff's complaint by hacking the loop behavior in >> test_postmaster_connection, which'd be ugly but not many lines of code. > Basically increasing

Re: [HACKERS] Pluggable storage

On Tue, Jun 27, 2017 at 4:19 PM, Amit Kapila wrote: > On Thu, Jun 22, 2017 at 5:46 PM, Alexander Korotkov > wrote: > > On Tue, Jun 13, 2017 at 4:50 AM, Haribabu Kommi < > kommi.harib...@gmail.com> > > wrote: > >> > >> On Fri, Oct 14, 2016 at

[HACKERS] lag(bigint,int,int), etc?

Hi, The following rather contrived example illustrates that lag(), lead() (and probably other functions) can't automatically cast an integer to a bigint: select lag(sum,1,0) over () from (select sum(generate_series) over (order by generate_series) from generate_series(1,10)) x; ERROR: function

[HACKERS] Typo in comment in xlog.c: ReadRecord

Attached fixes $SUBJECT. s/fetch_ckpt/fetching_ckpt/g Thanks, Amit diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index 0a6314a642..5b6cec8dee 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -4221,10 +4221,10 @@

Re: [HACKERS] Pluggable storage

On Wed, Jun 28, 2017 at 12:00 AM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Tue, Jun 27, 2017 at 4:19 PM, Amit Kapila > wrote: > >> On Thu, Jun 22, 2017 at 5:46 PM, Alexander Korotkov >> wrote: >> > On Tue, Jun 13, 2017 at

Re: [HACKERS] Fast promotion not used when doing a recovery_target PITR restore?

On 2017-06-28 06:04:23 +0900, Michael Paquier wrote: > On Wed, Jun 28, 2017 at 3:44 AM, Andres Freund wrote: > > I'm far from convinced by this. By now WAL replay with checkpointer, > > bgwriter, etc. active is actually *more* tested than the cases without > > it. The

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Fri, Jun 23, 2017 at 5:45 AM, Thom Brown wrote: > > I also think pg_prewarm.dump_interval should be renamed to > pg_prewarm.autoprewarm_interval. Thanks, I have changed it to pg_prewarm.autoprewarm_interval. >> >> * In the documentation, don't say "This is a SQL callable

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On 27/06/17 10:51, Masahiko Sawada wrote: > On Mon, Jun 26, 2017 at 12:12 PM, Masahiko Sawada > wrote: > > I've reviewed this patch briefly. Thanks! > > @@ -515,6 +533,31 @@ logicalrep_worker_stop(Oid subid, Oid relid) > } > > /* > + * Request worker to be stopped

Re: [HACKERS] lag(bigint,int,int), etc?

On Tue, Jun 27, 2017 at 10:12 AM, Colin 't Hart wrote: > On 27 Jun 2017, at 17:06, Merlin Moncure wrote: >> >>> On Tue, Jun 27, 2017 at 10:01 AM, Colin 't Hart >>> wrote: >>> Hi, >>> >>> The following rather contrived example

Re: [HACKERS] CREATE COLLATION definitional questions for ICU

Peter Eisentraut writes: > On 6/25/17 11:45, Tom Lane wrote: >> * Should not the FROM code path copy the old collation's version? >> It seems a little bit weird that "cloning" a collation takes the >> liberty of installing a new version. > I think this is

Re: [HACKERS] psql - add special variable to reflect the last query status

Hello Pavel, We can introduce macro SetVariableBool(vars, varname, bool) instead SetVariable(pset.vars, "ERROR", "FALSE"); I checked source code, and it requires little bit more harder refactoring because now we have SetVariableBool - what is unhappy name, because it initialize variable to

Re: [HACKERS] memory layouts for binary search in nbtree

On Thu, May 19, 2016 at 7:28 PM, Peter Geoghegan wrote: > Abbreviated keys in indexes are supposed to help with this. Basically, > the ItemId array is made to be interlaced with small abbreviated keys > (say one or two bytes), only in the typically less than 1% of pages > that

Re: [HACKERS] memory layouts for binary search in nbtree

Hi, On 2017-06-27 10:57:15 -0700, Peter Geoghegan wrote: > I looked at this again recently. I wrote a patch to prove to myself > that we can fairly easily reclaim 15 bits from every nbtree internal > page ItemId, and put an abbreviated key there instead. Interesting. Not sure however that really

Re: [HACKERS] memory layouts for binary search in nbtree

On 2016-05-19 19:38:02 -0700, Peter Geoghegan wrote: > On Wed, May 18, 2016 at 6:25 AM, Andres Freund wrote: > > currently we IIRC use linearly sorted datums for the search in > > individual btree nodes. Not surprisingly that's often one of the > > dominant entries in

Re: [HACKERS] Modifing returning value of PQgetvalue.

Peter Eisentraut writes: > On 6/24/17 06:31, Dmitry Igrishin wrote: >> PQgetvalue returns a value of type char* (without const). But the >> documentation says: >> "The pointer returned by PQgetvalue points to storage that is part of >> the PGresult structure.

Re: [HACKERS] pgjdbc logical replication client throwing exception

Hi, >What does the server log say? If nothing interesting, turn up debugging. I receive the following Log on server LOG: could not send data to client: Broken pipe Thanks, Sanyam Jain

Re: [HACKERS] psql - add special variable to reflect the last query status

Hi 2017-06-19 5:55 GMT+02:00 Pavel Stehule : > > > 2017-06-17 7:58 GMT+02:00 Fabien COELHO : > >> >> I have not any other comments. The implementation is trivial. I rerun all >>> tests and tests passed. >>> >>> I'll mark this patch as ready for

Re: [HACKERS] Setting pd_lower in GIN metapage

On 2017/06/27 10:22, Michael Paquier wrote: > On Mon, Jun 26, 2017 at 4:11 PM, Masahiko Sawada > wrote: >> Thank you for the patches! I checked additional patches for brin and >> spgist. They look good to me. > > Last versions are still missing something: brin_mask() and

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On Mon, Jun 26, 2017 at 12:12 PM, Masahiko Sawada wrote: > On Sun, Jun 25, 2017 at 7:35 PM, Petr Jelinek > wrote: >> (was away for a while, got some time now for this again) >> >> On 22/06/17 04:43, Peter Eisentraut wrote: >>> The alternative

[HACKERS] GSoC 2017: weekly progress reports (week 4) and patch for hash index

Project: Explicitly support predicate locks in index AMs besides b-tree Hi, During this week, I continued my work on predicate locking in the hash index and created a patch for it. As I have written in my proposal for the hash index, every scan operation acquires a predicate lock on the primary

Re: [HACKERS] Proposal : For Auto-Prewarm.

Thanks, Robert, I have tried to fix all of you comments and merged to fixes suggested by Thom in patch 15. On Fri, Jun 23, 2017 at 3:22 AM, Robert Haas wrote: > > * I suggest renaming launch_autoprewarm_dump() to > autoprewarm_start_worker(). I think that will be clearer.

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

On 2017/06/26 18:44, Kyotaro HORIGUCHI wrote: > At Mon, 26 Jun 2017 18:16:42 +0900, Amit Langote wrote: >> >> I recall I had proposed a fix for the same thing some time ago [1]. > > Wow. About 1.5 years ago and stuck? I have a concrete case where > this harms so I'd like to fix that this time.

Re: [HACKERS] pg_basebackup fails on Windows when using tablespace mapping

Hi, On Tue, Jun 27, 2017 at 10:13 AM, Michael Paquier wrote: > On Tue, Jun 27, 2017 at 12:13 PM, Michael Paquier > wrote: >> At quick glance, I think that this should definitely be a client-only >> fix. One reason is that pg_basebackup

Re: [HACKERS] Pluggable storage

On Thu, Jun 22, 2017 at 8:00 PM, Alexander Korotkov wrote: > On Wed, Jun 21, 2017 at 10:47 PM, Robert Haas wrote: >> >> On Mon, Jun 12, 2017 at 9:50 PM, Haribabu Kommi >> wrote: >> > Open Items: >> > >> > 1. The

Re: [HACKERS] pg_basebackup fails on Windows when using tablespace mapping

On Tue, Jun 27, 2017 at 7:46 PM, Ashutosh Sharma wrote: > I am still seeing the issue with the attached patch. I had a quick > look into the patch. It seems to me like you have canonicalized the > tablespace path to convert win32 slashes to unix type of slashes but > that

Re: [HACKERS] pg_terminate_backend can terminate background workers and autovacuum launchers

On Sat, 24 Jun 2017 08:09:52 +0900 Michael Paquier wrote: > 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

Re: [HACKERS] Pluggable storage

On Thu, Jun 22, 2017 at 5:46 PM, Alexander Korotkov wrote: > On Tue, Jun 13, 2017 at 4:50 AM, Haribabu Kommi > wrote: >> >> On Fri, Oct 14, 2016 at 7:26 AM, Alvaro Herrera >> wrote: >>> >>> I have sent the partial

Re: [HACKERS] pg_terminate_backend can terminate background workers and autovacuum launchers

On Fri, 23 Jun 2017 19:43:35 -0400 Stephen Frost wrote: > 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

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On Fri, Jun 23, 2017 at 09:42:10PM -0400, Peter Eisentraut wrote: > 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

Re: [HACKERS] Pluggable storage

On Tue, Jun 27, 2017 at 11:53 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Tue, Jun 27, 2017 at 4:08 PM, Amit Kapila > wrote: > >> On Thu, Jun 22, 2017 at 8:00 PM, Alexander Korotkov >> wrote: >> > On Wed, Jun 21, 2017 at

Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

On Wed, Aug 24, 2016 at 2:58 AM, Robert Haas wrote: > Now, for bigger segment sizes, I think there actually could be a > little bit of a noticeable performance hit here, because it's not just > about total elapsed time. Even if the code eventually touches all of > the

Re: [HACKERS] pg_serial early wraparound

On Sat, Mar 25, 2017 at 7:27 AM, Thomas Munro wrote: > On Sat, Mar 25, 2017 at 3:11 AM, Anastasia Lubennikova > wrote: >> You claim that SLRUs now support five digit segment name, while in slru.h >> at current master I see the following: >>

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Mon, May 22, 2017 at 6:39 AM, Thomas Munro wrote: > On Thu, Apr 27, 2017 at 11:03 AM, Thomas Munro > wrote: >> On Thu, Apr 27, 2017 at 5:13 AM, Oleg Golovanov wrote: >>> Can you actualize your patch set? The error

Re: [HACKERS] Pluggable storage

On Thu, Jun 22, 2017 at 5:47 AM, Robert Haas wrote: > On Mon, Jun 12, 2017 at 9:50 PM, Haribabu Kommi > wrote: > > Open Items: > > > > 1. The BitmapHeapScan and TableSampleScan are tightly coupled with > > HeapTuple and HeapScanDesc, So these

Re: [HACKERS] SERIALIZABLE with parallel query

On Tue, Apr 4, 2017 at 8:25 AM, Thomas Munro wrote: > ... but considering that these data structures may > finish up being redesigned as part of the GSoC project[1], it may be > best to wait and see where that goes before doing anything. I'll > follow developments

Re: [HACKERS] transition table behavior with inheritance appears broken

> "Noah" == Noah Misch writes: Noah> IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is Noah> long past due for your status update. Please reacquaint yourself Noah> with the policy on open item ownership[1] and then reply Noah> immediately. If I do not

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On Wed, Jun 28, 2017 at 1:47 AM, Petr Jelinek wrote: > > On 27/06/17 10:51, Masahiko Sawada wrote: >> On Mon, Jun 26, 2017 at 12:12 PM, Masahiko Sawada >> wrote: >> >> I've reviewed this patch briefly. > > Thanks! > >> >> @@ -515,6 +533,31 @@