Hi all,
While looking at the buildfarm and reviewing the old snapshot patch, I
noticed that isolation tests cannot run with MSVC scripts all the
time. Take for example that:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawong&dt=2016-03-24%2004%3A55%3A21
Which leads to the following
On Wed, Mar 23, 2016 at 11:32 PM, Robert Haas wrote:
> Well, I wouldn't go that far. It seems pretty clear that remote_apply
> by itself is useful - I can't imagine anybody seriously arguing the
> contrary, whatever they think of this implementation. My view,
> though, is that by itself that's p
On Thu, Mar 24, 2016 at 10:44 AM, Robert Haas wrote:
> On Wed, Mar 23, 2016 at 9:43 PM, Amit Kapila
> wrote:
> > RecordAndGetPageWithFreeSpace() tries to search from the oldPage passed
> to
> > it, rather than from top, so even if RecordPageWithFreeSpace() doesn't
> > update till root, it will
On Thu, Mar 24, 2016 at 5:18 AM, Petr Jelinek wrote:
> Hmm I see you are right, I missed the last couple emails. Ok I'll mark it
> ready for committer - it does work fine on my vs2015 machine and I am happy
> with the code too.
Thanks, let's see what others have to say.
> Well, as happy as I can
Hello,
At Thu, 24 Mar 2016 13:04:49 +0900, Masahiko Sawada
wrote in
> On Thu, Mar 24, 2016 at 11:34 AM, Fujii Masao wrote:
> > On Wed, Mar 23, 2016 at 5:32 PM, Kyotaro HORIGUCHI
> > wrote:
> >>> I don't think it's so difficult to extend this version so that
> >>> it supports also quorum commi
Hi,
At Tue, 22 Mar 2016 22:47:16 -0500, Jim Nasby wrote
in <56f211c4.6010...@bluetreble.com>
> On 3/22/16 10:35 PM, Kyotaro HORIGUCHI wrote:
> >> Even if we maintained some interlock for a backend's login role
> >> identity,
> >> >I hardly think it would be practical to e.g. lock during transien
On Thu, Mar 24, 2016 at 8:08 AM, Amit Kapila
wrote:
>
> On Thu, Mar 24, 2016 at 5:40 AM, Andres Freund wrote:
> >
> > Even after changing to scale 500, the performance benefits on this,
> > older 2 socket, machine were minor; even though contention on the
> > ClogControlLock was the second most s
Peter Geoghegan writes:
> On Mon, Mar 14, 2016 at 6:44 PM, Peter Geoghegan wrote:
>> I can produce a back-patchable variant of this if you and Peter E.
>> think this approach is okay.
> Where are we on this?
I'm generally okay with the approach used in
http://www.postgresql.org/message-id/CAM3S
On 2016/03/24 11:14, Michael Paquier wrote:
On Wed, Mar 23, 2016 at 10:05 PM, Thom Brown wrote:
I've noticed that you now can't cancel a query if there's DML pushdown
to a foreign server. This previously worked while it was sending
individual statements as it interrupted and rolled it back.
H
On Thu, Mar 24, 2016 at 11:34 AM, Fujii Masao wrote:
> On Wed, Mar 23, 2016 at 5:32 PM, Kyotaro HORIGUCHI
> wrote:
>> Hello,
>>
>> At Tue, 22 Mar 2016 23:08:36 +0900, Fujii Masao
>> wrote in
>>> On Tue, Mar 22, 2016 at 9:58 PM, Kyotaro HORIGUCHI
>>> wrote:
>>> > Thank you for the revised patc
On 2016/03/23 13:44, Ashutosh Bapat wrote:
An FDW can choose not to use those functions, so I don't see a
connection between scan list having simple Vars and existence of those
functions (actually a single one). But having those function would
minimize the code that each FDW has to write, in case
I wrote:
> Having said that, I also notice these dependencies:
> ...
> src/bin/initdb/encnames.c -> ../../../src/backend/utils/mb/encnames.c
> src/interfaces/libpq/encnames.c -> ../../../src/backend/utils/mb/encnames.c
> ...
> which seem like they'd be better handled by moving those files into
> sr
On Wed, Mar 23, 2016 at 8:05 PM, Tomas Vondra
wrote:
> FWIW, maintenance_work_mem was set to 1GB on the i5 machine and 256MB on the
> Xeon. Hmm, maybe that's why we see no difference for CREATE INDEX on the i5,
> and an improvement on the Xeon.
That would explain it.
> Not a big deal - it's easy
Hi,
On 03/24/2016 03:00 AM, Peter Geoghegan wrote:
On Tue, Mar 22, 2016 at 3:35 PM, Tomas Vondra
wrote:
I've tested the patch you've sent on 2016/3/11, which I believe is the last
version. I haven't tuned the replacement_sort_mem at all. because
my understanding was that it's not a 9.6 materia
On Wed, Mar 23, 2016 at 9:43 PM, Amit Kapila wrote:
> RecordAndGetPageWithFreeSpace() tries to search from the oldPage passed to
> it, rather than from top, so even if RecordPageWithFreeSpace() doesn't
> update till root, it will be able to search the newly added page. I agree
> with whatever yo
On Thu, Mar 24, 2016 at 5:40 AM, Andres Freund wrote:
>
> On 2016-03-23 21:43:41 +0100, Andres Freund wrote:
> > I'm playing around with SELECT txid_current(); right now - that should
> > be about the most specific load for setting clog bits.
>
> Or so I thought.
>
> In my testing that showed just
On Tue, Mar 22, 2016 at 2:27 PM, Tomas Vondra
wrote:
> For example these two queries got almost 2x as slow for some data sets:
>
> SELECT a FROM numeric_test UNION SELECT a FROM numeric_test_padding
> SELECT a FROM text_test UNION SELECT a FROM text_test_padding
>
> I assume the slowdown is relate
On Wed, Mar 23, 2016 at 5:32 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Tue, 22 Mar 2016 23:08:36 +0900, Fujii Masao wrote
> in
>> On Tue, Mar 22, 2016 at 9:58 PM, Kyotaro HORIGUCHI
>> wrote:
>> > Thank you for the revised patch.
>>
>> Thanks for reviewing the patch!
>>
>> > This version loo
On Wed, Mar 23, 2016 at 10:05 PM, Thom Brown wrote:
> I've noticed that you now can't cancel a query if there's DML pushdown
> to a foreign server. This previously worked while it was sending
> individual statements as it interrupted and rolled it back.
>
> Here's what the local server sees when
On Mon, Mar 14, 2016 at 6:44 PM, Peter Geoghegan wrote:
> I can produce a back-patchable variant of this if you and Peter E.
> think this approach is okay.
Where are we on this?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
On Tue, Mar 22, 2016 at 3:35 PM, Tomas Vondra
wrote:
> I've tested the patch you've sent on 2016/3/11, which I believe is the last
> version. I haven't tuned the replacement_sort_mem at all. because my
> understanding was that it's not a 9.6 material (per your message). So my
> intent was to test
On Thu, Mar 24, 2016 at 12:09 AM, Robert Haas wrote:
>
> On Tue, Mar 22, 2016 at 1:12 PM, Petr Jelinek
wrote:
>
> I've read this over several times and looked at
> RecordAndGetPageWithFreeSpace() and I'm still confused. First of all,
> if the lock was acquired by some other backend which did
> R
I don't quite see how this is supposed to work:
+ #ifdef WAL_DEBUG
+ /*
+* If xlog debug is enabled then check produced delta. Result of delta
+* application to saved image should be the same as current page state.
+*/
+ if (XLOG_DEBUG)
+ {
+ chartmp[BLCKSZ];
+ m
On Thu, Mar 24, 2016 at 1:53 AM, Robert Haas wrote:
> On Wed, Mar 23, 2016 at 5:24 AM, Rajkumar Raghuwanshi
> wrote:
>> Thanks Ashutosh for the patch. I have apply and retested it, now not getting
>> server crash.
>
> Thanks for the report and the testing. I have committed the patch.
Cool, I ha
Hi,
On Tue, Mar 1, 2016 at 7:06 AM, Alexander Korotkov wrote:
> I finally went over your review.
I'll respond to your points here. Note that I'm reviewing
"partial-sort-basic-7.patch", which you sent on March 13. I respond
here because this is where you answered my questions (I had no
feedback o
On Wed, Mar 23, 2016 at 11:01 PM, Tom Lane wrote:
> Michael Paquier writes:
>> That's ugly. We should actually use TextDatumGetCString because the
>> index is stored as text here via a Datum, and then it is converted
>> back to an integer. So I propose instead the simple patch attached
>> that fi
Hi,
On 2016-03-24 01:10:55 +0100, Andres Freund wrote:
> I'm afraid that this patch might be putting bandaid on some of the
> absolutely worst cases, without actually addressing the core
> problem. Simon's patch in [1] seems to come closer addressing that
> (which I don't believe it's safe without
On 2016-03-23 21:43:41 +0100, Andres Freund wrote:
> I'm playing around with SELECT txid_current(); right now - that should
> be about the most specific load for setting clog bits.
Or so I thought.
In my testing that showed just about zero performance difference between
the patch and master. And
On 24 March 2016 at 02:01, Merlin Moncure wrote:
> > If you plan to have "prepare if not exists" at startup only, why don't
> > you just wrap it with
> > exception handler then?
>
> That's impolite to our users. Virtually all other commands have been
> decorated with IF [NOT] exists to avoid ha
On 23 March 2016 at 23:54, Alvaro Herrera wrote:
> Craig Ringer wrote:
> > Hi all
> >
> > As part of some internal training/discussion I wrote some notes on
> logical
> > decoding's structure and flow that seemed worth polishing up into a draft
> > README for src/backend/replication/logical .
>
>
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> And where to put the corresponding header files?
> >> src/include/fe-utils?
>
> > Sounds fair but would that be installed in PREFIX/include/server?
> > That'd be a bit odd, but I'm not -1 on that.
>
> The only other plan I can thi
> I'm something of a backwards compatibility zealot, but I've become one for
> very good reasons. Personally, I'd rather we'd define precisely the usages
> that are deprecated (I guess SRF-tlist in the presence of
> FROM) and force them to error out with an appropriate HINT rather than give a
I wrote:
> ... I'd love to
> toss the entire SRF-in-tlist feature overboard one of these years,
> both because of semantic issues like these and because a fair amount
> of code and overhead could be ripped out if it were disallowed.
> But I don't know how we get to that --- as Merlin says, there's
Le 22/03/2016 14:44, Michael Paquier a écrit :
> On Sat, Mar 12, 2016 at 12:46 AM, Gilles Darold
> wrote:
>> Here is the patch rewritten to use alternate file
>> $PGDATA/pg_log_filename to store the current log filename used by
>> syslogger. All examples used in the first mail of this thread work
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Wed, Mar 23, 2016 at 2:11 PM, Tom Lane wrote:
> > In the meantime I suppose there's a case to be made for preserving
> > bug compatibility as much as possible.
> >
> > So anyway the question is whether to commit the attached or not.
>
>
On Wed, Mar 23, 2016 at 2:11 PM, Tom Lane wrote:
>
>
> In the meantime I suppose there's a case to be made for preserving
> bug compatibility as much as possible.
>
> So anyway the question is whether to commit the attached or not.
+1 for commit - I'll trust Tom on the quality of the patch
Stephen Frost writes:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> I'm something of a backwards compatibility zealot, but I've become one
>> for very good reasons. Personally, I'd rather we'd define precisely
>> the usages that are deprecated (I guess SRF-tlist in the presence of
>> FROM) an
Alvaro Herrera writes:
> Tom Lane wrote:
>> And where to put the corresponding header files?
>> src/include/fe-utils?
> Sounds fair but would that be installed in PREFIX/include/server?
> That'd be a bit odd, but I'm not -1 on that.
The only other plan I can think of is to put the .h files descr
On 2016-03-23 12:33:22 +0530, Amit Kapila wrote:
> On Wed, Mar 23, 2016 at 12:26 PM, Amit Kapila
> wrote:
> >
> > On Tue, Mar 22, 2016 at 4:22 PM, Andres Freund wrote:
> > >
> > >
> > > I think it's worthwhile to create a benchmark that does something like
> > > BEGIN;SELECT ... FOR UPDATE; SELEC
Michael Meskes wrote:
More than you think.
I doubt you want to propose removing features that make developing new
features harder, or do you? :)
I want to understand the situation. You may want to make the build ecpg
optional. Personally, I want to.
--
Yury Zhuravlev
Postgres Professional:
Merlin> All I'm saying is that the use of
Merlin> server side prepared statements is extremely problematic in
Merlin> conjunction with pgbouncer
I've filed https://github.com/pgbouncer/pgbouncer/issues/126 to get
pgbouncer improved in regard to prepared statements.
Vladimir
--
Sent via pgsql-h
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane wrote:
> > which is both SQL-standard semantics and much more efficient than
> > SRF-in-tlist. We've more or less deprecated SRF-in-tlist since we
> > introduced LATERAL in 9.3. How much are we willing to d
On 23/03/16 13:05, Michael Paquier wrote:
OK, the please send an updated set of patches for what remains.
Here you go:
- 0001 fixes the global declarations of TIMEZONE_GLOBAL and
TZNAME_GLOBAL to be WIN32-compliant. I got bitten by that in the ECPG
compilation.
- 0002, support of VS2015 in th
Merlin,
* Merlin Moncure (mmonc...@gmail.com) wrote:
> No one is arguing that that you should send it any every time (at
> least -- I hope not).
I'm not sure I follow how you can avoid that though?
pgbouncer in transaction pooling mode may let a particular connection
die off and then, when you i
On Wed, Mar 23, 2016 at 2:17 PM, Vladimir Sitnikov
wrote:
> Merlin>proposed would allow use of server side prepared statements with JDBC.
>
> It would not. If we discuss end-to-end scenarios in detail, we would end up
> with
> "send full query on each execution" -> lex/gram on each execution kind
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> > Actually you could just list them in OBJS_FRONTEND in src/common. That
> > way they're not built for the server at all; no need for a new subdir.
>
> Meh. I think stuff in OBJS_FRONTEND has to be pretty weird special
> cases, suc
On 23/03/16 20:43, Robert Haas wrote:
On Wed, Mar 23, 2016 at 3:33 PM, Petr Jelinek wrote:
Btw thinking about it some more, ISTM that not finding the block and just
doing the extension if the FSM wasn't extended correctly previously is
probably cleaner behavior than what we do now. The reasonin
On Wed, Mar 23, 2016 at 3:33 PM, Petr Jelinek wrote:
> Btw thinking about it some more, ISTM that not finding the block and just
> doing the extension if the FSM wasn't extended correctly previously is
> probably cleaner behavior than what we do now. The reasoning for that
> opinion is that if the
>>
>> Multicolumn BRIN is like GIN. Every column is indexed separately.
>> The order of the columns doesn't matter.
>
> Right. You can use one index to cover all columns; the position of the
> column in the index won't matter for a query that uses one column. The
> only reason to have multiple B
Alvaro Herrera writes:
> Tom Lane wrote:
>> Note: the reason for a new subdirectory, rather than putting this
>> stuff into src/common/, is that src/common/ is meant for code that's
>> shared between frontend and backend, which this stuff is not. Also,
>> many of these files depend on libpq which
On 23/03/16 20:19, Petr Jelinek wrote:
On 23/03/16 20:01, Robert Haas wrote:
On Wed, Mar 23, 2016 at 2:52 PM, Petr Jelinek
wrote:
Second, if the other backend extended the relation in
some other manner and did not extend the FSM, how does calling
RecordAndGetPageWithFreeSpace help? As far as
On 23/03/16 20:01, Robert Haas wrote:
On Wed, Mar 23, 2016 at 2:52 PM, Petr Jelinek wrote:
Second, if the other backend extended the relation in
some other manner and did not extend the FSM, how does calling
RecordAndGetPageWithFreeSpace help? As far as I can see,
GetPageWithFreeSpace and Reco
Merlin>proposed would allow use of server side prepared statements with JDBC.
It would not. If we discuss end-to-end scenarios in detail, we would end up with
"send full query on each execution" -> lex/gram on each execution kind
of overheads.
That is hardly a proper way of using prepared stateme
"David G. Johnston" writes:
> On Wednesday, March 23, 2016, Tom Lane wrote:
>> ... We've more or less deprecated SRF-in-tlist since we
>> introduced LATERAL in 9.3. How much are we willing to do to stay
>> bug-compatible with old behaviors here?
> My gut reaction is that this is an unnecessary
On Wed, Mar 23, 2016 at 2:52 PM, Petr Jelinek wrote:
>> Second, if the other backend extended the relation in
>> some other manner and did not extend the FSM, how does calling
>> RecordAndGetPageWithFreeSpace help? As far as I can see,
>> GetPageWithFreeSpace and RecordAndGetPageWithFreeSpace are
On 23/03/16 19:39, Robert Haas wrote:
On Tue, Mar 22, 2016 at 1:12 PM, Petr Jelinek wrote:
I also think the code simplicity makes this worth it.
Agreed. I went over this patch and did a cleanup pass today. I
discovered that the LockWaiterCount() function was broken if you try
to tried to u
On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane wrote:
> which is both SQL-standard semantics and much more efficient than
> SRF-in-tlist. We've more or less deprecated SRF-in-tlist since we
> introduced LATERAL in 9.3. How much are we willing to do to stay
> bug-compatible with old behaviors here?
On Tue, Mar 22, 2016 at 1:12 PM, Petr Jelinek wrote:
> I also think the code simplicity makes this worth it.
Agreed. I went over this patch and did a cleanup pass today. I
discovered that the LockWaiterCount() function was broken if you try
to tried to use it on a lock that you didn't hold or
On Wed, Mar 23, 2016 at 1:15 PM, Vladimir Sitnikov
wrote:
> Merlin>No one is arguing that that you should send it any every time (at
> least -- I hope not).
>
> Well, what is your suggestion exactly?
>
> pgjdbc is NOT using "prepare ..." sql command.
> I'm inclined to suppose, it will not use "pre
On Wednesday, March 23, 2016, Tom Lane wrote:
> "Regina Obe" > writes:
> > In the past couple of weeks our PostGIS tests against PostgreSQL 9.6 dev
> > started failing. I traced the issue down to a behavior change in 9.6
> when
> > dealing with output of set returning functions when used with (f
Hi,
I'll add couple of code comments from my first cursory read through
(this is huge):
0002:
there is some whitespace noise between the varlistentries in
alter_statistics.sgml
+ parentobject.classId = RelationRelationId;
+ parentobject.objectId = ObjectIdGetDatum(RelationGetRel
Merlin>No one is arguing that that you should send it any every time (at
least -- I hope not).
Well, what is your suggestion exactly?
pgjdbc is NOT using "prepare ..." sql command.
I'm inclined to suppose, it will not use "prepare..." even after your fix.
Merlin>Again, not in pooling scenarios
M
Tom Lane wrote:
> Note: the reason for a new subdirectory, rather than putting this
> stuff into src/common/, is that src/common/ is meant for code that's
> shared between frontend and backend, which this stuff is not. Also,
> many of these files depend on libpq which seems like an inappropriate
Vladimir Sitnikov writes:
> 2016-03-23 16:21 GMT+03:00 Merlin Moncure :
>> On Wed, Mar 23, 2016 at 7:27 AM, Craig Ringer wrote:
> Craig>> With PREPARE IF NOT EXISTS the client is also paying parse and network
> Craig>> overhead for every time you send that statement. Much better
> Craig>> not to
On Wed, Mar 23, 2016 at 12:46 PM, Vladimir Sitnikov
wrote:
> 2016-03-23 16:21 GMT+03:00 Merlin Moncure :
> Merlin> A typical pattern is for the application to
> Merlin> prepare them all upon startup, but currently each PREPARE needs to be
> Merlin> wrapped with an exception handler in case someone
On 23/03/16 14:17, Alvaro Herrera wrote:
Petr Jelinek wrote:
+++ b/contrib/test_decoding/sql/messages.sql
@@ -0,0 +1,17 @@
+-- predictability
+SET synchronous_commit = on;
+
+SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot',
'test_decoding');
+
+SELECT 'msg1' FROM pg_log
2016-03-23 16:21 GMT+03:00 Merlin Moncure :
> On Wed, Mar 23, 2016 at 7:27 AM, Craig Ringer wrote:
Craig>> With PREPARE IF NOT EXISTS the client is also paying parse and network
Craig>> overhead for every time you send that statement. Much better
not to send it
Craig>> repeatedly in the first plac
Robert Haas writes:
> On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane wrote:
>> I'm also a bit dubious of the assumption in RemoveOperatorById that an
>> operator can't be its own negator. Yeah, that should not be the case,
>> but if it is the case the deletion will fail outright.
> So what? We've
"Regina Obe" writes:
> In the past couple of weeks our PostGIS tests against PostgreSQL 9.6 dev
> started failing. I traced the issue down to a behavior change in 9.6 when
> dealing with output of set returning functions when used with (func).*
> syntax.
> CREATE OR REPLACE FUNCTION dumpset(para
On 23/03/16 09:14, Kouhei Kaigai wrote:
On 15/03/16 05:03, Kouhei Kaigai wrote:
Petr,
The attached patch is the revised one that follows the new extensible-
node routine.
It is almost same the previous version except for:
- custom-apis.[ch] was renamed to custom-node.[ch]
- check for the lengt
On Wed, Mar 23, 2016 at 5:55 PM, Tom Lane wrote:
> I'm not terribly happy with the hack I used to get pgbench to be able
> to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build
> scripts, and I have seen it causing two concurrent builds of psqlscan.o
> in parallel builds, which is li
On 23/03/16 17:55, Tom Lane wrote:
I'm not terribly happy with the hack I used to get pgbench to be able
to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build
scripts, and I have seen it causing two concurrent builds of psqlscan.o
in parallel builds, which is likely to cause a build
On Wed, Mar 23, 2016 at 12:55 PM, Tom Lane wrote:
> I'm not terribly happy with the hack I used to get pgbench to be able
> to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build
> scripts, and I have seen it causing two concurrent builds of psqlscan.o
> in parallel builds, which is li
Alvaro Herrera wrote:
> > tuple = (HeapTuple) palloc0(HEAPTUPLESIZE + len);
> >
> > which fails because (HEAPTUPLESIZE + len) is again considered
> > an invalid size, the size being 1468006476 in my test.
>
> Um, it seems reasonable to make this one be a huge-zero-alloc:
>
> Me
On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> I did not find this version very clear. It wasn't consistent about
>> using ObjectIdGetDatum() where needed, but the bigger problem was that
>> I found the logic unnecessarily convoluted. I rewrote it - I believe
>> more
Hi.
I implemented "ALTER FUNCTION … DEPENDS ON EXTENSION" using a new node
(AlterObjectDependsStmt), and tried to add "ALTER TRIGGER … DEPENDS ON
EXTENSION" (partly because I wanted to make sure the code could support
multiple object types, partly because it's convenient in this particular
use cas
In the past couple of weeks our PostGIS tests against PostgreSQL 9.6 dev
started failing. I traced the issue down to a behavior change in 9.6 when
dealing with output of set returning functions when used with (func).*
syntax.
Here is an example not involving PostGIS. Is this an intentional chang
I'm not terribly happy with the hack I used to get pgbench to be able
to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build
scripts, and I have seen it causing two concurrent builds of psqlscan.o
in parallel builds, which is likely to cause a build failure some of
the time. Another un
On Wed, Mar 23, 2016 at 5:24 AM, Rajkumar Raghuwanshi
wrote:
> Thanks Ashutosh for the patch. I have apply and retested it, now not getting
> server crash.
Thanks for the report and the testing. I have committed the patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
Robert Haas writes:
> I did not find this version very clear. It wasn't consistent about
> using ObjectIdGetDatum() where needed, but the bigger problem was that
> I found the logic unnecessarily convoluted. I rewrote it - I believe
> more straightforwardly - as attached. How does this look?
I
On Wed, Mar 23, 2016 at 8:21 AM, Merlin Moncure wrote:
> I'm not understanding the objection at all. You have N client
> sessions connecting to the database that all utilize the same named
> prepared statement. A typical pattern is for the application to
> prepare them all upon startup, but curr
> PS Who use ecpg? For me it's like hell.
More than you think.
I doubt you want to propose removing features that make developing new
features harder, or do you? :)
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot
On Wed, Mar 23, 2016 at 10:57 AM, Jim Nasby wrote:
> On 3/22/16 8:37 AM, Merlin Moncure wrote:
>>>
>>> I afraid of useless and forgotten call of functions. But the risk is same
>>> >like PERFORM - so this is valid from one half. The PERFORM statement
>>> > holds
>>> >special semantic, and it is in
On 3/22/16 7:28 AM, Michael Paquier wrote:
On Mon, Mar 21, 2016 at 7:55 AM, Jim Nasby wrote:
On 3/17/16 9:01 AM, Robert Haas wrote:
I think that
there are an awful lot of cases where extension authors haven't been
able to quite do what they want to do without core changes because
they couldn'
> Thanks! I can't think of anything else to worry about with regards to
> that version, so I have committed it.
>
Thanks, Robert. And thanks everyone for contributing to this patch.
--
Best regards,
Aleksander Alekseev
http://eax.me/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On Tue, Mar 22, 2016 at 9:25 PM, Tomas Vondra
wrote:
> OK, the new code seems more comprehensible to me.
I did not find this version very clear. It wasn't consistent about
using ObjectIdGetDatum() where needed, but the bigger problem was that
I found the logic unnecessarily convoluted. I rewrot
On 3/22/16 8:37 AM, Merlin Moncure wrote:
I afraid of useless and forgotten call of functions. But the risk is same
>like PERFORM - so this is valid from one half. The PERFORM statement holds
>special semantic, and it is interesting.
I see your point here, but the cost of doing that far outweigh
Craig Ringer wrote:
> Hi all
>
> As part of some internal training/discussion I wrote some notes on logical
> decoding's structure and flow that seemed worth polishing up into a draft
> README for src/backend/replication/logical .
That's nice, but you attached the one in src/backend/replication
i
Fabrízio de Royes Mello wrote:
I got an error when build this patch.
I fix it! All tests pass (include ecpg tests).
Patch in attachment.
Thanks.
PS Who use ecpg? For me it's like hell.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff -
On 18.03.2016 20:19, Anastasia Lubennikova wrote:
Please, find the new version of the patch attached. Now it has WAL
functionality.
Detailed description of the feature you can find in README draft
https://goo.gl/50O8Q0
This patch is pretty complicated, so I ask everyone, who interested in
On Wed, Mar 23, 2016 at 5:49 AM, Aleksander Alekseev
wrote:
> I still believe that optimizing 1% blindly without considering possible
> side effects this optimization can bring (other data alignment, some
> additional machine instructions - just to name a few) and having no
> way to measure these
On Wed, 23 Mar 2016 10:13:42 -0300
Alvaro Herrera wrote:
> Andreas Karlsson escribió:
> > On 03/23/2016 01:55 PM, Eduardo Morras wrote:
> > >Benefits:
> > >
> > >Dynamic multihoming, modifiable at run time, don't need aggregate
> > >links at OS level or shutdown servers/clients for a hardware or
> Hi
> I just add something in struct PGPORC, such as "int level", But I
> cann't seet what I added in MyProc while debugging. That's confused,
>
>
> zhangxiaojian
I think you forgot to run `make clean` after changing proc.h. When you
change header files dependent files are not recompil
On Wed, 23 Mar 2016 14:03:31 +0100
Andreas Karlsson wrote:
> On 03/23/2016 01:55 PM, Eduardo Morras wrote:
> > Benefits:
> >
> > Dynamic multihoming, modifiable at run time, don't need aggregate
> > links at OS level or shutdown servers/clients for a hardware or
> > topology network change. Messa
On Wed, Mar 23, 2016 at 8:43 AM, Michael Paquier
wrote:
> On Wed, Mar 23, 2016 at 8:39 PM, Robert Haas wrote:
>> On Wed, Mar 23, 2016 at 7:34 AM, Thomas Munro
>> wrote:
>>> synchronous_commitTPS
>>>
>>> off 9234
>>> local1223
>>> rem
On 03/23/2016 02:13 PM, Alvaro Herrera wrote:
Andreas Karlsson escribió:
On 03/23/2016 01:55 PM, Eduardo Morras wrote:
Benefits:
Dynamic multihoming, modifiable at run time, don't need aggregate links at OS
level or shutdown servers/clients for a hardware or topology network change.
Message o
Hi
I just add something in struct PGPORC, such as "int level", But I cann't
seet what I added in MyProc while debugging. That's confused,
zhangxiaojian
Michael Paquier writes:
> That's ugly. We should actually use TextDatumGetCString because the
> index is stored as text here via a Datum, and then it is converted
> back to an integer. So I propose instead the simple patch attached
> that fixes the failure for me. Could you check if that works for
Andreas Karlsson escribió:
> On 03/23/2016 01:55 PM, Eduardo Morras wrote:
> >Benefits:
> >
> >Dynamic multihoming, modifiable at run time, don't need aggregate links at
> >OS level or shutdown servers/clients for a hardware or topology network
> >change.
> >Message oriented connection.
> >Messag
Petr Jelinek wrote:
> +++ b/contrib/test_decoding/sql/messages.sql
> @@ -0,0 +1,17 @@
> +-- predictability
> +SET synchronous_commit = on;
> +
> +SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot',
> 'test_decoding');
> +
> +SELECT 'msg1' FROM pg_logical_emit_message(true, 't
1 - 100 of 132 matches
Mail list logo
