On 3 January 2017 at 23:22, Thomas Munro wrote:
>> I don't see why that would be unacceptable. If we do it for
>> remote_apply, why not also do it for other modes? Whatever the
>> reasoning was for remote_apply should work for other modes. I should
>> add it was originally designed to be that way
Server crash(failed assertion) when two "insert" in one SQL:
Step to reproduce:
create table t(a int, b int) partition by range(a);
create table t_p1 partition of t for values from (1) to (100);
create table t_p2 partition of t for values from (100) to (200);
create table t_p3 partition of t for v
On Wed, Jan 4, 2017 at 12:48 AM, Robert Haas wrote:
> On Sun, Jan 1, 2017 at 4:38 AM, Thomas Munro
> wrote:
>> To be able to do this, the patch modifies the isolation tester so that
>> it recognises wait_event SafeSnapshot.
>
> I'm not going to say that's unacceptable, but it's certainly not beau
On Mon, Dec 26, 2016 at 3:14 PM, Dilip Kumar wrote:
> Other the another option is, that we can always make caller to provide
> an allocator. But this way every new user for simple hash need to take
> care of having allocator.
>
> What is your opinion?
Attached is the new version of the patch whic
On Tue, Jan 3, 2017 at 8:41 PM, Michael Paquier
wrote:
> On Mon, Jan 2, 2017 at 2:15 AM, Fabrízio de Royes Mello
> wrote:
>> I changed the status to "In Progress".
>
> Thanks for covering my absence.
To all hackers,
Commit fest 2017-01 has now officially begun. With this commit fest
included, t
On Wed, Jan 4, 2017 at 1:23 PM, Ashutosh Bapat
wrote:
> I don't have anything more to review in this patch. I will leave that
> commitfest entry in "needs review" status for few days in case anyone
> else wants to review it. If none is going to review it, we can mark it
> as "ready for committer".
On Wed, Dec 21, 2016 at 9:23 PM, Dilip Kumar wrote:
> On Wed, Dec 21, 2016 at 8:39 PM, Robert Haas wrote:
>> Committed the refactoring patch with some mild cosmetic adjustments.
>
> Thanks..
>>
>> As to the second patch:
>>
>> +if (jointype == JOIN_UNIQUE_INNER)
>> +jointype =
At 2017-01-03 18:46:32 +0100, mag...@hagander.net wrote:
>
> Thoughts?
I think we should stop making wholesale changes to copyright notices
every year.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
On Wed, Jan 4, 2017 at 10:37 AM, Amit Langote wrote:
> On 2017/01/03 19:04, Rajkumar Raghuwanshi wrote:
> > On Tue, Dec 27, 2016 at 3:24 PM, Amit Langote wrote:
> >>
> >> Attached patch should fix the same.
> >
> > I have applied attached patch, server crash for range is fixed, but still
> > gett
On Tue, Jan 3, 2017 at 11:36 PM, Andrew Borodin wrote:
> 2017-01-03 19:39 GMT+05:00 Peter Eisentraut
> :
>>
>> On 1/3/17 1:26 AM, amul sul wrote:
>> > One more requirement for pg_background is session, command_qh,
>> > response_qh and worker_handle should be last longer than current
>> > memory co
On Tue, Jan 3, 2017 at 10:09 PM, Robert Haas wrote:
> On Tue, Jan 3, 2017 at 12:06 AM, Ashutosh Bapat
> wrote:
>> Instead of changing get_object_address_unqualified(),
>> get_object_address_unqualified() and pg_get_object_address(), should
>> we just stick get_database_name(MyDatabaseId) as objec
On 2017/01/03 19:04, Rajkumar Raghuwanshi wrote:
> On Tue, Dec 27, 2016 at 3:24 PM, Amit Langote wrote:
>>
>> Attached patch should fix the same.
>
> I have applied attached patch, server crash for range is fixed, but still
> getting crash for multi-level list partitioning insert.
>
> postgres=#
On Tue, Jan 3, 2017 at 9:18 PM, Peter Eisentraut
wrote:
> On 12/30/16 9:28 PM, Fabrízio de Royes Mello wrote:
>> The attached patch is reworked from a previous one [1] to better deal
>> with get_object_address and pg_get_object_address.
>>
>> Regards,
>>
>> [1] https://www.postgresql.org/message-i
On Tue, Jan 3, 2017 at 6:40 PM, Fabrízio de Royes Mello
wrote:
> Hi Ashutosh,
>
> First of all thanks for your review.
>
>
> On Tue, Jan 3, 2017 at 3:06 AM, Ashutosh Bapat
> wrote:
>>
>> The patch has white space error
>> git apply /mnt/hgfs/tmp/comment_on_current_database_v1.patch
>> /mnt/hgfs/t
On 3 January 2017 at 12:36, Craig Ringer wrote:
> On 2 January 2017 at 20:17, Simon Riggs wrote:
>
>> Bit confused... can't see a caller for wait_for_slot_catchup() and the
>> slot tests don't call it AFAICS.
>
> The recovery tests for decoding on standby will use it. I can delay
> adding it unti
On Tue, Jan 3, 2017 at 5:57 PM, Rahila Syed wrote:
> Thank you all for inputs.
> Kindly help me clarify the scope of the patch.
>
>>However, I thought the idea was to silently coerce affected columns from
>>unknown to text. This doesn't look like the behavior we want:
>
> This patch prevents crea
On Tue, Jan 3, 2017 at 5:38 PM, Michael Paquier
wrote:
> On Tue, Jan 3, 2017 at 8:41 PM, Ashutosh Bapat
> wrote:
>> Are you talking about
>> /*
>> * Now we can mark ourselves as out of the commit critical section: a
>> * checkpoint starting after this will certainly see the gxact as
On 4 January 2017 at 12:08, Craig Ringer wrote:
>
> 0001 incorporates the changes requested by Michael Paquier. Simon
> expressed his intention to commit this after updates, in the separate
> thread [...]
...
> 0005 (new streaming rep tests) is updated for the changes in 0001,
> otherwise unchan
On Fri, Dec 30, 2016 at 1:02 PM, Tom Lane wrote:
> Haribabu Kommi writes:
> > Attached a patch that replaces most of the getimeofday function calls,
> > except timeofday(user callable) and GetCurrentTimestamp functions.
>
> I looked at this for awhile and could not convince myself that it's
> a
On Tue, Nov 29, 2016 at 9:15 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Here's backtrace and some debugging information
> Program terminated with signal 11, Segmentation fault.
> #0 0x007f96cd in shm_mq_sendv (mqh=0x121e998,
> iov=0x7ffc9b7b79f0, iovcnt=2, nowait=1 '\0
On Wed, Jan 4, 2017 at 3:47 AM, Jim Nasby wrote:
> On 1/2/17 9:47 PM, Tom Lane wrote:
>> Correct coding would be
>>
>> volatile TupleDesc desc = slot->tts_tupleDescriptor;
>> CallbackState * volatile myState = (CallbackState *) self;
>> PLyTypeInfo * volatile args = myState->args;
>>
On 3 January 2017 at 21:32, valeriof wrote:
> Craig Ringer-3 wrote
>> Take a look at how pglogical does it in its replication set handling
>> and relation metadata cache.
>
> I checked it out but for what I understand it uses the inline parameter.
It specifies which replication sets to use with l
On 3 January 2017 at 05:37, Jim Nasby wrote:
> The recent thread about compiler warnings got me thinking about how it's
> essentially impossible to notice warnings with default make output. Perhaps
> everyone just uses make -s by default, though that's a bit annoying since
> you get no output unle
Tom Lane [mailto:t...@sss.pgh.pa.us] wrote:
>> 2. If the folding mode is chosen through a GUC variable, which
>> is certainly what people would expect, then it turns out that
>> it breaks client libraries/applications *anyway*, because an
>> installation-wide setting could impose itself on a client
On Tue, Jan 3, 2017 at 11:09 PM, Heikki Linnakangas wrote:
> Since not everyone agrees with this approach, I split this patch into two.
> The first patch refactors things, replacing the isMD5() function with
> get_password_type(), without changing the representation of
> pg_authid.rolpassword. Tha
"Lewis, Ian \(Microstar Laboratories\)" writes:
> One idea, which would likely be harder to implement on the server, but
> that would have less impact on third party tools and libraries, would be
> to configure case folding on a session basis.
There are a couple of problems even with that:
1. Al
I wrote:
> After looking a bit at gist and sp-gist, neither of them would find that
> terribly convenient; they really want to create one blob of memory per
> index entry so as to not complicate storage management too much. But
> they'd be fine with making that blob be a HeapTuple not IndexTuple.
On Tue, Dec 20, 2016 at 5:14 PM, Peter Geoghegan wrote:
>> Imagine a data structure that is stored in dynamic shared memory and
>> contains space for a filename, a reference count, and a mutex. Let's
>> call this thing a SharedTemporaryFile or something like that. It
>> offers these APIs:
>>
>>
Robert Haas [mailto:robertmh...@gmail.com] wrote:
> The issue is, rather, that every extension written for
> PostgreSQL, whether in or out of core, needs to handle this issue and
> every general-purpose client tool (pgAdmin, etc.) needs to be aware of
> it.
I can see the accuracy of all of th
On Wed, Jan 4, 2017 at 12:22 PM, Thomas Munro
wrote:
> (replay_lag - (write_lag / 2) may be a cheap proxy
> for a lag time that doesn't include the return network leg, and still
> doesn't introduce clock difference error)
(Upon reflection it's a terrible proxy for that because of the mix of
write
On Wed, Jan 4, 2017 at 12:22 PM, Thomas Munro
wrote:
> The patch streams (time-right-now, end-of-wal) to the standby in every
> outgoing message, and then sees how long it takes for those timestamps
> to be fed back to it.
Correction: we already stream (time-right-now, end-of-wal) to the
standby
On Wed, Jan 4, 2017 at 1:06 AM, Simon Riggs wrote:
> On 21 December 2016 at 21:14, Thomas Munro
> wrote:
>> I thought about that too, but I couldn't figure out how to make the
>> sampling work. If the primary is choosing (LSN, time) pairs to store
>> in a buffer, and the standby is sending repli
On 01/03/2017 01:34 PM, Michael Paquier wrote:
On Mon, Jan 2, 2017 at 10:55 PM, Simon Riggs wrote:
In the hope of making things better in 10.0, I remove my objection.
If people want to use wal_level = minimal they can restart their
server and they can find that out in the release notes.
Should
Hi,
On 12/31/2016 04:00 PM, Magnus Hagander wrote:
Cycling back to this topic again, but this time at the beginning of a CF.
Here's an actual patch to change:
wal_level=replica
max_wal_senders=10
max_replication_slots=20
Based on feedback from last year
(https://www.postgresql.org/message-id
On 1/2/17 2:01 PM, Greg Stark wrote:
The PostGIS extensions might not work on
your system with different case rules if they haven't been 100%
consistent with their camelCasing
FWIW I've already run into a similar problem with inter-extension
dependencies and relocatability. I've found hacks to
On 03/01/17 20:39, Peter Eisentraut wrote:
> In 0001-Add-PUBLICATION-catalogs-and-DDL-v16.patch.gz,
>
> +static bool
> +is_publishable_class(Oid relid, Form_pg_class reltuple)
> +{
> + return reltuple->relkind == RELKIND_RELATION &&
> + !IsCatalogClass(relid, reltuple) &&
> +
Tom Lane wrote:
> A little bit of "git bisect"-ing later, the blame is pinned on
>
> commit 9550e8348b7965715789089555bb5a3fda8c269c
> Author: Alvaro Herrera
> Date: Fri Apr 3 17:33:05 2015 -0300
>
> Transform ALTER TABLE/SET TYPE/USING expr during parse analysis
>
> This lets la
On 1/2/17 9:47 PM, Tom Lane wrote:
Jim Nasby writes:
In the attached patch (snippet below), I'm seeing something strange with
args->in.r.atts[].
Did you try comparing the apparent values of "args" before and after
entering PG_TRY?
Yeah, see below. FWIW, when I did that just now I stepped th
Robert Haas writes:
> The only point I'm making here is that the width of a spinlock is not
> irrelevant.
Sure, but it does not follow that we need to get all hot and bothered
about the width of pg_atomic_flag, which has yet to find its first
use-case. When and if its width becomes a demonstrabl
On 1/2/17 4:37 PM, Jim Nasby wrote:
> The recent thread about compiler warnings got me thinking about how it's
> essentially impossible to notice warnings with default make output.
I always build with -Werror.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development,
On 12/30/2016 02:12 PM, Petr Jelinek wrote:
On 12/12/16 22:50, Tomas Vondra wrote:
On 12/12/2016 12:26 PM, Amit Langote wrote:
Hi Tomas,
On 2016/10/30 4:23, Tomas Vondra wrote:
Hi,
Attached is v20 of the multivariate statistics patch series, doing
mostly
the changes outlined in the precedin
On 1/3/17 2:39 PM, Peter Eisentraut wrote:
> In 0001-Add-PUBLICATION-catalogs-and-DDL-v16.patch.gz,
Attached are a couple of small fixes for this. Feel free to ignore the
removal of the header files if they are needed by later patches.
--
Peter Eisentraut http://www.2ndQuadrant.com
I wrote:
> Hah:
> regression=# create table p(f1 int);
> CREATE TABLE
> regression=# create table c1(extra smallint) inherits(p);
> CREATE TABLE
> regression=# alter table p add column f2 int;
> ALTER TABLE
> regression=# insert into c1 values(1,2,3);
> INSERT 0 1
> regression=# alter table p alte
On Tue, Jan 3, 2017 at 3:38 PM, Simon Riggs wrote:
> On 3 January 2017 at 16:24, Robert Haas wrote:
>> On Jan 3, 2017 at 11:16 AM, Simon Riggs wrote:
>>> On 3 January 2017 at 15:44, Robert Haas wrote:
Yeah. I don't think there's any way to get around the fact that there
will be bigge
On Tue, Jan 3, 2017 at 12:07 PM, Tom Lane wrote:
> [ shrug... ] I have not seen you putting any effort into optimizing
> slock_t on non-x86 architectures, where it might make a difference today.
> Why all the concern about shaving hypothetical future bytes for
> pg_atomic_flag?
I don't know what
Justin Pryzby writes:
> On Tue, Jan 03, 2017 at 03:35:34PM -0500, Tom Lane wrote:
>> Right. So I bet that if you check the attnum of pmsumpacketlatency_000 in
>> eric_umts_rnc_utrancell_metrics, you'll find it's different from that in
>> eric_umts_rnc_utrancell_201701, and that the attribute havi
Jim Nasby writes:
> The attached hack doesn't quiet everything, but makes a significant
> difference, 1588 lines down to 622, with 347 being make -C (each of
> those was a make -j4 after a make clean).
> If folks are interested in this I can look at quieting the remaining
> output. My intentio
On 1/2/17 3:57 PM, Tom Lane wrote:
Jim Nasby writes:
The recent thread about compiler warnings got me thinking about how it's
essentially impossible to notice warnings with default make output.
Perhaps everyone just uses make -s by default, though that's a bit
annoying since you get no output u
On Tue, Jan 03, 2017 at 03:35:34PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote:
> >> I'm wondering if this represents some sort of out-of-sync condition
> >> between the table and its child tables. We can't actually tell from
> >> th
On 3 January 2017 at 16:24, Robert Haas wrote:
> On Jan 3, 2017 at 11:16 AM, Simon Riggs wrote:
>> On 3 January 2017 at 15:44, Robert Haas wrote:
>>> Yeah. I don't think there's any way to get around the fact that there
>>> will be bigger latency spikes in some cases with larger WAL files.
>>
>
Justin Pryzby writes:
> On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote:
>> I'm wondering if this represents some sort of out-of-sync condition
>> between the table and its child tables. We can't actually tell from
>> this trace which table is being processed. Could you try, from this
>
On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > (gdb) bt
> > #3 0x0059d5ce in ATRewriteTable (tab=,
> > OIDNewHeap=, lockmode=) at
> > tablecmds.c:4152
>
> I'm wondering if this represents some sort of out-of-sync condition
> between the table and
I wrote:
> I'm wondering if this represents some sort of out-of-sync condition
> between the table and its child tables.
Hah:
regression=# create table p(f1 int);
CREATE TABLE
regression=# create table c1(extra smallint) inherits(p);
CREATE TABLE
regression=# alter table p add column f2 int;
ALTE
Justin Pryzby writes:
> (gdb) bt
> #0 errfinish (dummy=0) at elog.c:414
> #1 0x005d0e30 in ExecEvalScalarVar (exprstate=,
> econtext=, isNull=, isDone= optimized out>) at execQual.c:655
> #2 0x005d0c3c in ExecMakeFunctionResultNoSets (fcache=0x21f18a0,
> econtext=0x2199e80, is
2017-01-03 20:54 GMT+01:00 Merlin Moncure :
> On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule
> wrote:
> > 2017-01-03 16:23 GMT+01:00 Merlin Moncure :
> >> So -1 to strict mode, unless we can make a case why this can't be done
> >> as part of checking/validation.
> >
> > Can be plpgsq.extra_errors
2017-01-03 20:56 GMT+01:00 Fabien COELHO :
>
> Hello,
>
> Probably there is not big difference between RESET and UNDO in complexity
>> of implementation. You have to do partial implementation of MVCC. No
>> simple
>> code.
>>
>
> I think so; yes; indeed.
>
> Also note that user-defined GUCs alread
On Tue, Jan 03, 2017 at 02:50:21PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
> >> 2. Even better would be a stack trace for the call to errfinish,
> >> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backe
Hello,
Probably there is not big difference between RESET and UNDO in complexity
of implementation. You have to do partial implementation of MVCC. No simple
code.
I think so; yes; indeed.
Also note that user-defined GUCs already implements the transactional
property, so probably the mecanis
On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule wrote:
> 2017-01-03 16:23 GMT+01:00 Merlin Moncure :
>> So -1 to strict mode, unless we can make a case why this can't be done
>> as part of checking/validation.
>
> Can be plpgsq.extra_errors and plpgsql.extra_warnings solution?
>
> I am thinking so t
Justin Pryzby writes:
> On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
>> 2. Even better would be a stack trace for the call to errfinish,
>> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
Thanks, but we need the whole call stack, or at least the firs
On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
> 3. It's pretty hard to see how you'd reach any of these places for an
> ALTER COLUMN TYPE on a simple table. Has the table got rules, triggers,
> default values? Could we see "\d+" output for it?
I really meant to do \d+..
On Tue, Jan 03, 2017 at 02:32:36PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> I can cause the error at will on the existing table,
>
> That's good news, at least.
>
> 1. Please trigger it with "\set VERBOSITY verbose" enabled, so we can see
> the exact source location --- there are a
In 0001-Add-PUBLICATION-catalogs-and-DDL-v16.patch.gz,
+static bool
+is_publishable_class(Oid relid, Form_pg_class reltuple)
+{
+ return reltuple->relkind == RELKIND_RELATION &&
+ !IsCatalogClass(relid, reltuple) &&
+ reltuple->relpersistence == RELPERSISTENCE_PER
Justin Pryzby writes:
I can cause the error at will on the existing table,
That's good news, at least.
1. Please trigger it with "\set VERBOSITY verbose" enabled, so we can see
the exact source location --- there are a couple of instances of that
text.
2. Even better would be a stack trace
On 11/2/16 11:45 AM, Oskari Saarenmaa wrote:
> 26.10.2016, 21:34, Andres Freund kirjoitti:
>> Any chance that plsh or the script it executes does anything with the file
>> descriptors it inherits? That'd certainly one way to get into odd corruption
>> issues.
>>
>> We processor really should use
Hi
2016-12-31 6:46 GMT+01:00 Peter Eisentraut :
> During some recent patch reviews, there was some back and forth about
> where to put prototypes for fmgr-callable functions. We don't actually
> need these prototypes except to satisfy the compiler, so we end up
> sprinkling them around random he
On 11/7/16 5:31 PM, Merlin Moncure wrote:
> Regardless, it seems like you might be on to something, and I'm
> inclined to patch your change, test it, and roll it out to production.
> If it helps or at least narrows the problem down, we ought to give it
> consideration for inclusion (unless someone
On Tue, Jan 03, 2017 at 01:40:50PM -0500, Robert Haas wrote:
> On Tue, Jan 3, 2017 at 11:59 AM, Justin Pryzby wrote:
> > On Tue, Jan 03, 2017 at 11:45:33AM -0500, Robert Haas wrote:
> >> > ts=# begin; drop view umts_eric_ch_switch_view,
> >> > eric_umts_rnc_utrancell_view, umts_eric_cell_integrit
Magnus Hagander writes:
> On Tue, Jan 3, 2017 at 7:33 PM, Tom Lane wrote:
>> Somehow the reset is clobbering local configuration on some members?
> I doubt that. I think that was probably never configured, it just didn't
> show up when everything was working.
> I don't know what the buildfarm r
2017-01-03 18:52 GMT+01:00 Fabien COELHO :
>
> ** PLEASE **
>>> COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN
>>> REPLYING IN THE THREAD?
>>> ** THANKS **
>>
>>
> Hmmm. It seems that you can't. You should, really.
I am sorry - The gmail client mask me thes
Lewis, Ian (Microstar Laboratories) wrote:
> PS. To anyone who might know the answer: My Reply All to this group does
> not seem to join to the original thread. All I am doing is Reply All
> from Outlook. Is there something else I need to do to allow my responses
> to join the original thread?
Th
On Tue, Jan 3, 2017 at 11:59 AM, Justin Pryzby wrote:
> On Tue, Jan 03, 2017 at 11:45:33AM -0500, Robert Haas wrote:
>> > ts=# begin; drop view umts_eric_ch_switch_view,
>> > eric_umts_rnc_utrancell_view, umts_eric_cell_integrity_view; ALTER TABLE
>> > eric_umts_rnc_utrancell_metrics ALTER COLUM
On Tue, Jan 3, 2017 at 7:33 PM, Tom Lane wrote:
> Magnus Hagander writes:
> >> Ok. Now let's wait for the fallout from the reset. This is an
> interesting
> >> experiment, we'll find out how many people are annoyed by a reset :-).
>
> > I bet a number of buildfarm machines will dislike it :(
>
>
Magnus Hagander writes:
>> Ok. Now let's wait for the fallout from the reset. This is an interesting
>> experiment, we'll find out how many people are annoyed by a reset :-).
> I bet a number of buildfarm machines will dislike it :(
Early returns don't look good, eg on termite
From git:
On Mon, Jan 2, 2017 at 8:03 PM, Lewis, Ian (Microstar Laboratories)
wrote:
> Personally, I believe such an option would increase, not decrease the
> number of people who could relatively easily use PostgreSQL. If that is
> right it is a strong argument for such a modal behavior in spite of the
> o
On 01/03/2017 03:30 PM, Peter Eisentraut wrote:
On 1/3/17 7:23 AM, Kuntal Ghosh wrote:
The regression tests for hot standby check fails since it uses the
following statement:
-select min_value as sequence_min_value from hsseq;
which is no longer supported I guess. It should be modified as follow
Magnus Hagander writes:
> On Tue, Jan 3, 2017 at 6:59 PM, Heikki Linnakangas wrote:
>> Ok. Now let's wait for the fallout from the reset. This is an interesting
>> experiment, we'll find out how many people are annoyed by a reset :-).
> Yeah, and how many had time to pull. It was only out there
2017-01-03 19:39 GMT+05:00 Peter Eisentraut :
> On 1/3/17 1:26 AM, amul sul wrote:
> > One more requirement for pg_background is session, command_qh,
> > response_qh and worker_handle should be last longer than current
> > memory context, for that we might need to allocate these in
> > TopMemoryCo
On Tue, Jan 3, 2017 at 6:59 PM, Jim Nasby wrote:
> On 1/3/17 11:57 AM, Magnus Hagander wrote:
>
>> I've pushed a reset to the master repo. Working on the mirror now.
>>
>
> Please don't forget github. :)
>
> Handled, thanks for the reminder.
--
Magnus Hagander
Me: http://www.hagander.net/
W
On Tue, Jan 3, 2017 at 06:57:44PM +0100, Magnus Hagander wrote:
> I'm leaning for +1 for resetting. It'll be a pain for any mirrors of the
> repo, but I think the clean history is worth it.
>
>
>
> It seems bruce pushed a whole bunch of merge conflicts, and possibly more. I
> think h
On Tue, Jan 3, 2017 at 6:59 PM, Heikki Linnakangas wrote:
> On 01/03/2017 07:57 PM, Magnus Hagander wrote:
>
>> On Tue, Jan 3, 2017 at 6:54 PM, Heikki Linnakangas
>> wrote:
>>
>> On 01/03/2017 07:49 PM, Bruce Momjian wrote:
>>>
>>> On Tue, Jan 3, 2017 at 06:46:32PM +0100, Magnus Hagander wrote:
On 01/03/2017 07:57 PM, Magnus Hagander wrote:
On Tue, Jan 3, 2017 at 6:54 PM, Heikki Linnakangas wrote:
On 01/03/2017 07:49 PM, Bruce Momjian wrote:
On Tue, Jan 3, 2017 at 06:46:32PM +0100, Magnus Hagander wrote:
Is this a big enough boo that we actually want to reset the master repo
to
On 1/3/17 11:57 AM, Magnus Hagander wrote:
I've pushed a reset to the master repo. Working on the mirror now.
Please don't forget github. :)
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble!
On 1/3/17 10:33 AM, Fabien COELHO wrote:
** PLEASE **
COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN
REPLYING IN THE THREAD?
** THANKS **
+1. Frankly, I've been skipping most of your (Pavel) replies in this
thread because of this.
--
Jim Nasby, Data Arc
On Tue, Jan 3, 2017 at 6:54 PM, Heikki Linnakangas wrote:
> On 01/03/2017 07:49 PM, Bruce Momjian wrote:
>
>> On Tue, Jan 3, 2017 at 06:46:32PM +0100, Magnus Hagander wrote:
>>
>>> Is this a big enough boo that we actually want to reset the master repo
>>> to get
>>> rid of it?
>>>
>>> If so, we
On 01/03/2017 07:49 PM, Bruce Momjian wrote:
On Tue, Jan 3, 2017 at 06:46:32PM +0100, Magnus Hagander wrote:
Is this a big enough boo that we actually want to reset the master repo to get
rid of it?
If so, we need to do it *now* beore people get a chance to mirror it properly..
Thoughts?
If
** PLEASE **
COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN
REPLYING IN THE THREAD?
** THANKS **
Hmmm. It seems that you can't. You should, really.
If you use patterns that I wrote - the security context will be valid
always.
No: This pattern assumes
2017-01-03 18:41 GMT+01:00 Jim Nasby :
> On 1/3/17 11:19 AM, Pavel Stehule wrote:
>
>> 2) There's no way to incrementally change those values for a
>> single
>> function. If you've set extra_errors = 'all' globally, a
>> single
>> function can't say "tur
On Tue, Jan 3, 2017 at 06:46:32PM +0100, Magnus Hagander wrote:
> Is this a big enough boo that we actually want to reset the master repo to get
> rid of it?
>
> If so, we need to do it *now* beore people get a chance to mirror it
> properly..
>
> Thoughts?
>
> If not, just a revert should wor
On 1/3/17 11:19 AM, Pavel Stehule wrote:
2) There's no way to incrementally change those values for a
single
function. If you've set extra_errors = 'all' globally, a single
function can't say "turn off the too many rows setting for this
func
On 01/03/2017 08:47 AM, Robert Haas wrote:
> On Tue, Jan 3, 2017 at 11:21 AM, Simon Riggs wrote:
>> On 3 January 2017 at 15:50, Robert Haas wrote:
>>> On Sun, Jan 1, 2017 at 4:14 PM, Simon Riggs wrote:
Trying to fit recovery targets into one parameter was really not
feasible, though I
On 1/3/17 9:58 AM, Pavel Stehule wrote:
> ** The real problem is that we have no mechanism for allowing a PL's
> language/syntax/API to move forward without massive backwards
compatibility
> problems. **
Just got back from break :-). Have some thoughts on this. Backwards
c
2017-01-03 17:57 GMT+01:00 Jim Nasby :
> On 1/2/17 1:51 PM, Pavel Stehule wrote:
>
>> 1) Neither is enabled by default, so 90% of users have no idea they
>> exist. Obviously that's an easy enough fix, but...
>>
>> We can strongly talk about it - there can be a chapter in plpgsql doc.
>> No
Robert Haas writes:
> On Tue, Jan 3, 2017 at 11:11 AM, Tom Lane wrote:
A survey of s_lock.h shows that we prefer char-width slock_t only on
these architectures:
x86
sparc (but not sparcv9, there we use int)
m68k
vax
>>> I don't think that's right, because on m
2017-01-03 17:33 GMT+01:00 Fabien COELHO :
>
> ** PLEASE **
>
> COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN
> REPLYING IN THE THREAD?
>
> ** THANKS **
>
> [...] Then B believes that A succeeded, which is not the case.
>>>
>>
>> No, just your design is unhapp
On 1/2/17 1:51 PM, Pavel Stehule wrote:
1) Neither is enabled by default, so 90% of users have no idea they
exist. Obviously that's an easy enough fix, but...
We can strongly talk about it - there can be a chapter in plpgsql doc.
Now, the patterns and antipatterns are not officially docu
On Tue, Jan 03, 2017 at 11:45:33AM -0500, Robert Haas wrote:
> > ts=# begin; drop view umts_eric_ch_switch_view,
> > eric_umts_rnc_utrancell_view, umts_eric_cell_integrity_view; ALTER TABLE
> > eric_umts_rnc_utrancell_metrics ALTER COLUMN PMSUMPACKETLATENCY_000 TYPE
> > BIGINT USING PMSUMPACKETL
On 3 January 2017 at 16:47, Robert Haas wrote:
> On Tue, Jan 3, 2017 at 11:21 AM, Simon Riggs wrote:
>> On 3 January 2017 at 15:50, Robert Haas wrote:
>>> On Sun, Jan 1, 2017 at 4:14 PM, Simon Riggs wrote:
Trying to fit recovery targets into one parameter was really not
feasible, thou
On Tue, Jan 3, 2017 at 11:21 AM, Simon Riggs wrote:
> On 3 January 2017 at 15:50, Robert Haas wrote:
>> On Sun, Jan 1, 2017 at 4:14 PM, Simon Riggs wrote:
>>> Trying to fit recovery targets into one parameter was really not
>>> feasible, though I tried.
>>
>> What was the problem?
>
> There are
On Mon, Jan 2, 2017 at 7:32 PM, Justin Pryzby wrote:
> On Wed, Oct 12, 2016 at 10:25:05AM -0500, Justin Pryzby wrote:
>> > I don't have a clear recollection how I solved this in July; possibly by
>> > restoring the (historic, partition) table from backup.
>> >
>> > Last week again again just now (
1 - 100 of 161 matches
Mail list logo