On 25 November 2016 at 14:16, Tom Lane wrote:
> Craig Ringer writes:
>> PGDLLIMPORT is free, so the question should be "is there a reason not
>> to add it here?".
>
> TBH, my basic complaint about it is that I do not like Microsoft's tool
> chain assuming t
On 25 November 2016 at 02:44, Alvaro Herrera wrote:
> Craig Ringer wrote:
>
>> Updated to correct the other expected file, since there's an alternate.
>
> FWIW I don't know what you did here, but you did not patch the
> alternate expected file.
Damn. Attached t
On 25 November 2016 at 02:47, Alvaro Herrera wrote:
> Craig Ringer wrote:
>> On 27 October 2016 at 00:42, Robert Haas wrote:
>> > On Wed, Oct 26, 2016 at 7:17 AM, Andres Freund wrote:
>> >> On 2016-09-23 16:04:32 -0400, Tom Lane wrote:
>> >>> Look
On 25 November 2016 at 07:36, Michael Paquier wrote:
> On Thu, Nov 24, 2016 at 11:01 PM, Magnus Hagander wrote:
>> On Thu, Nov 24, 2016 at 2:58 PM, Craig Ringer wrote:
>> My guess is that PGDLLIMPORT has been added explicitly when somebody needed
>> it for something, witho
se to be PGDLLIMPORT but
not others. In particular it's pretty silly for IsBackgroundWorker not
to be PGDLLIMPORT.
Too trivial to be worth making an actual patch, it'd be more work to
apply it than edit directly.
--
Craig Ringer http://www.2ndQuadrant.com/
Postgre
On 24 November 2016 at 02:32, Andres Freund wrote:
> Hi,
>
> On 2016-11-23 20:58:22 +0800, Craig Ringer wrote:
>> Today I ran into an issue where commit timestamp lookups were failing with
>>
>> ERROR: cannot retrieve commit timestamp for transaction
On 23 November 2016 at 03:55, Robert Haas wrote:
> On Tue, Nov 22, 2016 at 1:49 AM, Craig Ringer wrote:
>> On 22 November 2016 at 10:20, Craig Ringer wrote:
>>> I'm currently looking at making detection of replay conflict with a
>>> slot work by separating t
On 23 November 2016 at 20:58, Craig Ringer wrote:
> Hi all
>
> Today I ran into an issue where commit timestamp lookups were failing with
>
> ERROR: cannot retrieve commit timestamp for transaction 2
>
> which is of course FrozenTransactionId.
>
> TransactionId
to 9.6 and, without the TAP test part, to 9.5.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From 52081e9aa91102022d6e853d4e2217308bb230a9 Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Wed, 23 Nov 2016 19:50:50 +0800
S
d consider any logical replication
downstream a 'master'.
That's fine for now IMO. Determining whether a server is a logical
replica isn't that simple, nor is it a clear-cut yes/no answer, and I
think it's out of the scope of this patch to deal with it. Figure it
out once l
On 22 November 2016 at 15:14, Haribabu Kommi wrote:
>
> On Fri, Nov 18, 2016 at 7:18 PM, Craig Ringer wrote:
>>
>> The latest is what's attached upthread and what's in the git repo also
>> referenced upthread.
>>
>> I haven't been able to updat
On 22 November 2016 at 10:20, Craig Ringer wrote:
> I'm currently looking at making detection of replay conflict with a
> slot work by separating the current catalog_xmin into two effective
> parts - the catalog_xmin currently needed by any known slots
> (ProcArray->replicati
On 22 November 2016 at 11:35, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Mon, 21 Nov 2016 21:39:07 -0500, Robert Haas wrote
> in
>> On Mon, Nov 21, 2016 at 3:21 AM, Craig Ringer wrote:
>> > I'm still interested in hearing comments from experienced folks about
&
.
That also offers a handy step on the path toward table-valued
variables and pipelined functions, both of which would be _really_
nice for PL/PgSQL users.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent v
ed to be checked with:
* WinXP, non-admin
* WinXP, admin, should refuse to run
* WinVista / Win7, local admin, UAC on => should run
* WinVista / Win7, local admin, UAC off => should refuse to run
* WinVista / Win7, run cmd.exe using "run as admin" => should refuse to run
*
On 18 November 2016 at 10:57, Craig Ringer wrote:
> Hi all
>
> While adding support for logical decoding on standby I noticed that
> the walsender doesn't respect
> SIGUSR1 with PROCSIG_RECOVERY_CONFLICT_DATABASE set.
I have an update on this after further study.
Surprising
/CAMsr+YFi-LV7S8ehnwUiZnb=1h_14PwQ25d-vyUNq-f5S5r=z...@mail.gmail.com
* Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from
walsender?
[5]
https://www.postgresql.org/message-id/CAMsr+YFb3R-t5O0jPGvz9_nsAt2GwwZiLSnYu3=x6mr9rnr...@mail.gmail.com
Also relevant:
> GROUP BY 1 ORDER BY 1;
>
> but result is sensitive on locales setting - doesn't work well with czech
> locales.
Simple fix here is to append COLLATE "C" after the ORDER BY.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 2
On 21 November 2016 at 12:23, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Mon, 21 Nov 2016 11:58:34 +0800, Craig Ringer
> wrote in
>> On 18 November 2016 at 08:15, Craig Ringer wrote:
>> > On 18 November 2016 at 07:10, Michael Paquier
>> > wrote:
>>
On 19 November 2016 at 10:04, Euler Taveira wrote:
> On 01-09-2016 01:41, Craig Ringer wrote:
>> Here's a rebased version of my pg_recvlogical --endpos patch from the
>> 9.5 series, updated to incoroprate Álvaro's changes.
>>
> I should review this patch in th
On 18 November 2016 at 08:15, Craig Ringer wrote:
> On 18 November 2016 at 07:10, Michael Paquier
> wrote:
>> On Thu, Nov 17, 2016 at 2:39 PM, Craig Ringer wrote:
>>> I wasted a bunch of time getting set up to test for such an ancient
>>> Perl and would love to
d.
>
> True, but raising the bar for this feature so that it doesn't get done
> is also bad. It can be improved in a later patch.
Good point. Starting with the followup query method seems fine.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Develop
On 18 Nov. 2016 13:14, "Kyotaro HORIGUCHI"
wrote:
>
> Hello.
>
> We had too-early WAL recycling during a test we had on a sync
> replication set. This is not a bug and a bit extreme case but is
> contrary to expectation on synchronous replication.
Isn't this prevented by using a physical replicat
t of an
oversight, and it'd definitely be good to address that to make async
mode more usable on Windows. There's some other ugliness in PQsocket
already per the comments there. I think it should be a separate patch,
though.
--
Craig Ringer http://www.2n
ver tells us on connect whether it's a standby or not, use that.
Otherwise, ask it.
That way we don't pay the round-trip cost and get the log spam when
talking to newer servers that send us something useful in the startup
packet, but we can still query it on older servers. Gr
it'd be better to make it safe to handle all the
conflict cases within the walsender.
Anyway, this PoC passes regression tests and allows drop database on a
standby to succeed when a slot is in-use. Not for commit as-is.
--
Craig Ringer http://www.2ndQuadrant.com/
Postgre
On 18 November 2016 at 07:10, Michael Paquier wrote:
> On Thu, Nov 17, 2016 at 2:39 PM, Craig Ringer wrote:
>> I wasted a bunch of time getting set up to test for such an ancient
>> Perl and would love to save the next person along the hassle by
>> documenting the easy way.
On 18 November 2016 at 05:41, Robert Haas wrote:
> On Wed, Nov 16, 2016 at 9:54 PM, Craig Ringer wrote:
>> On 17 November 2016 at 10:42, Craig Ringer wrote:
>>> But sure, if it's easier, we can have 5.8.0 in the README. What's five
>>> extra years matter
On 17 November 2016 at 12:23, Michael Paquier wrote:
> On Wed, Nov 16, 2016 at 6:54 PM, Craig Ringer wrote:
>> In all seriousness, though, lets query the buildfarm database for Perl
>> versions. Let it answer.
>
> castoroides, Solaris 10 and perl 5.8.4, no?
> https://ww
On 17 November 2016 at 10:42, Craig Ringer wrote:
> But sure, if it's easier, we can have 5.8.0 in the README. What's five
> extra years matter anyway? Hey, while we're at it, lets change Pg to
> build on Borland C and require K&R style!
Sorry. That was unnecessary.
t's five
extra years matter anyway? Hey, while we're at it, lets change Pg to
build on Borland C and require K&R style!
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list
On 17 November 2016 at 00:01, Michael Paquier wrote:
> On Tue, Nov 15, 2016 at 11:32 PM, Noah Misch wrote:
>> On Wed, Nov 16, 2016 at 12:48:03PM +0800, Craig Ringer wrote:
>>> --- a/src/test/perl/README
>>> +++ b/src/test/perl/README
>>> @@ -64,3 +64,20 @@ Fo
On 16 November 2016 at 12:44, Craig Ringer wrote:
> Despite that, I've attached a revised version of the current approach
> incorporating fixes for the issues you mentioned. It's preceded by the
> patch to add an --endpos option to pg_recvlogical so that we can
> prope
0. Trivial one-file
docs patch. There's no README to patch in 9.4 or 9.5.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From 4ea6e7bff66ac2026bbca130bd036618b4012c35 Mon Sep 17 00:00:00 2001
From: Craig Ringer
Dat
>>
>> #include "access/xlogrecord.h"
>>
>> +#ifndef FRONTEND
>> +#include "nodes/pg_list.h"
>> +#endif
>
> Why is that needed?
It isn't anymore. Thanks for the catch. It was used when the timeline
history had to be looked up more
On 14 November 2016 at 14:55, Craig Ringer wrote:
> On 27 October 2016 at 00:42, Robert Haas wrote:
>> On Wed, Oct 26, 2016 at 7:17 AM, Andres Freund wrote:
>>> On 2016-09-23 16:04:32 -0400, Tom Lane wrote:
>>>> Looking back over the thread, I see tha
On 14 November 2016 at 16:52, Michael Paquier wrote:
> On Mon, Nov 14, 2016 at 3:45 PM, Craig Ringer wrote:
>> On 11 November 2016 at 18:13, Michael Paquier
>> wrote:
>>> On Fri, Nov 11, 2016 at 6:10 PM, Craig Ringer wrote:
>>>> Please backpatch to at leas
On 14 November 2016 at 15:01, Craig Ringer wrote:
> These three are related enough, and all only touch the TAP framework,
> so I've bundled them in a series.
CF entry https://commitfest.postgresql.org/12/883/
--
Craig Ringer http://www.2ndQuadrant.com/
bundled them in a series.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From f01790bb3f47f7fabf64328f8c9a01e8f3cf837c Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Wed, 9 Nov 2016 13:44:04 +0800
Subject: [PATCH 3/3]
isolationtester's API
>>> and behavior as something we need to hold stable for extension use.
>>
>> FWIW, I'd be quite happy if it were installed. Running isolationtester
>> when compiling extensions against distribution postgres packages would
>> be quite usefu
On 11 November 2016 at 18:13, Michael Paquier wrote:
> On Fri, Nov 11, 2016 at 6:10 PM, Craig Ringer wrote:
>> Please backpatch to at least 9.6 since it's trivial and we seem to be
>> doing that for TAP. 9.5 and 9.4 would be nice too :)
>
> Yes please!
No immedia
t;we stop answering when we lose 1 server", and semisync replication
> works for combination of these two.
Yep. Also, monitoring. sync with a short timeout means you can usually
rely on sync rep, and if it times out and falls back to async your
monitoring system can start screaming at y
On 11 Nov. 2016 13:00, "leoaaryan" wrote:
>
> Hi Michael,
>
> Thanks for all the help and time. I have already developed a code where I
> can exactly calculate the to be allocated shared memory value based on the
> Postgres 9.5.4 code (i went through the code, found out the sizes and
offset
> of a
g that for TAP. 9.5 and 9.4 would be nice too :)
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From 1180cfaca9b92c401095f9766cbb46e2ca4371f3 Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Fri, 11 Nov 2016 16:21:41
lot still to write to get solid coverage. Tests aren't hard. Who's
keen to write some? I'll happily help any volunteers out.
New patch series attached. 0001 is the new tests. The guts is patches
2-5. I'm not sure whether 2, 3, 4 and 5 should be squashed for commit
or not
nal-method-from-a-util
Please, PLEASE link to related prior discussion when you post
somewhere. It's really annoying having to look it up or wasting
people's time duplicating discussion that's already happened.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQ
On 8 Nov. 2016 15:11, "Craig Ringer" wrote:
>
>
>
> On 7 November 2016 at 05:08, Stefan Scheid wrote:
>>
>> Hi all,
>>
>> are there plans to introduce temporal tables?
>
> I don't know of anybody working on them, but someone else may. Try
ng. I don't see why anyone's going to need a matview at that
point. Since it's also untested, I suggest disallowing user catalog
matviews.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via
On 10 November 2016 at 07:18, Clifford Hammerschmidt
wrote:
>
> On Tue, Nov 8, 2016 at 2:58 PM, Craig Ringer
> wrote:
>>
>> 2ndQuadrant/bdr
>
>
> That is similar. I'm not clear on the usage of OID for sequence
> (`DirectFunctionCall1(nextval_oid, seqoid)`)
On 10 November 2016 at 07:18, Clifford Hammerschmidt
wrote:
>
> On Tue, Nov 8, 2016 at 2:58 PM, Craig Ringer
> wrote:
>>
>> 2ndQuadrant/bdr
>
>
> That is similar. I'm not clear on the usage of OID for sequence
> (`DirectFunctionCall1(nextval_oid, seqoid)`)
#x27;re not
>> modified that often. The elephant in the room is pg_proc.h, which is
>> huge, frequently-modified, and hard to decipher. But I think that's
>> going to need more surgery than just introducing named constants -
>> which would also have the downside of mak
On 9 November 2016 at 10:12, Michael Paquier wrote:
> On Wed, Nov 9, 2016 at 7:54 AM, Craig Ringer
> wrote:
>> On 9 Nov. 2016 06:37, "Yury Zhuravlev" wrote:
>>> This approach I see only in Postgres project and not fully understood.
>>> Can you explain m
On 9 Nov. 2016 06:37, "Yury Zhuravlev" wrote:
>
>> When I run cmake without options, it seems to do opportunistic feature
>> checking. For example, it turns on OpenSSL or Python support if it can
>> find it, otherwise it turns it off. We need this to be deterministic.
>> Without options, choose
On 9 Nov. 2016 02:48, "Clifford Hammerschmidt"
wrote:
>
> Looking closer at the bit math, I screwed it up it should be 64 bits
time, 6 bit uuid version, 8 node, 8 seq, and the rest random ... which is
42 bits of random. I'll find the code in a bit.
Huh, so that's what you are doing.
I just a
s step up and
either implement them or convince someone else to implement what they need.
The roadmap, such as it is, is "what the contributors and their various
customers want".
If this is important to you, look into what you need to do to make it
happen.
--
Craig Ringer
n
anomalous situation and Assert to crash the backend in an
--enable-cassert build when there's a problem.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list
On 4 Nov. 2016 06:05, "Clifford Hammerschmidt"
wrote:
>
> Hi all,
>
> Apologies in advance if this isn't the right place to be posting this.
>
> I've started work on a plugin in C (https://github.com/tanglebones/pg_tuid)
for generating generally monotonically ascending UUIDs (aka TUIDs), and
after
an interesting case IMO. Don't do
that.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
r nobody has stepped up to do the work required to
implement it in core.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
hat I can't help wondering what obvious thing I'm
missing about why it hasn't been done yet.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
thread has masked the signal,
but that means your other threads should be sure to mask all signals
used by PostgreSQL. Good luck doing that portably.
There are exceptions where you can call some backend functions and
macros from other threads. But you'd have to analyse each on a case by
case
On 31 October 2016 at 16:52, Andres Freund wrote:
> Hi,
>
> On 2016-10-31 16:34:38 +0800, Craig Ringer wrote:
>> TL;DR: Logical decoding clients need to generate their own keepalives
>> and not rely on the server requesting them to prevent timeouts. Or
>&
nd you can't interrupt
the lock wait to do some work then resume the lock wait. But that's
for later...)
Search kw:
* Logical decoding
* terminating walsender process due to replication timeout
* wal_sender_timeout
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
branches. It's not going to break anything since nothing
external that runs on Windows can previously have been referring to
these symbols.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
bals.c
> Do I detect I'm in a BGW by
> a non-null MyBgworkerEntry?
Use IsBackgroundWorker, same place as above.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgs
On 24 October 2016 at 23:49, Petr Jelinek wrote:
> Hi Craig,
>
> On 01/09/16 06:08, Craig Ringer wrote:
>> Hi all
>>
>> Attached is a rebased and updated logical decoding timeline following
>> patch for 10.0.
>>
>> This is a pre-requisite for the p
On 24 October 2016 at 12:58, Craig Ringer wrote:
> The attached patch adds a TAP test to src/test/recovery to show this.
Added to CF.
https://commitfest.postgresql.org/11/834/
... but IMO this should go in the next bugfix release.
I've also applied nearly the same fix for the same bu
target to run just one test file).
This would explain a few issues I've seen reported with BDR from the
community which I've so far been unable to reproduce, so thanks very
much for the report.
Álvaro, would you mind checking this and committing to HEAD and 9.6?
The commits.c change
ot;procedures" are necessary for
this, really.
This would also enable us to return multiple result sets.
We'd probably have to start at least one small read-only tx for the
initial cache access to look up the proc and set everything up, but if
we don't allocate xids local transactions ar
On 21 Oct. 2016 12:57 am, "Joshua D. Drake" wrote:
>
> Hello,
>
> What about a simpler solution to all of this. Let's just remove it from
postgresql.conf. Out of sight. If someone needs to test they can but a
uneducated user won't immediately know what to do about that "autovacuum
process" and whe
documentation needs to loudly warn users not
to turn it off, and that if they think vacuum is slowing their system
down they probably actually have to make it run MORE. The problem is
people not understanding autovac, and taking away the option to turn
it off won't help. They'll
a changes in a managed way. But I'm still in
favour of IF NOT EXISTS for convenience, easy development, and user
friendliness, though they need warnings in the docs really.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
ld make the whole mess of
Perl build stuff go away. CMake would solve this quite neatly since we
can bundle CMake parameters file for inclusion in other projects and
could also tell pg_config how to point to it. Extensions then become
trivial CMake projects.
--
Craig Ringer http://
worth it.
Personally I think it'd be cleaner to avoid one contrib referencing
another's headers directly and we have the fmgr infrastructure to make
it unnecessary. But I don't really think it's a problem that
especially needs solving either.
--
Craig Ringer
On 15 Oct. 2016 04:56, "Corey Huinker" wrote:
> I would like to make COPY itself a SRF. That's a bit beyond my
capabilities, so if that is the route we want to go, I will need help.
>
> The syntax would probably look like this (new bits in bold):
>
>> WITH my_copy AS (
>> COPY FROM 'example.
On 16 Oct. 2016 14:31, "Julien Rouhaud" wrote:
>
> On 16/10/2016 02:38, Jim Nasby wrote:
> > On 10/10/16 12:58 AM, Julien Rouhaud wrote:
> >> Unless you mean deparsing the Query instead of using raw source text?
I
> >> think that would solve this issue (and also the other issue when
> >> multiple
message - an error in a
> previous Query message doesn't cause later messages to be skipped.
Right, good point. So that concern isn't relevant.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent
ch containing multiple failures (because
> of unique constraint violation or whatever) - multiple errors is something
> that will have to be handled in any case.
I'm a bit hesitant about how this will interact with multi-statements
containing embedded BEGIN or COMMIT, where a singl
d another
backend accesses it and sees the value set by the first session?
Speaking of which: parallel query. How do you envision this working in
parallel query, where the workers are different backends? Especially
since things like RLS are where it'd be quite desirable.
--
Crai
into
another extension while maintaining correct dependencies sounds
nightmarish.
So I'm with you. Just don't rename it.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
what I suggest, and basically what the libpq batch
interface does, though it expects the client to deal with the
transaction boundaries.
You will need to think hard about transaction boundaries as they
relate to multi-statements unless nPgSQL parses out each statement
from multi-statement strings li
On 13 Oct. 2016 05:28, "Tom Lane" wrote:
>
> I wrote:
> > Albe Laurenz writes:
> >> Tom Lane wrote:
> >>> I'm okay with adding PGDLLEXPORT to the extern, but we should update
> >>> that comment to note that it's not necessary with any of our standard
> >>> Windows build processes. (For that matt
e the POC patch with
> more details
> similar like macaddr datatype.
There's been some minor BC breaking, but breaking on-disk format for
pg_upgrade is a much bigger deal. I'm really not a fan of that idea.
Just use macaddr64 if you want wide MACs.
--
Craig Ringer
oldest I deal with is 8.2, and that's enough of an aberration that
expecting them to go via 9.6 isn't wholly unreasonable. I agree 9.0 is
way too far.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent
On 5 October 2016 at 05:14, Andres Freund wrote:
> Hi,
>
> On 2016-09-23 13:01:27 +0800, Craig Ringer wrote:
>> From f98f2388c57d938ebbe07ccd2dbe02138312858f Mon Sep 17 00:00:00 2001
>> From: Vladimir Gordiychuk
>> Date: Wed, 7 Sep 2016 00:39:18 +0300
>> Subj
On 4 Oct. 2016 15:15, "Michael Paquier" wrote:
>
> On Mon, Oct 3, 2016 at 11:52 PM, Daniel Verite
wrote:
> > Wouldn't pgbench benefit from it?
> > It was mentioned some time ago [1], in relationship to the
> > \into construct, how client-server latency was important enough to
> > justify the use
ompat wrapper in TestLib.pm .
If folks think this is a good idea I can do the compat wrapper for the
existing tests and submit patches. I've got src/test/recovery running
happily for 9.5 already.
[1] https://www.postgresql.org/message-id/6710.1473775...@sss.pgh.pa.us
--
Craig Ringer
On 3 Oct. 2016 10:15, "Michael Paquier" wrote:
>
> On Tue, Sep 27, 2016 at 11:05 AM, Craig Ringer
wrote:
> > On 26 September 2016 at 21:52, Vladimir Gordiychuk
wrote:
> >>>You should rely on time I tests as little as possible. Some of the test
> >>&
On 3 October 2016 at 10:10, Michael Paquier wrote:
> On Tue, Sep 6, 2016 at 8:01 PM, Craig Ringer wrote:
>> On 6 September 2016 at 16:10, Daniel Verite wrote:
>>> Craig Ringer wrote:
>>>
>>>> Updated patch attached.
>>>
>>> Pleas
On 1 Oct. 2016 05:20, "Tom Lane" wrote:
>
> Corey Huinker writes:
> > Attached is a _very_ rough patch implementing a proof-of-concept
function
> > copy_srf();
> > ...
> > As for that future direction, we could either have:
> > - a robust function named something like copy_srf(), with parameters
On 30 Sep. 2016 19:36, "Emrul" wrote:
>
> Thanks Craig, I will look at that code.
>
> The alternative I'm considering is whether I can define my own index type
on
> the column storing my array of primary key ids. The index would, for each
> primary key id just provide a reference to the ctids of
; Trouble of course is that ctids can get changed (like for instance
> vacuuming). So my question is: how can I keep my ctid references up to date
> - is there any way to detect when a ctid is changed?
I expect that you'd have to teach the heapam code, vacuum, etc to do
the required houseke
isten to your
reports you really need to be very explicit about whether it's a
modified version or not. If it's modified, make sure you can reproduce
the problem in the unmodified version or explain the situation more.
If you want to ask things about BDR and pglogical, now that it'
able-depend --enable-debug --enable-cassert --prefix=`pwd`/install
> CFLAGS="-g -O0"
I suggest:
git reset --hard
git clean -fdx
ccache -C
then re-apply patch and re-check.
I've had a couple of issues recently caused by ccache doing something
funky :( but haven't been able to
On 28 Sep. 2016 17:50, "valeriof" wrote:
>
> Hi all,
> I'm developing a custom plugin to stream Postgres CDC changes to my client
> application. One of the info the application needs is the user id of the
> user who executed a certain transaction. I can see we have access to other
> transaction in
turning on the various debug print options for parsetrees,
rewriter output and plan trees helpful in understanding what's going
on.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pg
. but it doesn't:
SELECT * FROM xmltable('/x' PASSING
'avalue' COLUMNS elemName text,
extractedValue text PATH elemName);
ERROR: column "elemname" does not exist
LINE 1: ...' COLUMNS elemName text, extractedValue text PATH elemName);
... so please
mark runs aren't
desirable. You'll notice that I left diag messages in to report the
timing for the results in your tests, I just changed the tests so they
didn't depend on very tight timing for success/failure anymore.
We don't currently have any automated benchmarking infrastruct
t; evaluate the xpath and xml specifics in xpath.c today. It does strike
>> me that the new xpath parser should probably live in its own file,
>> though.
>
> moved
Thanks.
> new version is attached
Great.
I'm marking this ready for committer at this point.
I think the XML parser likely needs a more close reading, so I'll ping
Peter E to see if he'll have a chance to check that bit out. But by
and large I think the issues have been ironed out - in terms of
functionality, structure and clarity I think it's looking solid.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 21 September 2016 at 22:16, Robert Haas wrote:
> On Wed, Sep 21, 2016 at 3:40 AM, Craig Ringer wrote:
>> The only non-horrible one of those is IMO to just let the caller see
>> an error if they lose the race. It's a function that's intended for
>> use when yo
501 - 600 of 2076 matches
Mail list logo
