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
> 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
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
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
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
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
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
>
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
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.
> >
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
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
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
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
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
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
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
-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
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
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;
>>> +
>>>
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
>
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
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
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
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?
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
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,
> 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.
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)
> {
>
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
42 matches
Mail list logo