Here is resubmission of patch to implement logical decoding of two-phase
transactions (instead of treating them
as usual transaction when commit) [1] I’ve slightly polished things and used
test_decoding output plugin as client.
General idea quite simple here:
* Write gid along with commit/prepa
Hi
now the code in tabcomplete become large part of psql. Is there some
possibility to write regress tests?
I found only this link
http://stackoverflow.com/questions/22795767/how-to-test-python-readline-completion
Regards
Pavel
On Sat, Dec 3, 2016 at 1:38 AM, Haribabu Kommi wrote:
> Moved to next CF with "waiting on author" status.
Unfortunately it's been a bit trickier than I anticipated to get the
interprocess batch file sharing and hash table shrinking working
correctly and I don't yet have a new patch in good enough
On Tue, Dec 20, 2016 at 2:38 PM, Fujii Masao wrote:
> On Mon, Dec 19, 2016 at 7:51 PM, Vladimir Rusinov
> wrote:
> >
> > On Sat, Dec 17, 2016 at 2:37 PM, Magnus Hagander
> > wrote:
> >>
> >> Attached is an updated patch that does this. As a bonus it simplifies
> the
> >> code a bit. I also fixe
On Tue, Dec 20, 2016 at 11:53 PM, Michael Paquier wrote:
> On Tue, Dec 20, 2016 at 10:38 PM, Fujii Masao
> wrote:
> > On Mon, Dec 19, 2016 at 7:51 PM, Vladimir Rusinov
> wrote:
> >> The server must also be configured with max_wal_senders set high
> >> enough to leave at least one session availa
On Sat, Dec 31, 2016 at 6:57 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> A further step toward getting rid of the DSSSL tool chain requirement,
> here is a patch to change the generation of the text INSTALL file to use
> XLST and Pandoc.
>
> The change to Pandoc is not essent
On Wed, Sep 28, 2016 at 2:26 AM, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> > From: pgsql-hackers-ow...@postgresql.org
> > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> > On Sun, Sep 25, 2016 at 10:45 PM, Tsunakawa, Takayuki
> > wrote:
> > > Credit: Th
Updated patch with some merge conflicts resolved and some minor bug
fixes. Vitaly's earlier reviews were very comprehensive, and I believe
I have fixed all the issues that have been pointed out, so just
double-checking that would be helpful at this point. I still don't have
a solution for managin
On Sat, Dec 31, 2016 at 6:30 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 12/30/16 3:59 AM, Magnus Hagander wrote:
> > I wonder if I missed part of the discussions around this, so maybe my
> > understanding of the cases where this occurs is wrong, but isn't it the
> > case
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/CABUevEwfV7zDutescm2PHGvsJdYA0RWHFMTRGhwrJPGgSbzZDQ%
Em sáb, 31 de dez de 2016 às 07:11, Pavel Stehule
escreveu:
> Hi
>
> now the code in tabcomplete become large part of psql. Is there some
> possibility to write regress tests?
>
> I found only this link
>
>
> http://stackoverflow.com/questions/22795767/how-to-test-python-readline-completion
>
> I
On 12/31/16 4:09 AM, Pavel Stehule wrote:
> now the code in tabcomplete become large part of psql. Is there some
> possibility to write regress tests?
I started on that a while ago with some Perl Expect module. The use of
the module was a bit cumbersome, but it worked OK.
The problem is that yo
Magnus Hagander writes:
> I still think that some wording in the direction of the fact that the
> majority of all users won't actually have this problem is the right thing
> to do (regardless of our previous history in the area as pointed out by
> Craig)
+1. The use-a-system-user solution is the
unexpectedly, that would be missed by a PL/pgSQL analysis tool... There is
no miracle.
No - metadata, in my design, are persistent - like tables - so you don't
calculate so any functions can drop a variables. The deployment of secure
variables is same like table deployment. No dynamic there.
Peter Eisentraut writes:
> In order to reduce the number of useless casts and make the useful casts
> more interesting, here is a patch that automatically casts the result of
> copyNode() back to the input type, if the compiler supports something
> like typeof(), which most current compilers appea
There is a common coding pattern that goes like this:
RestrictInfo *rinfo = (RestrictInfo *) lfirst(lc);
Assert(IsA(rinfo, RestrictInfo));
(Arguably, the Assert should come before the cast, but I guess it's done
this way out of convenience.)
(Not to mention the other common coding patter
2016-12-31 17:51 GMT+01:00 Fabien COELHO :
>
> unexpectedly, that would be missed by a PL/pgSQL analysis tool... There is
>>> no miracle.
>>>
>>
>> No - metadata, in my design, are persistent - like tables - so you don't
>> calculate so any functions can drop a variables. The deployment of secure
Hello Craig,
As for "slow", I have just tested overheads with pgbench, comparing a direct
arithmetic operation (as a proxy to a fast session variable consultation) to
constant returning plpgsql functions with security definer and security
invoker, on a direct socket connection, with prepared st
DROP VARIABLE super_secret;
CREATE VARIABLE super_secret ...;
But you don't do it in functions - these variables are persistent - you
don't create it or drop inside functions. The content is secure, so you
don't need to hide this variable against other.
ISTM that you are still missing
>
> If you do not have expectations, then all is fine.
>
> (1) Having some kind of variable, especially in interactive mode, allows to
>>> manipulate previous results and reuse them later, without having to
>>> resort
>>> to repeated sub-queries or to retype non trivial values.
>>>
>>> Client side
Peter Eisentraut writes:
> I propose a macro castNode() that combines the assertion and the cast,
> so this would become
> RestrictInfo *rinfo = castNode(RestrictInfo, lfirst(lc));
Seems like an OK idea, but I'm concerned by the implied multiple
evaluations, particularly if you're going to ap
2016-12-31 18:46 GMT+01:00 Fabien COELHO :
>
>DROP VARIABLE super_secret;
>>>CREATE VARIABLE super_secret ...;
>>>
>>
>> But you don't do it in functions - these variables are persistent - you
>> don't create it or drop inside functions. The content is secure, so you
>> don't need to hide
I wrote:
> Just to bikeshed a bit ... would "castNode" be a better name?
Um ... -ENOCAFFEINE. Never mind that bit.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
pgbench's -l option is coded using inappropriate familiarity with the
contents of struct instr_time. I recall complaining about that when
the code went in, but to little avail. However, it needs to be fixed
if we're to switch over to using clock_gettime() as discussed in
the gettimeofday thread,
On Sat, Dec 31, 2016 at 9:24 PM, Magnus Hagander wrote:
> On Tue, Dec 20, 2016 at 11:53 PM, Michael Paquier
> wrote:
>> Recovery tests are broken by this patch, the backup() method in
>> PostgresNode.pm uses pg_basebackup -x:
>> sub backup
>> {
>> my ($self, $backup_name) = @_;
>> my $bac
On Tue, Dec 27, 2016 at 12:41 PM, Michael Paquier
wrote:
> There are still a couple of days to register patches! So if you don't
> want your fancy feature to be forgotten, please add it in time to the
> CF app. Speaking of which, I am going to have a low bandwidth soon as
> that's a period of Nati
On Fri, Sep 30, 2016 at 04:23:13PM +1300, Thomas Munro wrote:
> On Thu, Sep 29, 2016 at 6:19 PM, David Fetter wrote:
> > On Thu, Sep 29, 2016 at 11:12:11AM +1300, Thomas Munro wrote:
> >> On Mon, Sep 26, 2016 at 5:11 PM, Thomas Munro
> >> wrote:
> >> > On Mon, Sep 26, 2016 at 1:18 PM, Thomas Munr
27 matches
Mail list logo
