Re: [HACKERS] archive_timeout ignored directly after promotion

On Thu, Jun 22, 2017 at 2:58 AM, Andres Freund wrote: > One easy way to fix that would be to just wakeup the checkpointer from > the startup process once at the end of recovery, but it'd not be > pretty. I think it'd be better to change the >

Re: [HACKERS] Race conditions with WAL sender PID lookups

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 25fff40. > > > > [Action required within three days. This is a generic

Re: [HACKERS] Autovacuum launcher occurs error when cancelled by SIGINT

On Thu, Jun 22, 2017 at 9:48 AM, Michael Paquier wrote: > On Thu, Jun 22, 2017 at 1: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 Ghosh

Re: [HACKERS] Transition tables vs ON CONFLICT

On Mon, Jun 19, 2017 at 11:04 AM, Andrew Gierth wrote: >> "Thomas" == Thomas Munro writes: > > Thomas> That accidentally removed a comment that I wanted to keep. > Thomas> Here is a better version. > > I plan to commit this soon;

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

On Mon, Jun 19, 2017 at 11:06 AM, Andrew Gierth wrote: >> "Thomas" == Thomas Munro writes: > > Thomas> Thanks both for the review. New version of patch #2 attached. > > I'm looking to commit this soon; if anyone has any further

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Mon, Jun 12, 2017 at 2:03 PM, Thomas Munro wrote: > Thanks for the review. New version of patch #1 attached. Here's a version rebased on top of the recently reindented master branch. -- Thomas Munro http://www.enterprisedb.com

Re: [HACKERS] asynchronous execution

The patch got conflicted. This is a new version just rebased to the current master. Furtuer amendment will be taken later. > The attached patch is rebased on the current master, but no > substantial changes other than disallowing partitioned tables on > async by assertion. regards, -- Kyotaro

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

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 I'd love to see a SQL function >> that allows triggering SIGHUP on a specific process, like an

Re: [HACKERS] Logical replication launcher never been restarted when terminated

On Wed, 21 Jun 2017 15:17:20 -0400 Peter Eisentraut wrote: > On 6/21/17 13:03, Yugo Nagata wrote: > > As I report in another thread[1], when the logical replication launcher > > is terminated by SIGTERM, it never been restarted and we need to restart > > the

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

On Thu, Jun 22, 2017 at 3:04 AM, Andres Freund wrote: > When doing a PITR style recovery, with recovery target set, we're > currently not doing a fast promotion, in contrast to the handling when > doing a pg_ctl or trigger file based promotion. That can prolong making > the

Re: [HACKERS] Autovacuum launcher occurs error when cancelled by SIGINT

On Thu, 22 Jun 2017 13:12:48 +0900 Michael Paquier wrote: > On Wed, Jun 21, 2017 at 9:15 PM, Yugo Nagata wrote: > > This errors continue until this process is terminated or the server is > > restarted. > > > > When SIGINT is issued, the process

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

On Thu, 22 Jun 2017 12:05:19 +0900 Michael Paquier wrote: > On Thu, Jun 22, 2017 at 11:52 AM, Andres Freund wrote: > > On 2017-06-22 11:49:47 +0900, Yugo Nagata wrote: > >> I agree that we can kill theses processes by the OS command. However, > >>

Re: [HACKERS] Autovacuum launcher occurs error when cancelled by SIGINT

On Thu, Jun 22, 2017 at 1: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 Ghosh >> wrote: IMHO, It's not a good idea to use DSM call to

Re: [HACKERS] Autovacuum launcher occurs error when cancelled by SIGINT

On Wed, Jun 21, 2017 at 9:15 PM, Yugo Nagata wrote: > This errors continue until this process is terminated or the server is > restarted. > > When SIGINT is issued, the process exits from the main loop and returns > to sigsetjmp, and calls dsa_attach() before entering into

Re: [HACKERS] pgrowlocks relkind check

On 2017/06/22 12:26, Peter Eisentraut wrote: > On 6/14/17 01:34, Amit Langote wrote: >> How about the attached patch that teaches pgrowlocks() to error out unless >> a meaningful result can be returned? With the patch, it will issue a "%s >> is not a table" message if it is not a

Re: [HACKERS] outfuncs.c utility statement support

Peter Eisentraut writes: > On 6/18/17 10:14, Tom Lane wrote: >> Doesn't cope with backslash-quoted characters. If we're going to bother >> to do anything here, I think we ought to make it reversible for all >> possible characters. > Makes sense. Updated patch

Re: [HACKERS] pgrowlocks relkind check

On 6/14/17 01:34, Amit Langote wrote: > How about the attached patch that teaches pgrowlocks() to error out unless > a meaningful result can be returned? With the patch, it will issue a "%s > is not a table" message if it is not a RELKIND_RELATION, except a > different message will be issued for

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

On Thu, Jun 22, 2017 at 11:52 AM, Andres Freund wrote: > On 2017-06-22 11:49:47 +0900, Yugo Nagata wrote: >> I agree that we can kill theses processes by the OS command. However, >> It seems to me that pg_{cancel,terminate}_backend don't need to be able to >> kill processes

Re: [HACKERS] outfuncs.c utility statement support

On 6/18/17 10:14, Tom Lane wrote: > pg_strtok recognizes "<>" and returns length = 0, so debackslash() > would produce the right answer AFAICS (admittedly, I haven't tested). > But I don't really want to do it like that because of the wasted > palloc space and cycles. > >> Maybe >>

Re: [HACKERS] Pluggable storage

On Thu, Jun 22, 2017 at 11:12 AM, Amit Langote wrote: > On 2017/06/22 10:01, Michael Paquier wrote: >> #3 implies that the index AM logic is implemented in the table >> AM. Not saying that it is not useful, but it does not feel natural to >> have the planner request

Re: [HACKERS] Useless code in ExecInitModifyTable

On 2017/06/22 11:25, Etsuro Fujita wrote: > On 2017/06/21 23:52, Robert Haas wrote: > >> You're right that there is a comment missing from the function header, >> but it's not too hard to figure out what it should be. Just consult >> the definition of ModifyTable itself: >> >> /* RT

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

On 2017-06-22 11:49:47 +0900, Yugo Nagata wrote: > On Wed, 21 Jun 2017 11:04:34 -0400 > Robert Haas wrote: > > > On Wed, Jun 21, 2017 at 7:56 AM, Yugo Nagata wrote: > > > I have found that we can cancel/terminate autovacuum launchers and > > >

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

On Wed, 21 Jun 2017 11:04:34 -0400 Robert Haas wrote: > On Wed, Jun 21, 2017 at 7:56 AM, Yugo Nagata wrote: > > I have found that we can cancel/terminate autovacuum launchers and > > background worker processes by pg_cancel/terminate_backend function.

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

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 your subsequent status > update. Refer to the

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

On 6/19/17 22:41, Masahiko Sawada wrote: > On Tue, Jun 20, 2017 at 10:47 AM, Peter Eisentraut > wrote: >> On 6/16/17 04:16, Masahiko Sawada wrote: >>> A subscription relation state may have been removed already when we >>> try to update it.

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

On 6/20/17 19:10, Peter Eisentraut wrote: > On 6/19/17 22:54, Masahiko Sawada wrote: >>> It seems to me we could just take a stronger lock around >>> RemoveSubscriptionRel(), so that workers can't write in there concurrently. >> >> Since we reduced the lock level of updating pg_subscription_rel by

Re: [HACKERS] Useless code in ExecInitModifyTable

On 2017/06/21 23:52, Robert Haas wrote: You're right that there is a comment missing from the function header, but it's not too hard to figure out what it should be. Just consult the definition of ModifyTable itself: /* RT indexes of non-leaf tables in a partition tree */

Re: [HACKERS] Fix a typo in partition.c

On Wed, Jun 21, 2017 at 3:32 AM, Peter Eisentraut wrote: > On 6/19/17 23:02, Masahiko Sawada wrote: >> Hi, >> >> Attached patch for $subject. >> >> s/opreator/operator/ > > fixed > Thank you! I found another one. s/retrived/retrieved/ Regards, -- Masahiko

Re: [HACKERS] Pluggable storage

On 2017/06/22 10:01, Michael Paquier wrote: > #3 implies that the index AM logic is implemented in the table > AM. Not saying that it is not useful, but it does not feel natural to > have the planner request for a sequential scan, just to have the table > AM secretly do some kind of index/skipping

Re: [HACKERS] An attempt to reduce WALWriteLock contention

On Thu, Jun 22, 2017 at 6:46 AM, Michael Paquier wrote: > On Wed, Jun 21, 2017 at 4:57 PM, 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

Re: [HACKERS] An attempt to reduce WALWriteLock contention

On Thu, Dec 22, 2016 at 11:29 PM, Tomas Vondra wrote: > > How do these counts compare to the other wait events? For example > CLogControlLock, which is what Amit's patch [1] is about? > > [1] >

Re: [HACKERS] ASOF join

On Wed, Jun 21, 2017 at 9:46 PM, Konstantin Knizhnik wrote: > Thank you for this idea. I agree that it is the best way of implementing > ASOF join - just as optimization of standard SQL query. Great. I think this part definitely has potential. > But do you think that

Re: [HACKERS] An attempt to reduce WALWriteLock contention

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 doesn't scale beyond ~8 cores without saturating the IOPs or > bandwidth. Is there

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 2017-06-21 18:07:21 -0700, Andres Freund wrote: > On 2017-06-22 09:03:05 +0800, Craig Ringer wrote: > > On 22 June 2017 at 08:29, Andres Freund wrote: > > > > > I.e. we're doing tiny write send() syscalls (they should be coalesced) > > > > That's likely worth doing, but

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 22 June 2017 at 09:07, Andres Freund wrote: > On 2017-06-22 09:03:05 +0800, Craig Ringer wrote: >> On 22 June 2017 at 08:29, Andres Freund wrote: >> >> > I.e. we're doing tiny write send() syscalls (they should be coalesced) >> >> That's likely worth

Re: [HACKERS] An attempt to reduce WALWriteLock contention

On Wed, Jun 21, 2017 at 4:57 PM, 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 doesn't scale beyond ~8 cores without saturating the IOPs

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 2017-06-22 09:03:05 +0800, Craig Ringer wrote: > On 22 June 2017 at 08:29, Andres Freund wrote: > > > I.e. we're doing tiny write send() syscalls (they should be coalesced) > > That's likely worth doing, but can probably wait for a separate patch. I don't think so, we

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 22 June 2017 at 08:29, Andres Freund wrote: > I.e. we're doing tiny write send() syscalls (they should be coalesced) That's likely worth doing, but can probably wait for a separate patch. The kernel will usually do some packet aggregation unless we use TCP_NODELAY (which

Re: [HACKERS] Pluggable storage

On Thu, Jun 22, 2017 at 4:47 AM, Robert Haas wrote: > I think that BitmapHeapScan, at least, is applicable to any table AM > that has TIDs. It seems to me that in general we can imagine three > kinds of table AMs: > > 1. Table AMs where a tuple can be efficiently located

Re: [HACKERS] Adding support for Default partition in partitioning

On 2017/06/21 21:37, Jeevan Ladhe wrote: > Hi Amit, > > On Thu, Jun 15, 2017 at 12:31 PM, Amit Langote < > langote_amit...@lab.ntt.co.jp> wrote: > >> Oops, I meant to send one more comment. >> >> On 2017/06/15 15:48, Amit Langote wrote: >>> BTW, I noticed the following in 0002 >> +

Re: [HACKERS] ASOF join

On Mon, Jun 19, 2017 at 11:57 PM, Konstantin Knizhnik wrote: > On 16.06.2017 19:07, David Fetter wrote: >> If you turn your head sideways, it's very similar to the range merge >> join Jeff Davis proposed. https://commitfest.postgresql.org/14/1106/ > > May be, but I do

Re: [HACKERS] Rules on table partitions

On 2017/06/21 18:49, Dean Rasheed wrote: > On 20 June 2017 at 03:01, Amit Langote wrote: >> Hmm, yes. The following exercise convinced me. >> >> create table r (a int) partition by range (a); >> create table r1 partition of r for values from (1) to (10); >> create

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 2017-06-21 16:40:48 -0700, Andres Freund wrote: > On 2017-06-20 17:51:23 +0200, Daniel Verite wrote: > > Andres Freund wrote: > > > > > FWIW, I still think this needs a pgbench or similar example integration, > > > so we can actually properly measure the benefits. > > > > Here's an

Re: [HACKERS] Optional message to user when terminating/cancelling backend

On Wed, Jun 21, 2017 at 11:42 PM, Daniel Gustafsson wrote: > The message is truncated in SetBackendCancelMessage() for safety, but > pg_{cancel|terminate}_backend() could throw an error on too long message, or > warning truncation, to the caller as well. Personally I think a

Re: [HACKERS] RLS in CTE incorrect permission failure

On Wed, Jun 21, 2017 at 7:46 PM, Tom Lane wrote: > Rod Taylor writes: > > In the attached script, the second insert into t2 (as part of the CTE) > > should succeed. > > No, I don't think so. You declared the check function as STABLE which > means it is

Re: [HACKERS] [COMMITTERS] pgsql: Restart logical replication launcher when killed

On 2017-06-22 08:46:35 +0900, Michael Paquier wrote: > On Thu, Jun 22, 2017 at 4:16 AM, Peter Eisentraut wrote: > > Restart logical replication launcher when killed > > - /* The logical replication launcher can be stopped at any time. */ > - proc_exit(0); > +

Re: [HACKERS] RLS in CTE incorrect permission failure

Rod Taylor writes: > In the attached script, the second insert into t2 (as part of the CTE) > should succeed. No, I don't think so. You declared the check function as STABLE which means it is confined to seeing the same snapshot as the surrounding query. So it can't see

Re: [HACKERS] [COMMITTERS] pgsql: Restart logical replication launcher when killed

On Thu, Jun 22, 2017 at 4:16 AM, Peter Eisentraut wrote: > Restart logical replication launcher when killed - /* The logical replication launcher can be stopped at any time. */ - proc_exit(0); + /* The logical replication launcher can be stopped at

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 22 Jun. 2017 07:40, "Andres Freund" wrote: On 2017-06-20 17:51:23 +0200, Daniel Verite wrote: > Andres Freund wrote: > > > FWIW, I still think this needs a pgbench or similar example integration, > > so we can actually properly measure the benefits. > > Here's an

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 2017-06-20 17:51:23 +0200, Daniel Verite wrote: > Andres Freund wrote: > > > FWIW, I still think this needs a pgbench or similar example integration, > > so we can actually properly measure the benefits. > > Here's an updated version of the patch I made during review, > adding

[HACKERS] RLS in CTE incorrect permission failure

In the attached script, the second insert into t2 (as part of the CTE) should succeed. My actual use case isn't much more complex; the function is used primarily to allow peaking at columns that the function definer has access to but a typical user does not. Function also makes it easy to copy

[HACKERS] PG 10beta2 schedule

The release team has agreed that a good time to put out beta2 will be the second week of July, ie wrap tarballs 10 July for announcement 13 July. I imagine beta3 will appear along with the scheduled back-branch releases in the second week of August, but that's not positively decided yet.

Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests

Today, lorikeet failed with a new variant on the bgworker start crash: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet=2017-06-21%2020%3A29%3A10 This one is even more exciting than the last one, because it sure looks like the crashing bgworker took the postmaster down with it.

Re: [HACKERS] Re-indent HEAD tomorrow?

Andres Freund writes: > On 2017-06-21 17:28:32 -0400, Tom Lane wrote: >> And I think it'd make sense to wait a few >> months and garner some experience with back-patching from v10 into the >> older branches, so we have more than guesses about how much pain not >> reindenting

Re: [HACKERS] Re-indent HEAD tomorrow?

On 2017-06-21 17:28:32 -0400, Tom Lane wrote: > Right now we're really just speculating about how much pain there will > be, on either end of this. So it'd be interesting for somebody who's > carrying large out-of-tree patches (EDB? Citus?) to try the new > pgindent version on a back branch and

Re: [HACKERS] CREATE SUBSCRIPTION log noise

2017-06-21 15:14 GMT-03:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > > It doesn't appear to be contingent on anything other than the content of > > the command you just gave it. I don't think we need a NOTICE saying > > that it did that thing I just told it to do--that should be

Re: [HACKERS] Phantom segment upon promotion causing troubles.

Hi, On 2017-06-20 16:11:32 +0300, Heikki Linnakangas wrote: > On 06/19/2017 10:30 AM, Andres Freund wrote: > > Greg Burek from Heroku (CCed) reported a weird issue on IM, that was > > weird enough to be interesting. What he'd observed was that he promoted > > some PITR standby, and early clones

Re: [HACKERS] Re-indent HEAD tomorrow?

Bruce Momjian writes: > On Wed, Jun 21, 2017 at 04:07:30PM -0400, Tom Lane wrote: >> ... and it's done. > You are eventually doing all active branches, right? I don't think we'd entirely decided that we should do that, or when to do it. I'm not in a huge hurry; we might find

[HACKERS] Broken O(n^2) avoidance in wal segment recycling.

Hi, Author: Heikki Linnakangas Branch: master Release: REL9_5_BR [b2a5545bd] 2015-04-13 16:53:49 +0300 Branch: REL9_4_STABLE Release: REL9_4_2 [d72792d02] 2015-04-13 17:22:21 +0300 Branch: REL9_3_STABLE Release: REL9_3_7 [a800267e4] 2015-04-13 17:22:35 +0300 Branch:

Re: [HACKERS] Re-indent HEAD tomorrow?

On Wed, Jun 21, 2017 at 04:07:30PM -0400, Tom Lane wrote: > I wrote: > > Barring objections, I'd like to reindent HEAD with the new version > > of pg_bsd_indent (and correspondingly updated pgindent script) > > tomorrow, say around 1800 UTC. > > ... and it's done. You are eventually doing all

Re: [HACKERS] UPDATE of partition key

On Wed, Jun 21, 2017 at 1:38 PM, Amit Khandekar wrote: >>> Yep, it's more appropriate to use >>> ModifyTableState->rootResultRelationInfo->ri_RelationDesc somehow. That >>> is, if answer to the question I raised above is positive. > > From what I had checked earlier when

Re: [HACKERS] Making server name part of the startup message

Satyanarayana Narlapuram writes: >> Why do we need to incur a protocol break to add another one? > This is optional and is not a protocol break. Yes, it is. We've been around on this sort of thing before and we understand the consequences. If the option

Re: [HACKERS] UPDATE of partition key

On Wed, Jun 21, 2017 at 1:37 PM, Amit Khandekar wrote: >> e.g. the table is partitioned on order number, and you do UPDATE >> lineitem SET product_code = 'K372B' WHERE product_code = 'K372'. > > This query does not update order number, so here there is no >

Re: [HACKERS] postgresql transactons not fully isolated

On Tue, Jun 20, 2017 at 2:58 PM, Merlin Moncure wrote: > On Tue, Jun 20, 2017 at 2:34 PM, David G. Johnston > wrote: >> On Tue, Jun 20, 2017 at 12:22 PM, Chapman Flack >> wrote: >>> I get the reported result (DELETE 0 and a

Re: [HACKERS] Re-indent HEAD tomorrow?

I wrote: > Barring objections, I'd like to reindent HEAD with the new version > of pg_bsd_indent (and correspondingly updated pgindent script) > tomorrow, say around 1800 UTC. ... and it's done. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Pluggable storage

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 scans are directly operating > on those structures and providing the result. > > These scan

Re: [HACKERS] Adding connection id in the startup message

On Wed, Jun 21, 2017 at 12:15 PM, Robert Haas wrote: > I think the problem is real, > but I'm not sure that this is the best solution. On the other hand, > I'm also not entirely sure I understand the proposal yet. Given the problems with changing the protocol it does seem

Re: [HACKERS] Missing comment for ResultRelInfo in execnodes.h

On 6/20/17 22:37, Etsuro Fujita wrote: > On 2017/06/21 3:30, Peter Eisentraut wrote: >> On 6/20/17 05:50, Etsuro Fujita wrote: >>> Here is a small patch to add a comment on its new member PartitionRoot. >> >> The existing comment style is kind of unusual. How about the attached >> to clean it up

Re: [HACKERS] Making server name part of the startup message

PgBouncer for example assumes that the database names are unique across the database clusters it is serving. Our front-end Gateways can serve tens of thousands of Postgres servers spanning multiple customers, and organizations, and enforcing the database names being unique is not possible for

Re: [HACKERS] Making server name part of the startup message

> I should think that in such cases, the end client is exactly not what you > want to be choosing which server it gets redirected to. You'd be wanting to > base that on >policies defined at the pooler. There are already plenty of > client-supplied attributes you could use as inputs for such

Re: [HACKERS] Logical replication launcher never been restarted when terminated

On 6/21/17 13:03, Yugo Nagata wrote: > As I report in another thread[1], when the logical replication launcher > is terminated by SIGTERM, it never been restarted and we need to restart > the server to enable logical replication again. > > This is because the logical replication launcher exits

Re: [HACKERS] Adding connection id in the startup message

On Thu, Jun 15, 2017 at 9:50 AM, Tom Lane wrote: > Can you give a concrete example where this would have > helped above and beyond knowing, eg, the source and time of the connection > attempt? I can imagine that in really high-volume use cases (such as the OP apparently has)

Re: [HACKERS] Adding connection id in the startup message

On Thu, Jun 15, 2017 at 3:11 AM, Satyanarayana Narlapuram wrote: > The proposal is to tweak the connectivity wire protocol, and add a > connection id (GUID) filed in the startup message. We can trace the > connection using this GUID and investigate further

[HACKERS] GSoC 2017 Proposal for predicate locking in hash index

Hi, Now that hash index support write-ahead logging, it will be great if we add support for predicate locking to it. Implementation of predicate locking in hash index seems very simple. I have already made changes in the code. I am currently working on testing. Here is my approach 1)

Re: [HACKERS] pg_bsd_indent 2.0 is available from git.postgresql.org

On 06/21/2017 02:25 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 06/21/2017 11:30 AM, Tom Lane wrote: >>> Andrew Dunstan writes: Unfortunately this seems precluded by the use of the non-standard "err.h". It looks

Re: [HACKERS] Logical replication: stuck spinlock at ReplicationSlotRelease

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 apply worker > for

Re: [HACKERS] pg_bsd_indent 2.0 is available from git.postgresql.org

Andrew Dunstan writes: > On 06/21/2017 11:30 AM, Tom Lane wrote: >> Andrew Dunstan writes: >>> Unfortunately this seems precluded by the use of the non-standard >>> "err.h". It looks like that will trip us up on mingw also. >> Hm,

Re: [HACKERS] pg_bsd_indent 2.0 is available from git.postgresql.org

On 06/21/2017 11:30 AM, Tom Lane wrote: > Andrew Dunstan writes: >> Unfortunately this seems precluded by the use of the non-standard >> "err.h". It looks like that will trip us up on mingw also. > Hm, why? Doesn't the -I search path get the right thing? > >

Re: [HACKERS] CREATE SUBSCRIPTION log noise

On 6/20/17 22:54, Jeff Janes wrote: > I think this should go away: > > ereport(NOTICE, > (errmsg("created replication slot \"%s\" on > publisher", > slotname))); > > It doesn't appear to be contingent on anything other than the

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

Hi, When doing a PITR style recovery, with recovery target set, we're currently not doing a fast promotion, in contrast to the handling when doing a pg_ctl or trigger file based promotion. That can prolong making the server available for writes. I can't really see a reason for this? Greetings,

[HACKERS] archive_timeout ignored directly after promotion

Hi, When promoting a standby without using the "fast promotion" logic, e.g. by using recovery targets (which doesn't use fast promotion for unbeknownst to me reasons), checkpointer doesn't necessarily respect archive timeout for the first cycle after promotion. The reason for that is that it

Re: [HACKERS] UPDATE of partition key

On 21 June 2017 at 20:14, Robert Haas wrote: > On Wed, Jun 21, 2017 at 5:28 AM, Amit Langote > wrote:>> The comment "UPDATE/DELETE > cases are handled above" is referring to >>> the code that initializes the WCOs generated by the planner.

Re: [HACKERS] UPDATE of partition key

On 21 June 2017 at 00:23, Robert Haas wrote: > On Tue, Jun 20, 2017 at 2:54 AM, Amit Khandekar > wrote: >>> I guess I don't see why it should work like this. In the INSERT case, >>> we must build withCheckOption objects for each partition because

[HACKERS] Logical replication launcher never been restarted when terminated

Hi, As I report in another thread[1], when the logical replication launcher is terminated by SIGTERM, it never been restarted and we need to restart the server to enable logical replication again. This is because the logical replication launcher exits with exitstatus 0, so if it exits with

Re: [HACKERS] initdb initalization failure for collation "ja_JP"

On 20/06/2017 17:37, Tom Lane wrote: I wrote: Marco Atzeri writes: Building on Cygwin latest 10 beta1 or head sourece, make check fails as: ... performing post-bootstrap initialization ... 2017-05-31 23:23:22.214 CEST [16860] FATAL: collation "ja_JP" for encoding

Re: [HACKERS] Incorrect documentation about pg_stat_activity

On Wed, 21 Jun 2017 16:18:50 +0200 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

Re: [HACKERS] Broken hint bits (freeze)

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 knowledgeable as you are, so if they make any > >

Re: [HACKERS] Autovacuum launcher occurs error when cancelled by SIGINT

On Wed, Jun 21, 2017 at 7:52 PM, Dilip Kumar wrote: > On Wed, Jun 21, 2017 at 7:47 PM, Kuntal Ghosh > wrote: >>> IMHO, It's not a good idea to use DSM call to verify the DSA handle. >>> >> Okay. Is there any particular scenario you've in mind

Re: [HACKERS] Shortened URLs for commit messages

On Wed, Jun 21, 2017 at 11:11:57AM -0400, Alvaro Herrera wrote: > Bruce Momjian wrote: > > > Oh, here is a fixed version that requires an @ sign, which all message > > id's have: > > > > sed '/http/!s;^\(Discussion: *\)\(.*@.*\)$;\1https://postgr.es/m/\2;' > > So how do you actually use

Re: [HACKERS] pg_bsd_indent 2.0 is available from git.postgresql.org

Andres Freund writes: > On 2017-06-20 20:30:34 -0400, Tom Lane wrote: >> Well, *I* don't care, but I thought we wanted to support Windows-using >> developers as reasonably first-class citizens. > The old one didn't have windows support either, right? Not that I was aware of,

Re: [HACKERS] pg_bsd_indent 2.0 is available from git.postgresql.org

On 2017-06-20 20:30:34 -0400, Tom Lane wrote: > Michael Paquier writes: > > On Wed, Jun 21, 2017 at 8:43 AM, Tom Lane wrote: > >> Yeah, I thought it would work fine with Makefile-using Windows toolchains. > >> But people who use MSVC need something

Re: [HACKERS] Useless code in ExecInitModifyTable

Robert Haas writes: > It appears to me that create_modifytable_path() has a partitioned_rels > argument and it looks like inheritance_planner not only passes it but > guarantees that it's non-empty when the target is a partitioned table. Oh, somehow I missed the call in

Re: [HACKERS] pg_bsd_indent 2.0 is available from git.postgresql.org

Andrew Dunstan writes: > Unfortunately this seems precluded by the use of the non-standard > "err.h". It looks like that will trip us up on mingw also. Hm, why? Doesn't the -I search path get the right thing? regards, tom lane -- Sent

Re: [HACKERS] Default Partition for Range

On Wed, Jun 21, 2017 at 8:08 PM, Robert Haas wrote: > I think somebody should do some testing of the existing code with > valgrind. And then apply the list-partitioning patch and this patch, > and do some more testing with valgrind. It seems to be really easy to > miss

Re: [HACKERS] Shortened URLs for commit messages

Bruce Momjian wrote: > Oh, here is a fixed version that requires an @ sign, which all message > id's have: > > sed '/http/!s;^\(Discussion: *\)\(.*@.*\)$;\1https://postgr.es/m/\2;' So how do you actually use this? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL

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

Yugo Nagata wrote: > However, we can terminate background workers by pg_terminate_backend. > In the following example, I terminated the logical replication launcher, > and this process did not appear again[1]. > > postgres=# select pg_terminate_backend(30902); > pg_terminate_backend >

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

On Wed, Jun 21, 2017 at 7:56 AM, Yugo Nagata wrote: > I have found that we can cancel/terminate autovacuum launchers and > background worker processes by pg_cancel/terminate_backend function. > I'm wondering this behavior is not expected and if not I want to fix it. I think

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Fri, May 19, 2017 at 11:12 AM, Masahiko Sawada wrote: > On Wed, May 17, 2017 at 1:30 AM, Robert Haas wrote: >> On Sat, May 13, 2017 at 7:27 AM, Amit Kapila wrote: >>> On Fri, May 12, 2017 at 9:14 AM, Tom Lane

Re: [HACKERS] Useless code in ExecInitModifyTable

On Wed, Jun 21, 2017 at 10:33 AM, Tom Lane wrote: > Amit Langote writes: >> On 2017/06/21 16:59, Etsuro Fujita wrote: >>> but I noticed that that function doesn't use the relation descriptor at >>> all. Since partitioned_rels is given in case

Re: [HACKERS] UPDATE of partition key

On Wed, Jun 21, 2017 at 5:28 AM, Amit Langote wrote:>> The comment "UPDATE/DELETE cases are handled above" is referring to >> the code that initializes the WCOs generated by the planner. You've >> modified the comment in your patch, but the associated code: your >>

  1   2   >