>> Thanks for finding these accidental duplications, and to Ishii-san for
>> committing the fix. Oops.
>>
>> +1 for this refactoring.
>
> Thanks for confirming. I will go ahead commit/push the patch.
Done.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English:
On Sat, Jun 16, 2018 at 10:47 AM, Konstantin Knizhnik
wrote:
>
>
> On 16.06.2018 06:33, Amit Kapila wrote:
>>
>> On Fri, Jun 15, 2018 at 11:31 PM, Andres Freund
>> wrote:
>>>
>>> On 2018-06-14 10:13:44 +0300, Konstantin Knizhnik wrote:
On 14.06.2018 09:52, Thomas Munro wrote:
On 16.06.2018 06:33, Amit Kapila wrote:
On Fri, Jun 15, 2018 at 11:31 PM, Andres Freund wrote:
On 2018-06-14 10:13:44 +0300, Konstantin Knizhnik wrote:
On 14.06.2018 09:52, Thomas Munro wrote:
On Thu, Jun 14, 2018 at 1:09 AM, Konstantin Knizhnik
wrote:
pg_wal_prefetch function will
On Thu, Jun 14, 2018 at 10:05 PM, Tom Lane wrote:
> I wrote:
>> This appears to be the fault of commit ab7271677, whose authors I've cc'd:
>> the stanza starting at about allpaths.c:1672 is bullheadedly creating a
>> parallel path whether that's allowed or not. Fixing it might be as simple
>> as
On Thu, Jun 14, 2018 at 9:54 PM, Tom Lane wrote:
> Rajkumar Raghuwanshi writes:
>> I am getting a server crash for below test case.
>
>> postgres=# CREATE TABLE test( c1 int, c2 int, c3 text) partition by
>> range(c1);
>> CREATE TABLE
>> postgres=# create table test_p1 partition of test for
On 16.06.2018 06:30, Amit Kapila wrote:
On Fri, Jun 15, 2018 at 8:45 PM, Konstantin Knizhnik
wrote:
On 15.06.2018 18:03, Amit Kapila wrote:
wal_prefetch is prefetching blocks referenced by WAL records. But in case of
"full page writes" such prefetch is not needed and even is harmful.
On Fri, Jun 15, 2018 at 4:23 PM, Alvaro Herrera
wrote:
> I've been looking at re-implementing this feature recently, using
> Tsunakawa's proposed UI of a GUC transaction_rollback_scope that can
> take values "transaction" (default, current behavior) and "statement".
> I didn't take other parts of
On Thu, Jun 14, 2018 at 9:45 AM, Ashutosh Bapat
wrote:
>> It sounds like you want to try to hide from users the fact that they
>> can create triggers on the individual partitions.
>
> No. I never said that in my mails (see [1], [2]) I object to the
> explicit suggestion that they can/should
On Fri, Jun 15, 2018 at 11:31 PM, Andres Freund wrote:
> On 2018-06-14 10:13:44 +0300, Konstantin Knizhnik wrote:
>>
>>
>> On 14.06.2018 09:52, Thomas Munro wrote:
>> > On Thu, Jun 14, 2018 at 1:09 AM, Konstantin Knizhnik
>> > wrote:
>> > > pg_wal_prefetch function will infinitely traverse WAL
On Fri, Jun 15, 2018 at 8:45 PM, Konstantin Knizhnik
wrote:
>
> On 15.06.2018 18:03, Amit Kapila wrote:
>
> wal_prefetch is prefetching blocks referenced by WAL records. But in case of
> "full page writes" such prefetch is not needed and even is harmful.
>
Okay, IIUC, the basic idea is to
From: Alvaro Herrera
> I've been looking at re-implementing this feature recently, using
> Tsunakawa's proposed UI of a GUC transaction_rollback_scope that can
> take values "transaction" (default, current behavior) and
"statement".
> I didn't take other parts of his patch though; see below.
On Fri, Jun 15, 2018 at 2:36 PM, Robert Haas wrote:
> Yes, retail index deletion is essential for the delete-marking
> approach that is proposed for zheap.
Makes sense.
I don't know that much about zheap. I'm sure that retail index tuple
deletion is really important in general, though. The Gray
Hi,
After pg_upgrade, the data in Postgres is corrupted.
1. Postgres 9.4, stop db with "immediate" mode
2. Run pg_upgrade, to upgrade to Postgres 10.4
3. Start Postgres 10 and run vacuum full, got a bunch of "concurrent insert
in progress". Looks like the data is corrupted. (Loading the old data
On Thu, Jun 14, 2018 at 2:44 PM, Peter Geoghegan wrote:
> I've been thinking about using heap TID as a tie-breaker when
> comparing B-Tree index tuples for a while now [1]. I'd like to make
> all tuples at the leaf level unique, as assumed by L This can
> enable "retail index tuple deletion",
On Thu, Jun 14, 2018 at 7:43 AM, Magnus Hagander wrote:
> I still think that the fact that we are still discussing what is basically
> the *basic concepts* of how this would be set up after we have released
> beta1 is a clear sign that this should not go into 11.
+1.
--
Robert Haas
On 2017-Nov-06, Tsunakawa, Takayuki wrote:
> From: Simon Riggs
> > A backend-based solution is required for PL procedures and functions.
> >
> > We could put this as an option into PL/pgSQL, but it seems like it is
> > a function of the transaction manager rather than the driver.
>
> Exactly.
> On Jun 13, 2018, at 12:53 PM, Jeff Davis wrote:
>
>>
>> An adaptive hash agg node would start as a hash agg, and turn into a
>> "partial hash agg + sort + final group agg" when OOM is detected.
>>
>> The benefit over ordinary sort+group agg is that the sort is
>> happening
>> on a
On 06/15/2018 02:40 PM, John Naylor wrote:
> On 2/19/18, Joe Conway wrote:
>> The attached does exactly this. Gives all system tables toast tables
>> except pg_class, pg_attribute, and pg_index, and includes cat version
>> bump and regression test in misc_sanity.
>>
>> Any further discussion,
By the way, why do we need to strlen() the target buffer when strlcpy
already reports the length? (You could argue that there is a difference
if the string is truncated ... but surely we don't care about that case)
I propose the attached.
--
Álvaro Herrera
On 2018-Jun-14, Nikhil Sontakke wrote:
> There was a slight oversight in the twophase_gid length calculation in
> the XactLogCommitRecord() code path in the cf5a1890592 commit. The
> corresponding XactLogAbortRecord() code path was ok. PFA, a small
> patch to fix the oversight.
Forgot to add:
On 2018-Jun-14, Nikhil Sontakke wrote:
> There was a slight oversight in the twophase_gid length calculation in
> the XactLogCommitRecord() code path in the cf5a1890592 commit. The
> corresponding XactLogAbortRecord() code path was ok. PFA, a small
> patch to fix the oversight.
Thanks, pushed.
I noticed that ParseFuncOrColumn isn't terribly thorough about rejecting
non-procedure results when proc_call is true. Since the caller is just
assuming that it gets back what it expects, that leads to core dumps
or worse:
regression=# call int4(42);
server closed the connection unexpectedly
> "Tom" == Tom Lane writes:
Tom> For example, suppose f(...) returns a single-column tuple result.
Tom> This should be legal, if x matches the type of the single column:
Tom> update ... set (x) = f(...)
Tom> but if we try to do what you seem to have in mind, this would not
Tom> be:
On 2/19/18, Joe Conway wrote:
> The attached does exactly this. Gives all system tables toast tables
> except pg_class, pg_attribute, and pg_index, and includes cat version
> bump and regression test in misc_sanity.
>
> Any further discussion, comments, complaints?
Hi Joe,
There's been a little
On 15 June 2018 at 09:46, Peter Eisentraut
wrote:
> On 6/5/18 07:02, Amit Khandekar wrote:
>> I haven't written a patch for it, but I think we should have a
>> separate on_commit_stop_workers for eachyou get subtransaction. At
>> subtransaction commit, we replace the on_commit_stop_workers list
Hi,
On 2018-06-15 10:45:04 -0700, Andres Freund wrote:
> > +
> > + srels = palloc(sizeof(SMgrRelation) * ndelrels);
> > for (i = 0; i < ndelrels; i++)
> > - {
> > - SMgrRelation srel = smgropen(delrels[i], InvalidBackendId);
> > + srels[i] = smgropen(delrels[i],
I propose removing the "Included attributes in B-tree indexes"
top-level section of chapter 63 from the user facing documentation.
Chapter 63 concerns B-Tree operator classes themselves, in the
abstract, so the fact that an operator class isn't needed for extra
covering index columns isn't
On 2018-06-14 10:13:44 +0300, Konstantin Knizhnik wrote:
>
>
> On 14.06.2018 09:52, Thomas Munro wrote:
> > On Thu, Jun 14, 2018 at 1:09 AM, Konstantin Knizhnik
> > wrote:
> > > pg_wal_prefetch function will infinitely traverse WAL and prefetch block
> > > references in WAL records
> > > using
We just had a customer hit this issue. I kind of wonder whether this
shouldn't be backpatched: Currently the execution on the primary is
O(NBuffers * log(ndrels)) whereas it's O(NBuffers * ndrels) on the
standby - with a lot higher constants to boot. That means it's very
easy to get into
Hi,
We just had a customer hit this issue. I kind of wonder whether this
shouldn't be backpatched: Currently the execution on the primary is
O(NBuffers * log(ndrels)) whereas it's O(NBuffers * ndrels) on the
standby - with a lot higher constants to boot. That means it's very
easy to get into
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> As far as (a) goes, it was an intentional compatibility breakage,
> So here I have a problem: the fact that it was a compatibility breakage
> seems not to have been discussed *or even so much as mentioned* on
> -hackers at any time.
I
On 14 June 2018 07:28:53 CEST, Atul Kumar wrote:
>Hi,
>
>I have postgres edb 9.6 version, i have below query to solve it out.
>
>i have configured streaming replication having master and slave node
>on same server just to test it.
>
>All worked fine but when i made slave service stop, and create
Alvaro Herrera writes:
> Can somebody (Arseny, Konstantin, horiguti, Sawada) please confirm that
> Michaël's commit fixes the reported bug?
I confirm that starting reading WAL since restart_lsn as implemented in
f731cfa fixes this issue, as well as the second issue tushar mentioned
at [1]. I
On 15.06.2018 18:03, Amit Kapila wrote:
On Fri, Jun 15, 2018 at 1:08 PM, Konstantin Knizhnik
wrote:
On 15.06.2018 07:36, Amit Kapila wrote:
On Fri, Jun 15, 2018 at 12:16 AM, Stephen Frost
wrote:
I have tested wal_prefetch at two powerful servers with 24 cores, 3Tb
NVME
RAID 10 storage
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
- appendStringInfo(buf, "off %u", xlrec->offnum);
+
On Thu, Jun 14, 2018 at 10:58 AM, Atul Kumar wrote:
> Hi,
>
> I have postgres edb 9.6 version, i have below query to solve it out.
>
This is not the right place to ask queries on edb versions. You need
to check with your vendor about the right place to ask questions.
Here, you can ask the
On 06/15/2018 10:02 AM, Tom Lane wrote:
Andrew Dunstan writes:
OK, lousyjack is back online with this, new and improved. It currently
takes 7.5 hours for a run. Should I also add -DCATCACHE_FORCE_RELEASE?
I did some experimentation yesterday with valgrind plus both
RELCACHE_FORCE_RELEASE
Andrew Dunstan writes:
> OK, lousyjack is back online with this, new and improved. It currently
> takes 7.5 hours for a run. Should I also add -DCATCACHE_FORCE_RELEASE?
I did some experimentation yesterday with valgrind plus both
RELCACHE_FORCE_RELEASE and CATCACHE_FORCE_RELEASE. I didn't
On 06/12/2018 07:47 AM, Andrew Dunstan wrote:
On 06/11/2018 06:41 PM, Andrew Dunstan wrote:
On 06/11/2018 06:24 PM, Tom Lane wrote:
If we had any buildfarm critters running valgrind on
RELCACHE_FORCE_RELEASE or CLOBBER_CACHE_ALWAYS builds, they'd have
detected use of uninitialized
While hacking around the planner, the "callback" mechanism in
query_planner started to feel awkward. It would seem more natural to
split query_planner() into two parts: one function to do all the
pre-processing of the jointree, building equivalence classes etc. And a
second function to
(2018/06/14 22:37), Ashutosh Bapat wrote:
On Mon, Jun 11, 2018 at 4:05 PM, Etsuro Fujita
wrote:
(2018/06/07 19:42), Ashutosh Bapat wrote:
On Wed, Jun 6, 2018 at 5:00 PM, Etsuro Fujita
wrote:
Yeah, but I mean we modify set_append_rel_size so that we only map a parent
wholerow Var in the
Hi!
On Fri, Jun 15, 2018 at 2:11 PM Nikita Glukhov wrote:
>
> On 28.03.2018 15:43, Peter Eisentraut wrote:
>
> > On 3/21/18 18:50, Peter Eisentraut wrote:
> >> On 3/12/18 11:26, Nikita Glukhov wrote:
> >>> I have reviewed this patch. Attached new 6th version of the patch with
> >>> v5-v6
On 15 June 2018 at 20:37, Amit Langote wrote:
> select * from partitioned_table_a
> union all
> select * from partitioned_table_b
>
> The only thing that changes with the patch is that
> ExecLockNonLeafAppendTables is called *twice* for the two nested Appends
> corresponding to
On 28.03.2018 15:43, Peter Eisentraut wrote:
On 3/21/18 18:50, Peter Eisentraut wrote:
On 3/12/18 11:26, Nikita Glukhov wrote:
I have reviewed this patch. Attached new 6th version of the patch with
v5-v6 delta-patch.
Thanks for the update. I'm working on committing this.
Committed.
On 06/15/2018 12:21 AM, Peter Eisentraut wrote:
On 6/11/18 16:06, Andrew Dunstan wrote:
This affects pretty much nothing. In fact some of the other changes I've
recently committed were arguably more dangerous. Do you want me to
revert the whole lot?
No, but this whole let's clean up the
On 2018/06/14 20:23, David Rowley wrote:
> On 14 June 2018 at 19:17, Amit Langote wrote:
>> I had sent a patch to try to get rid of the open(NoLock) there a couple of
>> months ago [1]. The idea was to both lock and open the relation in
>> ExecNonLeafAppendTables, which is the first time all
On Fri, Jun 15, 2018 at 5:06 AM, Alvaro Herrera
wrote:
> Hello
>
> Can somebody (Arseny, Konstantin, horiguti, Sawada) please confirm that
> Michaël's commit fixes the reported bug?
>
I don't confirm that commit deeply yet but I have confirmed that the
reported bug is fixed using the following
Hi Thomas,
> On Fri, Jun 15, 2018 at 8:42 PM, Antonin Houska wrote:
>> Tatsuo Ishii wrote:
>>
>>> The changes were made by this commit to add infrastructure for sharing
>>> temporary files between backends, according to the author (Thomas
>>> Munro).
>>>
>>>
On Fri, Jun 15, 2018 at 8:42 PM, Antonin Houska wrote:
> Tatsuo Ishii wrote:
>
>> The changes were made by this commit to add infrastructure for sharing
>> temporary files between backends, according to the author (Thomas
>> Munro).
>>
>>
Tatsuo Ishii wrote:
> The changes were made by this commit to add infrastructure for sharing
> temporary files between backends, according to the author (Thomas
> Munro).
>
> https://git.postgresql.org/pg/commitdiff/dc6c4c9dc2a111519b76b22dc86c5608223b
>
> Your proposal looks reasonable
On 2018/06/14 23:40, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 14, 2018 at 7:23 AM, David Rowley
>> wrote:
>>> However, I only spent about 10 mins looking into this, there may be
>>> some giant holes in the idea. It would need much more research.
>
>> It kind of flies in the face of
On Fri, Jun 15, 2018 at 2:20 AM, Alvaro Herrera
wrote:
> On 2018-Jun-14, Michael Paquier wrote:
>
>> On Thu, Jun 14, 2018 at 02:06:57AM +0900, Masahiko Sawada wrote:
>> > On Thu, Jun 14, 2018 at 12:04 AM, Simon Riggs
>> > wrote:
>> >> On 13 June 2018 at 15:51, Alvaro Herrera wrote:
>> >>> I
On 2018/06/11 16:49, David Rowley wrote:
> On 11 June 2018 at 12:19, Tom Lane wrote:
>> David Rowley writes:
>>> On 10 June 2018 at 04:48, Tom Lane wrote:
So, IIUC, the issue is that for partitioning cases Append expects *all*
its children to be partitions of the *same* partitioned
Hello Charles,
> The repo currently can be build on my mac. You can check it out.
> Also I am working on the CI config to monitor each commit.
Tests pass on Arch Linux with PostgreSQL 11 and Ubuntu 16.04 with
PostgreSQL 9.6. However there is a name conflict in case of PostgreSQL
11:
> Now I see that BufFileCreateShared() has similar problem with file->name.
Right.
> More generic problem I see is that the common initialization of BufFile is
> repeated a few times. The attached patch tries to improve that (it also fixes
> the duplicate allocation of file->name).
The changes
Now I see that BufFileCreateShared() has similar problem with file->name.
More generic problem I see is that the common initialization of BufFile is
repeated a few times. The attached patch tries to improve that (it also fixes
the duplicate allocation of file->name).
Tatsuo Ishii wrote:
> >
Hi Robert,
Sounds very similar to commit 3de241dba86f3dd000434f70aebba725fb928032.
I'm reusing part of the code from this commit (mainly
"CloneForeignKeyConstraints")..
But this commit concerns only partitioned tables.. not inherited tables.
Kind regards,
--
Raphael Medaer
Product
On 2018/06/15 16:32, Rajkumar Raghuwanshi wrote:
> Hi,
>
> I am getting "ERROR: did not find all requested child rels in
> append_rel_list" when enable_partition_pruning is on for below test case.
>
> CREATE TABLE test(c1 int, c2 int) PARTITION BY RANGE(c1);
> CREATE TABLE test_p1 PARTITION OF
Hi,
I am getting "ERROR: did not find all requested child rels in
append_rel_list" when enable_partition_pruning is on for below test case.
CREATE TABLE test(c1 int, c2 int) PARTITION BY RANGE(c1);
CREATE TABLE test_p1 PARTITION OF test FOR VALUES FROM (minvalue) TO (0);
CREATE TABLE test_p2
> Memory is allocated twice for "file" and "files" variables. Possible fix:
>
> diff --git a/src/backend/storage/file/buffile.c
> b/src/backend/storage/file/buffile.c
> index d8a18dd3dc..00f61748b3 100644
> --- a/src/backend/storage/file/buffile.c
> +++ b/src/backend/storage/file/buffile.c
> @@
Memory is allocated twice for "file" and "files" variables. Possible fix:
diff --git a/src/backend/storage/file/buffile.c
b/src/backend/storage/file/buffile.c
index d8a18dd3dc..00f61748b3 100644
--- a/src/backend/storage/file/buffile.c
+++ b/src/backend/storage/file/buffile.c
@@ -277,10 +277,10
On 2018/06/14 22:45, Ashutosh Bapat wrote:
> On Thu, Jun 14, 2018 at 6:49 PM, Robert Haas wrote:
>> It sounds like you want to try to hide from users the fact that they
>> can create triggers on the individual partitions.
>
> No. I never said that in my mails (see [1], [2]) I object to the
>
Many thanks to Marko and David for your reply. It really helped.
Now I am playing with extension auth_delay, which uses
ClientAuthentication_hook. But I find it not easy to distinguish the first
connection of psql from the second one with empty password, since the
variable 'status' are both
63 matches
Mail list logo
