Hi all,
Happy new year to all and best wishes!
I guess that the following command followed by a commit is the common
happy-new-year thing to do:
perl src/tools/copyright.pl
This would update the copyright headers to 2016 :)
Regards,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-ha
On 2015-12-24 14:57, Alexander Korotkov wrote:
What do you think about
"
System Administration Functions
" chapter?
http://www.postgresql.org/docs/devel/static/functions-admin.html
Other than that I am happy with the patch.
Sounds good to me.
One last tiny gripe, I think the amroutin
Hello,
I would like to introduce concept of generic WAL logical messages.
These messages just create WAL record with arbitrary data as specified
by user. For standard WAL reply, these are basically noop, but in
logical decoding they are be decoded and the special callback of the
output plugin
Hi,
I noticed that the filter callback is documented as
LogicalDecodeChangeCB in the logical decoding docs. Here is one-line
patch to fix it.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
logical-decoding-filter-typo
On 12/31/15 19:06, Jim Nasby wrote:
> Those columns are there to tell you what *kind* of objects are involved in
> the dependency. For example, a function will have two entries. classid will
> be 1255 (pg_proc) for both of them. refclassid will be 2612 (pg_language)
> for one and 2615 (pg_namespace
On 12/31/15 3:49 PM, Chapman Flack wrote:
On 12/23/15 15:02, Jim Nasby wrote:
>BTW, I've been pondering a very similar problem to this. I'm working on a
>metacoding framework, and it's inevitable that at some point it will want to
>know what objects it's created
>
>I was planning on just mak
Hi,
I'd like to submit the replication solution which is based on the
pglogical_output [1] module (which is obviously needed for this to compile).
The pglogical contrib module provides extension which does the
master-slave logical replication based on the logical decoding.
The basic documen
On Thu, Dec 31, 2015 at 12:48 PM, Tomas Vondra
wrote:
> 1) initHyperLogLogError(hyperLogLogState *cState, double error)
>
>Instead of specifying bwidth (essentially the number of bits used
>for addressing in the counter), this allows specifying the expected
>error rate for the counter,
"Paragon Corporation" writes:
>> Yes. The FDW author is not expected to implement those clauses; where do
>> you see documentation saying otherwise?
> I didn't. I was copying the postgres_fdw and noticed it implemented them
> directly.
Ah. I believe that's mostly just an efficiency hack (and a
Alvaro Herrera writes:
> Tom Lane wrote:
>> While this isn't exactly a stop-ship class of problem, it still seems like
>> it'd be good to fix before 9.5.0.
> I wonder if a note to packagers to inform them of the new file added
> after the RC would be a good idea.
On closer look, the busted ALTER
On 12/23/15 15:02, Jim Nasby wrote:
> BTW, I've been pondering a very similar problem to this. I'm working on a
> metacoding framework, and it's inevitable that at some point it will want to
> know what objects it's created
>
> I was planning on just making a best possible attempt and solving
"Paragon Corporation" writes:
>> So I am guessing you guys are filtering the list so that it works for
>> all FDWs even if the FDW author doesn't directly handle LIMIT / EXCEPT
clause?
> Yes. The FDW author is not expected to implement those clauses; where do
you see documentation saying other
On Thu, Dec 31, 2015 at 04:41:44PM -0500, Chapman Flack wrote:
> I suppose there really won't be a way to do this with reliability
> unless someday extensions can hook the dependency infrastructure,
> as you mentioned in passing in an earlier message.
>
> That sounds like a longer discussion. But
On 12/31/15 16:13, Tom Lane wrote:
>> I see that 9.5.0 already adds PGDLLIMPORT on the global variable
>> creating_extension, but CurrentExtensionObject on the very next
>> line of extension.h still doesn't have it.
>
> Why would you need to access that?
This returns to the earlier question about
On Wed, Dec 2, 2015 at 01:16:09AM +, Greg Stark wrote:
>
> On 1 Dec 2015 19:48, "Tom Lane" wrote:
> >
> > In passing, avoid possible calculation of log10(0). Probably that's
> > harmless, given the lack of field complaints, but it seems risky:
> > conversion of NaN to an integer isn't well
Chapman Flack writes:
> I see that 9.5.0 already adds PGDLLIMPORT on the global variable
> creating_extension, but CurrentExtensionObject on the very next
> line of extension.h still doesn't have it.
Why would you need to access that?
regards, tom lane
--
Sent via pgsq
"Paragon Corporation" writes:
> So I am guessing you guys are filtering the list so that it works for all
> FDWs even if the FDW author doesn't directly handle LIMIT / EXCEPT clause?
Yes. The FDW author is not expected to implement those clauses; where
do you see documentation saying otherwise?
While on the subject of things that could make it or not into 9.5.?,
I see that 9.5.0 already adds PGDLLIMPORT on the global variable
creating_extension, but CurrentExtensionObject on the very next
line of extension.h still doesn't have it.
The simplest way I've come up with in Windows to identify
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, December 31, 2015 3:36 PM
To: Paragon Corporation
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] IMPORT FOREIGN SCHEMA return create foreign table
commands are those further filtered in LIMIT and EXCEPT
Meh, of course I forgot to actually attach the patch.
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 8f207693faa65e65e8a1e5e894c2ad96ad1f3cea Mon Sep 17 00:00:00 2001
From: Tomas Vondra
Date: Mon, 28 Dec 201
Hi,
while working on the bloom filters for hashjoins, I've started using the
HLL library committed as part of the sorting improvements for 9.5. I
propose adding two more functions to the API, which I think are quite
useful:
1) initHyperLogLogError(hyperLogLogState *cState, double error)
Hi,
attached is v2 of the patch, with a number of improvements:
0) This relies on the the other hashjoin patches (delayed build of
buckets and batching), as it allows sizing the bloom filter.
1) enable_hashjoin_bloom GUC
This is mostly meant for debugging and testing, not for committing.
"Paragon Corporation" writes:
> I've implemented IMPORT FOREIGN SCHEMA support for an fdw called ogr_fdw
> against the PostgreSQL 9.5RC1 code base.
> Code is here: https://github.com/robe2/pgsql-ogr-fdw
> It works great except in the Case of LIMIT TO clause (and possible EXCEPT
> though I have
I've implemented IMPORT FOREIGN SCHEMA support for an fdw called ogr_fdw
against the PostgreSQL 9.5RC1 code base.
Code is here: https://github.com/robe2/pgsql-ogr-fdw
It works great except in the Case of LIMIT TO clause (and possible EXCEPT
though I have to retest EXCEPT to see if there is a c
I did a bit of initial poking at the problem complained of in bug #13840,
namely that if you use "none" as the value of a reloption, you get a
syntax error when trying to reload a dump containing the table or index
declaration. The submitter blames this on pg_dump but it is surely not
pg_dump's fa
Hi,
attached is v2 of the patch, with a bugfix and two significant improvements:
1) bugfix: forgotten memset() in ExecHashIncreaseNumBatches()
Caused segfaults whenever we started with a single batch and then
had to increase the number of batches.
2) 0002: postpone the batching (not just
On Thu, Dec 24, 2015 at 05:28:11PM +0300, Dmitry Ivanov wrote:
> Suppose you want to upgrade from 9.4 to 9.6. In that case you would use the
> pg_upgrade utility provided by the release 9.6, which means that it's the
> pg_dump who would have to connect to the older instance and to prepare tuples
Alvaro Herrera writes:
> Tom Lane wrote:
>> While this isn't exactly a stop-ship class of problem, it still seems like
>> it'd be good to fix before 9.5.0.
> I wonder if a note to packagers to inform them of the new file added
> after the RC would be a good idea.
I doubt they care; I've not seen
On Thu, Dec 31, 2015 at 12:50:13AM -0500, Bruce Momjian wrote:
> On Wed, Dec 30, 2015 at 11:57:45PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Oops. Once this patch is applied, it is only going to take effect when
> > > someone _installs_ Postgres. Even an initdb will not add the fil
Tom Lane wrote:
> I noticed $subject while chasing a different issue.
>
> The way to fix this is to export pg_operator.c's makeOperatorDependencies
> function so that AlterOperator can call it. But since that declaration
> uses HeapTuple, I doubt we want to put it into pg_operator.h (which'd
> re
I noticed $subject while chasing a different issue.
The way to fix this is to export pg_operator.c's makeOperatorDependencies
function so that AlterOperator can call it. But since that declaration
uses HeapTuple, I doubt we want to put it into pg_operator.h (which'd
require further growth in that
Em 31 de dezembro de 2015 04:56:55 BRST, Noah Misch
escreveu:
>On Wed, Dec 30, 2015 at 10:18:35AM -0500, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2015-12-29 11:07:26 -0500, Tom Lane wrote:
>> >> In passing, the patch gets rid of a vestigial
>CHECK_FOR_INTERRUPTS()
>> >> call; it was ad
Hello,
As discussed, I will be managing the commitfest process this time
around. Please, everyone, make sure patches are registered in the app
today. As of this instant, we have:
Needs review: 73.
Waiting on Author: 5.
Ready for Committer: 6.
Committed: 5.
Total: 89.
Thanks,
--
Álvaro H
On 12/31/2015 06:36 AM, Amit Kapila wrote:
Going further on this work, I have written a patch for separating the
tranches for extensions. The basic idea is to expose two new API's,
first to request a new tranche and second to assign a lock from that
tranche.
RequestAddinLWLockTranche(const char
On Thu, Dec 24, 2015 at 8:02 AM, Michael Paquier
wrote:
>
> On Tue, Nov 17, 2015 at 8:36 PM, Vladimir Borodin
wrote:
> >
> > 14 нояб. 2015 г., в 10:50, Amit Kapila
написал(а):
> >
> > On Wed, Sep 16, 2015 at 11:22 PM, Robert Haas
wrote:
> >> On Wed, Sep 16, 2015 at 12:29 PM, Alexander Korotkov
On Thu, Dec 31, 2015 at 5:06 PM, Amit Kapila
wrote:
>
> On Tue, Dec 29, 2015 at 2:26 PM, Amit Kapila
wrote:
>>
>> On Wed, Dec 16, 2015 at 12:26 AM, Robert Haas
wrote:
>> >
>> >
I have moved this patch to new CF as the work is still in
progress.
With Regards,
Amit Kapila.
EnterpriseDB: http://w
On Tue, Dec 29, 2015 at 2:26 PM, Amit Kapila
wrote:
> On Wed, Dec 16, 2015 at 12:26 AM, Robert Haas
> wrote:
> >
> >
> > In terms of this project overall, NumLWLocks() now knows about only
> > four categories of stuff: fixed lwlocks, backend locks (proc.c),
> > replication slot locks, and locks
On Fri, Dec 18, 2015 at 10:51 AM, Dilip Kumar wrote:
> On Sun, Jul 19 2015 9:37 PM Andres Wrote,
>
> > The situation the read() protect us against is that two backends try to
> > extend to the same block, but after one of them succeeded the buffer is
> > written out and reused for an independent
Hi
here is new version.
Now I use a common ancestor "plpy.BaseError" for plpy builtin classes. So
plpy.SPIError isn't descendant of plpy.Error and then there are not
possible incompatibility issues.
Instead modification builtin function plpy.debug, plpy.info, ... and
introduction incompatibility
39 matches
Mail list logo
