Hello,
At Fri, 19 Jan 2018 11:28:58 +, Greg Stark wrote in
> On 19 January 2017 at 09:37, Kyotaro HORIGUCHI
> wrote:
> >
> > Though I haven't look closer to how a modification is splitted
> > into WAL records. A tuple cannot be so long. As a simple test, I
> > observed rechder->xl_tot_len
On Tue, Jan 23, 2018 at 4:17 AM, Edmund Horner wrote:
> Hi Vik, thanks for the feedback!
>
Don't forget to include the list :-)
I'm quoting the entirety of the message---which I would normally trim---for
the archives.
> On 23 January 2018 at 07:41, Vik Fearing
> wrote:
> > This looks better.
At Fri, 19 Jan 2018 18:24:56 +0900, Michael Paquier
wrote in <20180119092456.ga1...@paquier.xyz>
> On Fri, Jan 19, 2018 at 10:54:53AM +0900, Kyotaro HORIGUCHI wrote:
> > On the other hand if one logical record must be read from single
> > source, we need any means to deterrent wal-recycling on th
On 23 January 2018 at 05:08, Jeff Davis wrote:
> On Fri, Jan 19, 2018 at 2:07 AM, Simon Riggs wrote:
>> err... that isn't correct. An empty range matches nothing, so can be
>> ignored in joins.
>>
>> So probably best to explain some more, please.
>
> The semantics of R1 @> R2 will return true if
Hi David.
On 2018/01/23 15:44, David Rowley wrote:
> On 19 January 2018 at 04:03, David Rowley
> wrote:
>> On 18 January 2018 at 23:56, Amit Langote
>> wrote:
>>> So, I've been assuming that the planner changes in the run-time pruning
>>> patch have to do with selecting clauses (restriction cl
There is a bug connected with invalidation pg catalog cache in trigger
functions
Another example of this bug I have already reported [1]
The following bug has been logged on the website:
Bug reference: 14879
Logged by: Konstantin Evteev
Email address: konst583(at)gmail(dot)com
Em ter, 23 de jan de 2018 às 03:36, Masahiko Sawada
escreveu:
> Hi all,
>
> While reading the code, I realized that the requesting an autovacuum
> work-item could fail in silence if work-item array is full. So the
> users cannot realize that work-item is never performed.
> AutoVacuumRequestWork()
(2017/12/13 16:38), Amit Langote wrote:
I recently posted to the list about a couple of problems I saw when using
array type column as the partition key. One of them was that the internal
partition constraint expression that we generate for list partitions is of
a form that the backend would rej
Hi,
The current master HEAD fails pg_upgrade tests on my machine.
If I revert the "Move handling of database properties from pg_dumpall
into pg_dump." commit b3f8401205afdaf63cb20dc316d44644c933d5a1 the test
passes.
The error is:
pg_restore: creating RULE "public.rtest_emp rtest_emp_del"
pg_res
Here is a comment for get_qual_for_list in partition.c:
* get_qual_for_list
*
* Returns an implicit-AND list of expressions to use as a list partition's
- * constraint, given the partition key and bound structures.
I don't think the part "given the partition key and bound structures."
is co
Hi
2018-01-23 8:13 GMT+01:00 Kyotaro HORIGUCHI :
> Hello, I returned to this.
>
> I thouroughly checked the translator's behavior against the XPath
> specifications and checkd out the documentation and regression
> test. Almost everything is fine for me and this would be the last
> comment from m
On Tue, Jan 23, 2018 at 12:21:51PM +0100, Marco Nenciarini wrote:
> into pg_dump." commit b3f8401205afdaf63cb20dc316d44644c933d5a1 the test
> passes.
>
> The error is:
>
> pg_restore: creating RULE "public.rtest_emp rtest_emp_del"
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_res
Hai all,
We are building In-memory index extension for postgres. We would
capture table inserts, updates, deletes using triggers. During vacuum
operation, postgres would give calls to ambulkdelete, amvacuumcleanup (as
part of index cleanup). As we handle all updates, deletes using triggers,
w
Il 22/01/18 19:41, Petr Jelinek ha scritto:
> On 19/01/18 12:41, Marco Nenciarini wrote:
>> Hi Peter,
>>
>> Il 18/01/18 17:30, Peter Eisentraut ha scritto:
>>> On 1/17/18 11:33, Petr Jelinek wrote:
> P.S: I'm struggling to understand why we have two possible values of
> session_replication_
On 23.01.2018 01:41, Andrew Dunstan wrote:
On 01/17/2018 04:01 PM, Andrew Dunstan wrote:
On 01/15/2018 07:24 PM, Andrew Dunstan wrote:
On 01/10/2018 05:42 PM, Nikita Glukhov wrote:
Attached new 8th version of jsonpath related patches. Complete
documentation is still missing.
The first 4 smal
On Fri, Jan 12, 2018 at 11:43 AM, amul sul wrote:
>
> Thanks for looking at this thread, attached herewith an updated patch rebase
> on
> 'UPDATE of partition key v35' patch[1].
>
ExecDelete(mtstate, tupleid, oldtuple, planSlot, epqstate, estate,
- &tuple_deleted, false, false);
+ &tuple_d
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
This patch seems to be in a pretty good shape. There is a roo
On Mon, Jan 22, 2018 at 7:17 PM, Robert Haas wrote:
> On Sun, Jan 21, 2018 at 9:02 AM, Amit Kapila wrote:
>> How about adding a project to support Unique capability for the Hash
>> Index?
>
> Hmm, that seems pretty hard.
>
Yeah, but I think here hard part is to decide the solution to achieve
it.
On 1/19/18 4:43 PM, Peter Eisentraut wrote:
> On 1/19/18 14:07, David Steele wrote:
>> I have yet to add tests for pg_rewindwal and pg_upgrade. pg_rewindwal
>> doesn't *have* any tests as far as I can tell and pg_upgrade has tests
>> in a shell script -- it's not clear how I would extend it or reu
On 22 January 2018 at 20:03, Petr Jelinek wrote:
> On 22/01/18 20:21, Robert Haas wrote:
>>> The other option would be to make sure 2PC decoding/tx streaming does
>>> not read aborted transaction but that would mean locking the transaction
>>> every time we give control to output plugin. Given th
On 1/20/18 5:47 PM, Michael Paquier wrote:
> On Fri, Jan 19, 2018 at 06:54:23PM -0300, Alvaro Herrera wrote:
>> Peter Eisentraut wrote:
>> If the only problem is that buildfarm would run tests twice, then I
>> think we should just press forward with this regardless of that: it
>> seems a chicken-an
David Steele writes:
> Unless I read it wrong the buildfarm is not doing cross-version
> upgrades, but a developer/user can do so manually using the same script?
The buildfarm isn't doing that *by default*, but Andrew has at least
one critter configured to do so (crake I think). It found a bug j
On 23/01/18 13:34, Marco Nenciarini wrote:
> Il 22/01/18 19:41, Petr Jelinek ha scritto:
>> On 19/01/18 12:41, Marco Nenciarini wrote:
>>> Hi Peter,
>>>
>>> Il 18/01/18 17:30, Peter Eisentraut ha scritto:
On 1/17/18 11:33, Petr Jelinek wrote:
>> P.S: I'm struggling to understand why we hav
On 1/23/18 9:26 AM, Tom Lane wrote:
> David Steele writes:
>> Unless I read it wrong the buildfarm is not doing cross-version
>> upgrades, but a developer/user can do so manually using the same script?
>
> The buildfarm isn't doing that *by default*, but Andrew has at least
> one critter configur
On Mon, Jan 22, 2018 at 5:15 PM, Stephen Frost wrote:
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> here is a GUC based patch for plancache controlling. Looks so this code is
>> working.
>
> This really could use a new thread, imv. This thread is a year old and
> about a comple
> On 23 Jan 2018, at 03:24, Michael Paquier wrote:
>
> On Mon, Jan 22, 2018 at 04:52:11PM +0100, Daniel Gustafsson wrote:
>> Not really, but IIUC a bug in this code could lead to channel binding
>> not being used for a connection even if the user wanted it (and may
>> miss that ixt didn’t happen
Marco Nenciarini writes:
> The current master HEAD fails pg_upgrade tests on my machine.
Yup, see <12453.1516655...@sss.pgh.pa.us>
regards, tom lane
2018-01-23 15:35 GMT+01:00 Robert Haas :
> On Mon, Jan 22, 2018 at 5:15 PM, Stephen Frost wrote:
> > Pavel,
> >
> > * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> >> here is a GUC based patch for plancache controlling. Looks so this code
> is
> >> working.
> >
> > This really could use a new
On Mon, Jan 22, 2018 at 4:23 PM, Tom Lane wrote:
>> If nobody is willing to put in the effort to keep AIX supported under
>> XLC, then we should just update the documentation to say that it isn't
>> supported. Our support for that platform is pretty marginal anyway if
>> we're only supporting it
> I must be missing something in this discussion, cos I don't see any
> problems with this "other option".
>
> Surely we prepare the 2PCxact and then it is persistent. Yes,
> potentially for an unbounded period of time. And it is (usually) up to
> the XA manager to resolve that. 2PC interacts with
> On 23 Jan 2018, at 05:52, Michael Paquier wrote:
>
> On Mon, Jan 22, 2018 at 12:48:45PM +0100, Daniel Gustafsson wrote:
>
>> Not sure how much they’re worth in "make check” though as it’s quite
>> easy to add a new option checked with pg_strcasecmp which then isn’t
>> tested. Still, it might a
Greetings Sergei,
* Sergei Kornilov (s...@zsrv.org) wrote:
> I update patch and also rebase to current head. I hope now it is better
> aligned with project style
Thanks for updating it and continuing to work on it. I haven't done a
full review but there were a few things below that I thought co
On Sun, Jan 21, 2018 at 11:02:29AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Jan 19, 2018 at 02:54:25PM -0500, Tom Lane wrote:
> >> Command was: DROP DATABASE "template1";
>
> > Uh, the oid of the template1 database is 1, and I assume we would want
> > to preserve that too.
>
>
Sorry, I forgot to show version of PostgreSQL:
https://www.postgresql.org/message-id/CAAqA9PQXEmG%3Dk3WpDTmHZL-VKcMpDEA3ZC06Qr0ASO3oTA7bdw%40mail.gmail.com
"Invalidation pg catalog cache in trigger functions"
was detected on "PostgreSQL 9.2.18 on x86_64-unknown-linux-gnu, compiled by
gcc (Ubuntu 4.
2018-01-22 23:15 GMT+01:00 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > here is a GUC based patch for plancache controlling. Looks so this code
> is
> > working.
>
> This really could use a new thread, imv. This thread is a year old and
> about a completely di
On Mon, Jan 22, 2018 at 10:56 PM, Amit Kapila wrote:
> It does turn such cases into error but only at the end when someone
> calls WaitForParallelWorkersToFinish. If one tries to rely on it at
> any other time, it won't work as I think is the case for Parallel
> Create Index where Peter G. is try
Haribabu Kommi writes:
> On Tue, Jan 23, 2018 at 8:56 AM, Tom Lane wrote:
>> I'm thinking we'd still need to do what I said in the previous message,
>> and change pg_dump so that the restore session will absorb ALTER DATABASE
>> settings before proceeding. Otherwise, at minimum, we have a hazard
On Tue, Jan 23, 2018 at 8:44 AM, Amit Kapila wrote:
> On Sat, Jan 20, 2018 at 2:03 AM, Robert Haas wrote:
>> Allow UPDATE to move rows between partitions.
>
> +If an UPDATE on a partitioned table causes a row to
> move
> +to another partition, it will be performed as a DELETE
> +from
Greetings Alexander,
* Alexander Kuzmenkov (a.kuzmen...@postgrespro.ru) wrote:
> Here is the patch rebased to a852cfe9.
Thanks for updating it. This would definitely be nice to have.
Ashutosh, thanks for your previous review, would you have a chance to
look at it again? Would be great to at lea
On 1/16/18 01:14, Michael Paquier wrote:
>> I don't see it either. I think the actually useful parts of that patch
>> were to declare record_image_cmp's result correctly as int rather than
>> bool, and to cope with varlena fields of unequal size. Unfortunately
>> there seems to be no contemporane
-- Forwarded message --
From: "Abinaya k"
Date: Jan 23, 2018 1:43 PM
Subject: Regarding ambulkdelete, amvacuumcleanup index methods
To:
Cc:
Hai all,
We are building In-memory index extension for postgres. We would
capture table inserts, updates, deletes using triggers. Duri
On 1/19/18 16:54, Alvaro Herrera wrote:
> If the only problem is that buildfarm would run tests twice, then I
> think we should just press forward with this regardless of that: it
> seems a chicken-and-egg problem, because buildfarm cannot be upgraded to
> use some new test method if the method doe
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> The most obvious hack is just to exclude PL objects with OIDs below 16384
>> from the dump. An issue with that is that it'd lose any nondefault
>> changes to the ACL for plpgsql, which seems like a problem. On the
>> other hand, I
Il 22/01/18 23:18, Petr Jelinek ha scritto:
> On 22/01/18 19:45, Petr Jelinek wrote:
>
> Actually on second look, I don't like the new boolean parameter much.
> I'd rather we didn't touch the input list and always close only
> relations opened inside the ExecuteTruncateGuts().
>
> It may mean mor
Bruce Momjian writes:
> Oh, I see what you mean. I was just worried that some code might expect
> template1 to always have an oid of 1, but we can just call that code
> broken.
Ever since we invented template0, it's been possible to drop and recreate
template1, so I'd say any expectation that it
On 1/23/18 09:33, David Steele wrote:
> What if I update pg_upgrade/test.sh to optionally allow group
> permissions and we configure an animal to test it if it gets committed?
>
> It's not ideal, I know, but it would get the permissions patch over the
> line and is consistent with how we currently
Peter Eisentraut writes:
> On 1/19/18 16:54, Alvaro Herrera wrote:
>> If the only problem is that buildfarm would run tests twice, then I
>> think we should just press forward with this regardless of that: it
>> seems a chicken-and-egg problem, because buildfarm cannot be upgraded to
>> use some n
On 1/18/18 18:42, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 17, 2018 at 3:50 PM, Nikolay Shaplov wrote:
>>> This patch raises error if user tries o set or change toast.* option for a
>>> table that does not have a TOST relation.
> There might be a case for raising a warning in this si
On 1/17/18 23:57, Ashutosh Sharma wrote:
> By elsewhere do you mean in the contrib module 'sepgsql'
> (sepgsql/sql/ddl.sql) because other than that i didn't find any other
> places having ALTER TABLE ... ADD CONSTRAINT ... EXCLUDE ... sort of
> sql queries other than the files which i mentioned in
On 1/22/18 02:29, Michael Paquier wrote:
> However there is as well the argument that this list's contents are not
> directly used now, and based on what I saw from the MacOS SSL and GnuTLS
> patches that would not be the case after either.
Right, there is no facility for negotiating the channel b
Hi,
On 23/01/18 15:38, Marco Nenciarini wrote:
> Il 22/01/18 23:18, Petr Jelinek ha scritto:
>> On 22/01/18 19:45, Petr Jelinek wrote:
>>
>> Actually on second look, I don't like the new boolean parameter much.
>> I'd rather we didn't touch the input list and always close only
>> relations opened
On 1/21/18 18:08, Daniel Gustafsson wrote:
> As per before, my patch for running tests against another set of binaries is
> included as well as a fix for connstrings with spaces, but with the recent
> hacking by Peter I assume this is superfluous. It was handy for development
> so
> I’ve kept it
Il 23/01/18 18:13, Petr Jelinek ha scritto:
> Hi,
>
> On 23/01/18 15:38, Marco Nenciarini wrote:
>> Il 22/01/18 23:18, Petr Jelinek ha scritto:
>>> On 22/01/18 19:45, Petr Jelinek wrote:
>>>
>>> Actually on second look, I don't like the new boolean parameter much.
>>> I'd rather we didn't touch th
On 23/01/18 18:19, Marco Nenciarini wrote:
> Il 23/01/18 18:13, Petr Jelinek ha scritto:
>> Hi,
>>
>> On 23/01/18 15:38, Marco Nenciarini wrote:
>>> Il 22/01/18 23:18, Petr Jelinek ha scritto:
On 22/01/18 19:45, Petr Jelinek wrote:
Actually on second look, I don't like the new boolea
On 1/10/18 07:36, Fabien COELHO wrote:
> I just noticed while rebasing stuff that there is some crust in
> "pgbench/t/001_pgbench_with_server.pl" coming from this patch:
>
> +=head
> +
> +} });
> +
> +=cut
>
> I cannot find any use for these lines which are ignored by perl execution
>
Hi,
On 23/01/18 18:47, Marco Nenciarini wrote:
> Il 23/01/18 18:25, Petr Jelinek ha scritto:
>> On 23/01/18 18:19, Marco Nenciarini wrote:
>>> Il 23/01/18 18:13, Petr Jelinek ha scritto:
Hi,
On 23/01/18 15:38, Marco Nenciarini wrote:
> Il 22/01/18 23:18, Petr Jelinek ha scritto:
On Mon, Jan 22, 2018 at 7:23 AM, Justin Pryzby wrote:
> Consider this shorter, less-severe sounding alternative:
> "... (but note that this feature can degrade performance of some
> PostgreSQL workloads)."
I think the patch looks good now.
As Justin mentions, as far as I see the only arguable pi
Hi all,
When I was trying to do read-write pgbench bench-marking of PostgreSQL
9.6.6 vs 10.1 I found PostgreSQL 10.1 regresses against 9.6.6 in some
cases.
Non Default settings and test
==
Server:
./postgres -c shared_buffers=8GB -N 200 -c min_wal_size=15GB -c
max_wal_size=20G
On Mon, Jan 22, 2018 at 10:13 PM, Peter Geoghegan wrote:
> _bt_leader_heapscan() can detect when workers exit early, at least in
> the vast majority of cases. It can do this simply by processing
> interrupts and automatically propagating any error -- nothing special
> about that. It can also detec
On Tue, Jan 23, 2018 at 12:03 PM, Peter Eisentraut
wrote:
> It might also be useful to set these reloptions before you add a new
> column to a table.
I don't understand. AAUI, it is currently the case that if you set
the options before the TOAST table exists, they are lost.
--
Robert Haas
Ente
Masahiko Sawada wrote:
> Hi,
>
> Attached a patch for $subject. The implementation of autovacuum
> work-item has been changed by commit
> 31ae1638ce35c23979f9bcbb92c6bb51744dbccb but the loading of dsa.h
> header file is remained.
You're right -- pushed.
--
Álvaro Herrerahttps:/
On Fri, Jan 19, 2018 at 9:42 AM, Robert Haas wrote:
> That's not necessarily an argument against this patch, which by the
> way I have not reviewed. Even a 5% speedup on this kind of workload
> is potentially worthwhile; everyone likes it when things go faster.
> I'm just not convinced you can ge
В письме от 23 января 2018 12:03:50 пользователь Peter Eisentraut написал:
> >>> This patch raises error if user tries o set or change toast.* option for
> >>> a table that does not have a TOST relation.
> >
> > There might be a case for raising a warning in this situation,
> > but I would disagr
On Tue, Jan 23, 2018 at 10:36 AM, Robert Haas wrote:
> As Amit says, what remains is the case where fork() fails or the
> worker dies before it reaches the line in ParallelWorkerMain that
> reads shm_mq_set_sender(mq, MyProc). In those cases, no error will be
> signaled until you call WaitForPara
Hello Stephen
I changed the suggested things and added some regression tests. Also i wrote
few words to the documentation. New patch is attached.
Thank you for feedback!
regards, Sergeidiff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index 286c7a8..cf2c56f 10064
On Tue, Jan 23, 2018 at 10:50 AM, Peter Geoghegan wrote:
> On Tue, Jan 23, 2018 at 10:36 AM, Robert Haas wrote:
>> I am going to repeat my previous suggest that we use a Barrier here.
>> Given the discussion subsequent to my original proposal, this can be a
>> lot simpler than what I suggested or
On 23/01/18 16:01, Nikhil Sontakke wrote:
>> I must be missing something in this discussion, cos I don't see any
>> problems with this "other option".
>>
>> Surely we prepare the 2PCxact and then it is persistent. Yes,
>> potentially for an unbounded period of time. And it is (usually) up to
>> the
On Mon, Jan 22, 2018 at 6:53 PM, Tom Lane wrote:
> Here's a possibly more useful graph of regression test timings over
> the last year. I pulled this from the buildfarm database: it is the
> reported runtime for the "installcheck-C" step in each successful
> build of HEAD on dromedary, going back
Il 23/01/18 18:25, Petr Jelinek ha scritto:
> On 23/01/18 18:19, Marco Nenciarini wrote:
>> Il 23/01/18 18:13, Petr Jelinek ha scritto:
>>> Hi,
>>>
>>> On 23/01/18 15:38, Marco Nenciarini wrote:
Il 22/01/18 23:18, Petr Jelinek ha scritto:
> On 22/01/18 19:45, Petr Jelinek wrote:
>
When a primary with replication slots gets reset with pg_rewind,
it keeps the replication slots.
This does no harm per se, but when it gets promoted again,
the replication slots are still there and are in the way.
Won't they also hold back the xmin horizon?
I think that pg_rewind should delete al
> On 23 Jan 2018, at 18:20, Peter Eisentraut
> wrote:
>
> On 1/21/18 18:08, Daniel Gustafsson wrote:
>> As per before, my patch for running tests against another set of binaries is
>> included as well as a fix for connstrings with spaces, but with the recent
>> hacking by Peter I assume this is
This stuff sounds pretty nice. However, have a look at this report:
https://codecov.io/gh/postgresql-cfbot/postgresql/commit/2aa632dae3066900e15d2d42a4aad811dec11f08
it seems to me that the new code is not tested at all. Shouldn't you
add a few more tests?
I think 0004 should apply to unpatche
On 1/23/18 14:59, Daniel Gustafsson wrote:
> It’s not specific to the implementation per se, but it increases the
> likelyhood
> of hitting it. In order to load certificates from Keychains the cert common
> name must be specified in the connstr, when importing the testfiles into
> keychains I ran
On Tue, Jan 23, 2018 at 11:15 AM, Robert Haas wrote:
> On Mon, Jan 22, 2018 at 10:56 PM, Amit Kapila wrote:
>> It does turn such cases into error but only at the end when someone
>> calls WaitForParallelWorkersToFinish. If one tries to rely on it at
>> any other time, it won't work as I think is
On Tue, Jan 23, 2018 at 2:11 PM, Peter Geoghegan wrote:
> Finally, it's still not clear to me why nodeGather.c's use of
> parallel_leader_participation=off doesn't suffer from similar problems
> [1].
Thomas and I just concluded that it does. See my email on the other
thread just now.
I thought
On 01/23/2018 09:05 PM, Alvaro Herrera wrote:
> This stuff sounds pretty nice. However, have a look at this report:
>
> https://codecov.io/gh/postgresql-cfbot/postgresql/commit/2aa632dae3066900e15d2d42a4aad811dec11f08
>
> it seems to me that the new code is not tested at all. Shouldn't you
>
Did this go anywhere?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello
I tested this patch and think it can be commited to master. Is there a CF
record? I can not find one.
Should we also make backport to older versions? I test on REL_10_STABLE - patch
builds and works ok, but "make check" fails on new testcase with error:
> CREATE INDEX ON t USING gist (a t
> On 23 Jan 2018, at 22:04, Peter Eisentraut
> wrote:
>
> On 1/23/18 14:59, Daniel Gustafsson wrote:
>> It’s not specific to the implementation per se, but it increases the
>> likelyhood
>> of hitting it. In order to load certificates from Keychains the cert common
>> name must be specified in
While reviewing the patch for tab completion after SELECT, I realized
that psql doesn't know how to complete after FROM if the ONLY keyword is
present.
This trivial patch fixes that, as well as JOIN ONLY and TABLE ONLY.
--
Vik Fearing +33 6 46 75 15 36
htt
Hi All,
Recently I put a proposal to support 'prefer-read' parameter in
target_session_attrs in libpq. Now I updated the patch with adding content
in the sgml and regression test case.
Some people may have noticed there is already another patch (
https://commitfest.postgresql.org/15/1148/ ) which
On Fri, Jan 19, 2018 at 6:22 AM, Robert Haas wrote:
>> (3)
>> erm, maybe it's a problem that errors occurring in workers while the
>> leader is waiting at a barrier won't unblock the leader (we don't
>> detach from barriers on abort/exit) -- I'll look into this.
>
> I think if there's an ERROR, th
Peter Eisentraut wrote:
> On 12/29/17 17:53, Alvaro Herrera wrote:
> > This patch enables FOR EACH ROW triggers on partitioned tables.
> >
> > As presented, this patch is sufficient to discuss the semantics that we
> > want for triggers on partitioned tables, which is the most pressing
> > questio
On Tue, Jan 23, 2018 at 1:05 PM, Robert Haas wrote:
> I was just talking to Thomas, and one or the other of us realized that
> this doesn't completely fix the problem. I think that if a worker
> fails, even by some unorthodox mechanism like an abrupt proc_exit(1),
> after the point where it attac
Hey all!
This doesn't come up that often but enough that it seems hammering home
that multi-dimension <> array-of-array seems warranted.
The first and last chuck cover definition and iteration respectively. The
second chuck removes the mention of "subarray" since that's what we don't
want people
On Fri, Jan 19, 2018 at 12:14 AM, Thomas Munro
wrote:
> On Sat, Jan 13, 2018 at 2:16 PM, Tom Lane wrote:
>> What we could/should do instead, I think, is have pgss_planner_hook
>> make its own pgss_store() call to log the planning time results
>> (which would mean we don't need the added PlannedSt
Robert Haas writes:
> On Mon, Jan 22, 2018 at 6:53 PM, Tom Lane wrote:
>> Here's a possibly more useful graph of regression test timings over
>> the last year. I pulled this from the buildfarm database: it is the
>> reported runtime for the "installcheck-C" step in each successful
>> build of HE
Thomas Munro writes:
> One problem is that pgss_planner_hook doesn't have the source query
> text. That problem could be solved by adding a query_string argument
> to the planner hook function type and also planner(),
> standard_planner(), pg_plan_query(), pg_plan_queries(). I don't know
> if th
Can someone confirm this so I can apply this patch?
---
On Fri, Nov 17, 2017 at 06:34:29PM +0900, Masahiko Sawada wrote:
> Hi,
>
> I found that the doc says in 19.6.4. Subscribers section that "Note
> that wal_receiver_time
On 23 January 2018 at 23:22, Amit Langote wrote:
> On 2018/01/23 15:44, David Rowley wrote:
>> Attached is what I had in mind about how to do this.
>
> Thanks for the delta patch. I will start looking at it tomorrow.
Thanks. I've been looking more at this and I've made a few more
adjustments in
Hello.
Just very small fix for C4141 warning (
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4141
).
Also could be viewed on Github -
https://github.com/michail-nikolaev/postgres/commit/38a590a00110a4ea870d625470e4c898e5ad79aa
Tested both MSVC an
On Wed, Jan 24, 2018 at 1:16 PM, Michail Nikolaev
wrote:
> Just very small fix for C4141 warning
> (https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4141).
>
> Also could be viewed on Github -
> https://github.com/michail-nikolaev/postgres/commit/38a5
On Tue, Jan 23, 2018 at 06:36:04PM -0500, Bruce Momjian wrote:
>
> Can someone confirm this so I can apply this patch?
Never mind. I see this was applied:
doc: mention wal_receiver_status_interval as GUC affecting logical rep
worker.
wal_receiver_timeout, wal_receiver_
Thomas Munro writes:
> On Wed, Jan 24, 2018 at 1:16 PM, Michail Nikolaev
> wrote:
>> Just very small fix for C4141 warning
> Thanks. This is similar to the fix I proposed over here:
> https://www.postgresql.org/message-id/CAEepm%3D2iTKvbebiK3CdoczQk4_FfDt1EeU4c%2BnGE340JH7gQ0g%40mail.gmail.com
On Thu, Nov 23, 2017 at 03:39:24PM -0500, Tom Lane wrote:
> Also, we're way overdue for getting out from under the creaky TeX-based
> toolchain for producing PDFs. Every time we make releases, I worry
> whether we're going to get blindsided by its bugs with hotlinks that get
> split across pages,
From: Robert Haas [mailto:robertmh...@gmail.com]
> Oh, incidentally -- in our internal testing, we found that
> wal_sync_method=open_datasync was significantly faster than
> wal_sync_method=fdatasync. You might find that open_datasync isn't much
> different from pmem_drain, even though they're bot
On 01/23/2018 04:59 PM, Bruce Momjian wrote:
On Thu, Nov 23, 2017 at 03:39:24PM -0500, Tom Lane wrote:
Also, we're way overdue for getting out from under the creaky TeX-based
toolchain for producing PDFs. Every time we make releases, I worry
whether we're going to get blindsided by its bugs wit
On Tue, Jan 23, 2018 at 05:25:30PM -0800, Joshua Drake wrote:
> On 01/23/2018 04:59 PM, Bruce Momjian wrote:
> >On Thu, Nov 23, 2017 at 03:39:24PM -0500, Tom Lane wrote:
> >>Also, we're way overdue for getting out from under the creaky TeX-based
> >>toolchain for producing PDFs. Every time we make
On Tue, Jan 23, 2018 at 5:51 AM, Simon Riggs wrote:
>> Not yet working
>> * Partitioning
>> * RLS
>>
>> Based on this successful progress I imagine I'll be looking to commit
>> this by the end of the CF, allowing us 2 further months to bugfix.
>
> This is complete and pretty clean now. 1200 lines
On Tue, Jan 23, 2018 at 04:22:22PM +0100, Daniel Gustafsson wrote:
> On 23 Jan 2018, at 05:52, Michael Paquier wrote:
>> 2) indexam.sgml mentions using pg_strcasecmp() for consistency with the
>> core code when defining amproperty for an index AM. Well, with this
>> patch I think that for consiste
1 - 100 of 147 matches
Mail list logo
