Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to a specific backend

On Wed, 28 Jun 2017 13:35:12 +0200 Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On 28 June 2017 at 12:17, Yugo Nagata wrote: > > > > Hi, > > > > Attached is a patch of pg_reload_backend that is a function signaling > > SIGHUP to a specific backend. The original idea is

Re: [HACKERS] Reducing pg_ctl's reaction time

Jeff Janes writes: > In the now-committed version of this, the 'pg_ctl start' returns > successfully as soon as the server reaches a consistent state. Which is OK, > except that it does the same thing when hot_standby=off. When > hot_standby=off, I would expect it to wait

Re: [HACKERS] UPDATE of partition key

On 22 June 2017 at 01:41, Robert Haas wrote: >>> +for (i = 0; i < num_rels; i++) >>> +{ >>> +ResultRelInfo *resultRelInfo = _rels[i]; >>> +Relationrel = resultRelInfo->ri_RelationDesc; >>> +Bitmapset *expr_attrs = NULL; >>> + >>>

Re: [HACKERS] Reducing pg_ctl's reaction time

On June 29, 2017 10:19:46 AM PDT, Jeff Janes wrote: >On Tue, Jun 27, 2017 at 11:59 AM, Tom Lane wrote: > >> I wrote: >> > Andres Freund writes: >> >> On 2017-06-26 17:38:03 -0400, Tom Lane wrote: >> >>> Hm. Take that a bit

Re: [HACKERS] Reducing pg_ctl's reaction time

On Thu, Jun 29, 2017 at 11:39 AM, Tom Lane wrote: > Jeff Janes writes: > > In the now-committed version of this, the 'pg_ctl start' returns > > successfully as soon as the server reaches a consistent state. Which is > OK, > > except that it does the

Re: [HACKERS] gen_random_uuid security not explicit in documentation

On Sun, Jun 25, 2017 at 09:26:28PM -0700, Noah Misch wrote: > On Fri, Jun 23, 2017 at 10:23:36AM +0900, Michael Paquier wrote: > > On Fri, Jun 23, 2017 at 3:02 AM, Heikki Linnakangas wrote: > > > I'm inclined to change gen_random_uuid() to throw an error if the server > > > is >

Re: [HACKERS] Broken hint bits (freeze)

On Wed, Jun 28, 2017 at 10:11:35PM -0400, Bruce Momjian wrote: > On Fri, Jun 23, 2017 at 06:17:47PM +0300, Sergey Burladyan wrote: > > PS: > > I successfully upgraded last night from 9.2 to 9.4 and find other issue :-) > > > > It is about hash index and promote: > > 1. create master > > 2. create

Re: [HACKERS] Apparent walsender bug triggered by logical replication

Petr Jelinek writes: > On 30/06/17 02:07, Tom Lane wrote: >> I'm also kind of wondering why the "behind the apply" path out of >> LogicalRepSyncTableStart exists at all; as far as I can tell we'd be much >> better off if we just let the sync worker exit always as

[HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

Hackers, In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not allow a parallel plan if a portal will be returned. This has the practical consequence that a common coding practice (at least for me) of doing something like: create function myfunc(arg1 text, arg2 text) returns

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

Noah Misch wrote: > On Wed, Jun 28, 2017 at 06:52:14PM -0400, Alvaro Herrera wrote: > > I think I'm done with the walsender half of this patch; I still need to > > review the walreceiver part. I will report back tomorrow 19:00 CLT. > > This PostgreSQL 10 open item is past due for your status

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

On Wed, Jun 28, 2017 at 06:52:14PM -0400, Alvaro Herrera wrote: > I think I'm done with the walsender half of this patch; I still need to > review the walreceiver part. I will report back tomorrow 19:00 CLT. This PostgreSQL 10 open item is past due for your status update. Kindly send a status

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger wrote: > Hackers, > > In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not > allow a parallel plan if a portal will be returned. This has the practical > consequence that a common coding practice (at least

Re: [HACKERS] Apparent walsender bug triggered by logical replication

On 30/06/17 02:07, Tom Lane wrote: > I'm also kind of wondering why the "behind the apply" path out of > LogicalRepSyncTableStart exists at all; as far as I can tell we'd be much > better off if we just let the sync worker exit always as soon as it's done > the initial sync, letting any extra

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On 29 June 2017 at 20:18, Robert Haas wrote: > I'm not sure if non-critical is exactly the right terminology. What > we want to do is distinguish between things that are intended as > protocol-level options vs. things that are intended as GUCs. We probably also need to

Re: [HACKERS] Code quality issues in ICU patch

On Sun, Jun 25, 2017 at 09:28:51PM -0700, Noah Misch wrote: > On Sat, Jun 24, 2017 at 10:03:25AM -0400, Peter Eisentraut wrote: > > On 6/23/17 12:31, Tom Lane wrote: > > > icu_to_uchar() and icu_from_uchar(), and perhaps other places, are > > > touchingly naive about integer overflow hazards in

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

On Wed, Jun 28, 2017 at 03:22:18AM +, Noah Misch wrote: > 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. > >

Re: [HACKERS] Causal reads take II

On Tue, Jun 27, 2017 at 12:20 PM, Thomas Munro wrote: > On Sun, Jun 25, 2017 at 2:36 AM, Simon Riggs wrote: >> What I think we need is a joined up plan for load balancing, so that >> we can understand how it will work. i.e. explain the whole

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Jun 29, 2017, at 9:14 PM, Amit Kapila wrote: > > On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger wrote: >> Hackers, >> >> In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not >> allow a parallel plan if a portal will be

Re: [HACKERS] gen_random_uuid security not explicit in documentation

On 30 June 2017 06:45:04 EEST, Noah Misch wrote: >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. I'll fix this some time next week. (I'm on vacation

Re: [HACKERS] Apparent walsender bug triggered by logical replication

Hi, On 2017-06-29 20:07:14 -0400, Tom Lane wrote: > I was able to make the hang go away by means of the attached patch that > allows WalSndWaitForWal to exit early if the client has shut down the > COPY. However, since that function is miserably underdocumented (like > most of this code :-(), I

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

-Original Message- From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas Sent: Thursday, June 29, 2017 5:18 AM To: Tom Lane Cc: Craig Ringer ; Peter Eisentraut ; Magnus

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On 06/25/17 21:20, Chapman Flack wrote: > I want to make sure I understand what the deadlock potential is > in this case. AdvanceXLInsertBuffer will call WaitXLogInsertionsToFinish > ... > Does not the fact we hold all the insertion slots exclude the possibility > that any dirty buffer (preceding

[HACKERS] Apparent walsender bug triggered by logical replication

I've been poking into the src/test/subscription TAP tests, thinking that they seem a lot slower than they ought to be. The first thing I came across was this bit in WaitForReplicationWorkerAttach(): /* * We need timeout because we generally don't get notified via latch

Re: [HACKERS] Dumping database creation options and ACLs

On 12/08/2014 04:21 PM, Ronan Dunklau wrote: > Hello. > > As of now, the only way to restore database options and ACLs is to use > pg_dumpall without the globals options. The often recommended pg_dumpall -g + > individual dumps of the target databases doesn't restore those. > > Since

Re: [HACKERS] Reducing pg_ctl's reaction time

On Tue, Jun 27, 2017 at 11:59 AM, Tom Lane wrote: > 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

[HACKERS] Start logical decoding from any lsn present in the wal segment

Hi, Currently logical decoding finds a consistent point by generating a snapshot and stream changes after consistent point.I want to change this behaviour to something which stream changes from a lsn in the past provided its present in wal segment.Can this behaviour be implemented and if yes,

Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to a specific backend

On Wed, 28 Jun 2017 13:59:51 +0200 Remi Colinet wrote: > Hi Yugo, > > The patch looks fine. Installed and tested. Thank you for your interest. > > But a similar function already exists for the Postmaster process. > > Datum > pg_reload_conf(PG_FUNCTION_ARGS) > { >

Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to a specific backend

> On 29 Jun 2017 08:18, "Yugo Nagata" wrote: > > This is because this function is defined as strict Yes, I realized that few moments after I sent my message. > Arg type is needed. > > =# grant execute on function pg_reload_backend(int) to test_user; Oh, I see, thank you.

Re: [HACKERS] What does it mean by XLOG_BACKUP_RECORD?

On Thu, Jun 29, 2017 at 10:49 AM, Michael Paquier wrote: > On Thu, Jun 29, 2017 at 10:28 AM, Masahiko Sawada > wrote: >> While reading source codes I found the following comment in xlog.c. >> >> /* >> * Have we passed our safe starting point?

Re: [HACKERS] Start logical decoding from any lsn present in the wal segment

On 29 June 2017 at 16:32, sanyam jain wrote: > Hi, > > Currently logical decoding finds a consistent point by generating a snapshot > and stream changes after consistent point.I want to change this behaviour to > something which stream changes from a lsn in the past provided

Re: protocol version negotiation (Re: [HACKERS] Libpq PGRES_COPY_BOTH - version compatibility)

On Wed, Jun 28, 2017 at 10:27 PM, Tom Lane wrote: > Yeah. Back in the day I helped design the PNG image format, and one > of the better ideas in it was to make a distinction between critical and > noncritical chunks within a PNG file; that was exactly the idea you're >

[HACKERS] Add support for tuple routing to foreign partitions

Hi, Here is a patch for $subject. This is based on Amit's original patch (patch '0007-Tuple-routing-for-partitioned-tables-15.patch' in [1]). Main changes are: * I like Amit's idea that for each partition that is a foreign table, the FDW performs query planning in the same way as in

Re: [HACKERS] Declarative partitioning - another take

Hi Maksim, On 2017/04/07 19:52, Maksim Milyutin wrote: On 07.04.2017 13:05, Etsuro Fujita wrote: On 2016/12/09 19:46, Maksim Milyutin wrote: I would like to work on two tasks: - insert (and eventually update) tuple routing for foreign partition. - the ability to create an index on the

Re: [HACKERS] UPDATE of partition key

On 29 June 2017 at 07:42, Amit Langote wrote: > Hi Amit, > > On 2017/06/28 20:43, Amit Khandekar wrote: >> In attached patch v12 > > The patch no longer applies and fails to compile after the following > commit was made yesterday: > > commit

Re: [HACKERS] Segmentation fault in libpq

Hi, comments inline ... On 06/29/2017 03:08 PM, Merlin Moncure wrote: On Thu, Jun 29, 2017 at 4:01 AM, Michal Novotny wrote: Hi all, we've developed an application using libpq to access a table in the PgSQL database but we're sometimes experiencing

Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

On Thu, Jun 22, 2017 at 6:22 PM, Masahiko Sawada wrote: > On Thu, Jun 22, 2017 at 10:36 PM, Magnus Hagander > wrote: > > > > > > On Thu, Jun 22, 2017 at 10:12 AM, Masahiko Sawada > > > wrote: > >> > >> Hi, > >> > >> Since an

Re: [HACKERS] Segmentation fault in libpq

On Thu, Jun 29, 2017 at 8:23 AM, Michal Novotny wrote: > Hi, > > comments inline ... > > > > On 06/29/2017 03:08 PM, Merlin Moncure wrote: >> >> On Thu, Jun 29, 2017 at 4:01 AM, Michal Novotny >> wrote: >>> >>> Hi all, >>> >>> we've

Re: [HACKERS] Segmentation fault in libpq

On Thu, Jun 29, 2017 at 4:01 AM, Michal Novotny wrote: > Hi all, > > we've developed an application using libpq to access a table in the PgSQL > database but we're sometimes experiencing segmentation fault on > resetPQExpBuffer() function of libpq called from

[HACKERS] Segmentation fault in libpq

Hi all, we've developed an application using libpq to access a table in the PgSQL database but we're sometimes experiencing segmentation fault on resetPQExpBuffer() function of libpq called from PQexecParams() with prepared query. PostgreSQL version is 9.6.3 and the backtrace is: Core was

Re: [HACKERS] Causal reads take II

On Sat, Jun 24, 2017 at 4:05 PM, Thomas Munro wrote: > On Fri, Jun 23, 2017 at 11:48 PM, Thomas Munro > wrote: >> Maybe it needs a better name. > > Ok, how about this: the feature could be called "synchronous replay". > The new column

Re: [BUGS] [HACKERS] Segmentation fault in libpq

Merlin Moncure writes: > On Thu, Jun 29, 2017 at 8:23 AM, Michal Novotny > wrote: >> Could you please help me based on information provided above? > You might want to run your code through some analysis tools (for > example, valgrind). Yeah,

Re: [BUGS] [HACKERS] Segmentation fault in libpq

On Thu, Jun 29, 2017 at 9:12 AM, Tom Lane wrote: > Merlin Moncure writes: >> On Thu, Jun 29, 2017 at 8:23 AM, Michal Novotny >> wrote: >>> Could you please help me based on information provided above? > >> You might want to