>From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
>The detailed comments for the source code will be provided later.
Hi,
I'm adding some comments to 0001 and 0002 one.
[0001 patch]
+ /*
Thank you for piking this and sorry being late.
At Mon, 19 Nov 2018 13:39:58 +0900, Michael Paquier wrote
in <20181119043958.ge4...@paquier.xyz>
> ereport should not be called within xlogreader.c as a base rule:
Ouch! I forgot that. Fixed to use report_invalid_record slightly
changing the
On 20/12/2018 18:53, David Rowley wrote
[...]
Patched:
postgres=# analyze t1;
Time: 680.833 ms
Time: 699.976 ms
Time: 695.608 ms
Time: 676.007 ms
Time: 693.487 ms
Time: 726.982 ms
Time: 677.835 ms
Time: 688.426 ms
Master:
postgres=# analyze t1;
Time: 721.837 ms
Time: 756.035 ms
Time: 734.545
On Thu, 20 Dec 2018 at 17:50, Tom Lane wrote:
> David Rowley writes:
> > However, I doubt it would take much more effort to maintain
> > using 32-bit sets on 32-bit machines. If someone feels strongly about
> > that then I can adjust the patch to allow that.
>
> Hm, are you thinking of making
On Tue, Dec 18, 2018 at 1:29 PM Masahiko Sawada wrote:
>
> Attached the updated patches. I scaled back the scope of this patch.
> The patch now includes only feature (a), that is it execute both index
> vacuum and cleanup index in parallel. It also doesn't include
> autovacuum support for now.
>
Back in 2016 [1] there was some discussion about using the POPCNT
instruction to improve the performance of counting the number of bits
set in a word. Improving this helps various cases, such as
bms_num_members and also things like counting the allvisible and
frozen pages in the visibility map.
On Thu, Dec 20, 2018 at 12:02:52AM +, Dagfinn Ilmari Mannsåker wrote:
> Point, fixed in the attached v4. OTOH, as I mentioned in my other
> email, that runs into the problem that it won't complete the actions
> after e.g. "CREATE TEMP TABLE FOO () WITH () ON COMMIT".
I am fine to do that
čt 20. 12. 2018 v 5:29 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > čt 20. 12. 2018 v 0:14 odesílatel Tom Lane napsal:
> >> After my last few commits, the only issue that's left here is the
> >> cast-to-varchar implied by casting to sql_identifier. Upthread
> >> I showed a possible
On Wed, Dec 19, 2018 at 11:08 PM David Rowley
wrote:
>
> On Thu, 20 Dec 2018 at 09:48, Julien Rouhaud wrote:
> > On Wed, Dec 19, 2018 at 3:01 PM David Rowley
> > wrote:
> > > If so, I'd question why the default partition
> > > is so special? Pruning of any of the other partitions could turn a
David Rowley writes:
> I've attached the trivial patch which implements 64-bit Bitmapsets.
> One caveat about this may be that it will likely slow performance for
> 32-bit machines. My current thinking about that is that such a
> platform is likely not that common a target for the latest
Hello,
Sorry for delay.
The detailed comments for the source code will be provided later.
>> I just thought that the pair of ageclass and nentries can be
>> represented as json or multi-dimensional array but in virtual they are
>> all same and can be converted each other using some functions.
As many of you will know, part of my planned work for PG12 is to
further improve the performance of querying partitioned tables. Amit
Langote is doing quite a bit of work on the planner side of things to
remove the per-partition overhead to reduce that to just for
partitions that survive partition
čt 20. 12. 2018 v 0:14 odesílatel Tom Lane napsal:
> I wrote:
> > Pavel Stehule writes:
> >> Slow query
> >> select * from information_schema.tables where table_name = 'pg_class';
>
> > Yeah. This has been complained of many times before.
>
> > The core of the problem, I think, is that we're
On 12/19/18, Andrew Gierth wrote:
> Is there any particular reason not to go further and use a perfect hash
> function for the lookup, rather than binary search?
When I was investigating faster algorithms, I ruled out gperf based on
discussions in the archives. The approach here has modest goals
On Wed, Dec 19, 2018 at 08:50:10PM +, Bossart, Nathan wrote:
> If an option is specified for a server version that is not supported,
> the option is silently ignored. For example, SKIP_LOCKED was only
> added to VACUUM and ANALYZE for v12. Alternatively, I think we could
> fail in
On 2018/12/20 10:38, Michael Paquier wrote:
On Thu, Dec 20, 2018 at 10:05:30AM +0900, Tatsuro Yamada wrote:
Alright, I'll create new patches including these:
- No completion after "ALTER TABLE/INDEX SET STATISTICS" instead of schema
names
- Complete "ALTER INDEX foo ALTER COLUMN SET"
On Wed, Dec 19, 2018 at 01:29:48PM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
>> I put the new function at the bottom of heapam.c but I think it probably
>> needs a better place.
>
> catalog/catalog.c contains some functions with roughly this kind of
> knowledge, so maybe there?
+1 for the
On Thu, Dec 20, 2018 at 10:05:30AM +0900, Tatsuro Yamada wrote:
> Alright, I'll create new patches including these:
>
> - No completion after "ALTER TABLE/INDEX SET STATISTICS" instead of schema
> names
> - Complete "ALTER INDEX foo ALTER COLUMN SET" with STATISTICS by
> using
On 2018/12/19 18:22, Michael Paquier wrote:
On Wed, Dec 19, 2018 at 04:26:27PM +0900, Tatsuro Yamada wrote:
Yep, I already did that for ALTER INDEX in
tab_completion_alter_index_set_statistics.patch like this:
+ /* ALTER INDEX ALTER COLUMN SET STATISTICS */
+ else if
Andrew Gierth writes:
> Is there any particular reason not to go further and use a perfect hash
> function for the lookup, rather than binary search?
Tooling? I seem to recall having looked at gperf and deciding that it
pretty much sucked, so it's not real clear to me what we would use.
Hi,
On 2018-12-20 00:54:39 +, Andrew Gierth wrote:
> > "John" == John Naylor writes:
>
> > On 12/18/18, Tom Lane wrote:
> >> I'd be kind of inclined to convert all uses of ScanKeyword to the
> >> new way, if only for consistency's sake. On the other hand, I'm not
> >> the one
Hi,
On 2018-12-19 19:39:33 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Dec 19, 2018 at 5:37 PM Andres Freund wrote:
> >> What's gained by the logic of emitting that warning in VACUUM after a
> >> crash? I don't really see any robustness advantages in it.
>
> > I don't know. I am
> "John" == John Naylor writes:
> On 12/18/18, Tom Lane wrote:
>> I'd be kind of inclined to convert all uses of ScanKeyword to the
>> new way, if only for consistency's sake. On the other hand, I'm not
>> the one volunteering to do the work.
John> That's reasonable, as long as the
On 12/18/18, Tom Lane wrote:
> I'd be kind of inclined to convert all uses of ScanKeyword to the new way,
> if only for consistency's sake. On the other hand, I'm not the one
> volunteering to do the work.
That's reasonable, as long as the design is nailed down first. Along
those lines,
On Wed, Dec 19, 2018 at 01:24:29PM -0700, mkondle wrote:
> “2018-12-19 07:24:25 UTC: : @: [25775]: [2-1] FATAL: could not receive data
> from WAL stream: server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.”
>
Michael Paquier writes:
> On Wed, Dec 19, 2018 at 11:22:29PM +, Dagfinn Ilmari Mannsåker wrote:
>> Michael Paquier writes:
>>> + /* Complete ON COMMIT actions for temp tables */
>>> + else if (TailMatches("ON", "COMMIT"))
>>> + COMPLETE_WITH("PRESERVE ROWS", "DELETE ROWS",
On Wed, Dec 19, 2018 at 11:22:29PM +, Dagfinn Ilmari Mannsåker wrote:
> Michael Paquier writes:
>> + /* Complete ON COMMIT actions for temp tables */
>> + else if (TailMatches("ON", "COMMIT"))
>> + COMPLETE_WITH("PRESERVE ROWS", "DELETE ROWS", "DROP");
>>
>> This causes ON COMMIT to
Hi,
On 2018-12-19 18:22:28 -0500, Greg Stark wrote:
> I think this is a bug:
>
> postgres=# alter table only x2 add if not exists i integer;
> ERROR: 42701: column "i" of relation "x2" already exists
>
> Note that it does not occur without the ONLY:
>
> postgres=# alter table x2 add if not
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> Michael Paquier writes:
>
>> On Fri, Nov 30, 2018 at 03:44:38PM +, Dagfinn Ilmari Mannsåker wrote:
>>> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
Please find attached a patch that adds the following tab completions for
On Wed, Dec 19, 2018 at 06:38:00PM +0200, David Steele wrote:
> I'll push this to the first post-PG12 CF when one appears. Can we just go
> ahead and create a 2019-07 CF now? I know we generally discuss this at
> PGCon, but we can always rename it, right?
The schedule gets decided at the
I think this is a bug:
postgres=# alter table only x2 add if not exists i integer;
ERROR: 42701: column "i" of relation "x2" already exists
Note that it does not occur without the ONLY:
postgres=# alter table x2 add if not exists i integer;
NOTICE: 42701: column "i" of relation "x2" already
I wrote:
> Pavel Stehule writes:
>> Slow query
>> select * from information_schema.tables where table_name = 'pg_class';
> Yeah. This has been complained of many times before.
> The core of the problem, I think, is that we're unable to convert the
> condition on table_name into an indexscan on
On Wed, Dec 19, 2018 at 5:37 PM Andres Freund wrote:
> What's gained by the logic of emitting that warning in VACUUM after a
> crash? I don't really see any robustness advantages in it. If the logic
> were that we'd never reuse empty pages because they can hide corruption
> that normally would
Greetings,
Just would like to follow up this issue and fix proposal. We really would like
to have this issue fixed in PG. Could someone give some suggestions to the fix
proposal? Or other ideas to fix this issue?
Looking forward for your feedbacks!
Best regards,
--
Chengchao Yu
Software
On Tue, Dec 18, 2018 at 2:04 AM Alexander Korotkov
wrote:
> On Mon, Dec 17, 2018 at 3:35 PM Alexander Korotkov
> wrote:
> > On Mon, Dec 17, 2018 at 3:40 AM Alexander Korotkov
> > wrote:
> > > On Mon, Dec 17, 2018 at 1:25 AM Andres Freund wrote:
> > > > On 2018-12-17 01:03:52 +0300, Alexander
Hi,
On 2018-12-19 17:28:17 -0500, Robert Haas wrote:
> On Wed, Dec 19, 2018 at 3:39 AM Andres Freund wrote:
> > Thinking about whether it's worth to allow to extend that function in an
> > extensible manner made me wonder: Is it actually a good idea to
> > initialize the page at that point,
We have master server on one Datacenter, and the Replicate is in another
Datacenter
Intermittently, on the replicate server, we see this as below.
“2018-12-19 07:24:25 UTC: : @: [25775]: [2-1] FATAL: could not receive data
from WAL stream: server closed the connection unexpectedly
This probably
On Wed, Dec 19, 2018 at 3:39 AM Andres Freund wrote:
> Thinking about whether it's worth to allow to extend that function in an
> extensible manner made me wonder: Is it actually a good idea to
> initialize the page at that point, including marking it dirty?
As far as I can recall, my
On Thu, 20 Dec 2018 at 05:44, Tom Lane wrote:
> I don't think this is quite bulletproof against overflow, especially
> in view of the rather careless mixing of int32 and uint32 variables
> that exists here. The easiest way to make it bulletproof is to add
> an explicit test, so I did that and
On Thu, 20 Dec 2018 at 09:48, Julien Rouhaud wrote:
> On Wed, Dec 19, 2018 at 3:01 PM David Rowley
> wrote:
> > If so, I'd question why the default partition
> > is so special? Pruning of any of the other partitions could turn a
> > naturally unordered LIST partitioned table into a naturally
On Wed, Dec 19, 2018 at 2:44 PM Alvaro Herrera wrote:
> Oh, I remember eyeing that suspiciously, but was too distracted on
> making the other thing work to realize it was actually wrong :-(
> I agree that it's wrong.
OK, cool. If you're going to push a fix for the other changes, do you
want to
Peter Geoghegan writes:
> The Unicode consortium calls our current behavior within comparisons
> "deterministic comparisons" -- it's something they're not so keen on:
> https://unicode.org/reports/tr10/#Deterministic_Comparison
> I suggest using their terminology for our current behavior.
Hm,
On Wed, Dec 19, 2018 at 6:36 AM Tom Lane wrote:
> I don't really find it "natural" for equality to consider obviously
> distinct values to be equal.
The Unicode consortium calls our current behavior within comparisons
"deterministic comparisons" -- it's something they're not so keen on:
On Wed, Dec 19, 2018 at 3:01 PM David Rowley
wrote:
>
> On Thu, 20 Dec 2018 at 01:58, Julien Rouhaud wrote:
>
> I'm objecting to processing for all partitions, but processing for
> just non-pruned partitions seems fine to me. If there are 10k
> partitions and we pruned none of them, then
Contrary to popular understanding, in classified environments it is common
to have data marked with a variety of combinations that make it difficult
to create roles and labels that match the various permutations. As a simple
example, a document could be classified as follows:
Releasable to US
On 2018-Dec-19, Robert Haas wrote:
> While working on the problem of lowering lock levels for ATTACH
> PARTITION and DETACH PARTITION, I discovered that DETACH PARTITION
> takes only AccessShareLock on the table being detached, which I think
> is not good.
Oh, I remember eyeing that
> On 19 Dec 2018, at 20:21, Robert Haas wrote:
> I vote for calling the current heap "heap" - i.e. what the patchset is
> currently doing. As others have already noted, that's a perfectly
> good word for storing stuff in no particular order, and it's also a
> term with a very long history.
On Tue, Dec 18, 2018 at 11:17 PM Andres Freund wrote:
> The current pluggable table storage patchset [1] introduces the ability
> to specify the access method of a table (CREATE TABLE ... USING
> "ident"). The patchset currently names the current storage method
> (i.e. heapam.c et al) "heap"
While working on the problem of lowering lock levels for ATTACH
PARTITION and DETACH PARTITION, I discovered that DETACH PARTITION
takes only AccessShareLock on the table being detached, which I think
is not good. It seems to me that at a minimum it needs to take a
self-exclusive lock, because
On Wed, Dec 19, 2018 at 08:32:28AM -0300, Alvaro Herrera wrote:
> Hi,
>
> On 2018-Dec-19, Andres Freund wrote:
>
> > Well, that depends on what "non-heap layouts" you're thinking of. I
> > think there'd be some further work needed to make efficient IOTs
> > possible, but the patchset gets us a
On Wed, Dec 19, 2018 at 5:38 PM David Steele wrote:
> On 12/12/18 4:44 AM, Andres Freund wrote:
> > On 2018-12-12 11:32:55 +0900, Michael Paquier wrote:
> >>
> >> +1 on all that. Per the trend of this thread, I see a bunch of
> >> committers and contributors commenting about *not* removing this
I wrote:
> We could eliminate those two problems if we made "name" have
> typcollation "C" rather than "default", so that its semantics
> wouldn't change without explicit collation specs. This feels
> like pretty much of a wart to me, but maybe it's worth doing
> in the name of avoiding
Call it "pile" and "hoard":
https://www.thesaurus.com/browse/heap
https://www.thesaurus.com/browse/pile
https://www.thesaurus.com/browse/hoard
ср, 19 дек. 2018 г. в 07:17, Andres Freund :
> Hi,
>
> The current pluggable table storage patchset [1] introduces the ability
> to specify the access
Alvaro Herrera writes:
> On 2017-Aug-02, Tom Lane wrote:
>> I think Peter's got the error and the detail backwards. It should be
>> more like
>> ERROR: "someview" cannot have constraints
>> DETAIL: "someview" is a view.
>> If we do it like that, we need one ERROR message per error reason,
>> and
st 19. 12. 2018 v 19:01 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > st 19. 12. 2018 v 17:59 odesílatel Tom Lane napsal:
> >> So either this is something we fixed since 9.5.5, or your summary
> >> of the problem is missing many critical details.
>
> > I got different error message
On 2017-Aug-02, Tom Lane wrote:
> I think Peter's got the error and the detail backwards. It should be
> more like
>
> ERROR: "someview" cannot have constraints
> DETAIL: "someview" is a view.
>
> If we do it like that, we need one ERROR message per error reason,
> and one DETAIL per relkind,
This is a good news, also for code portability
Il giorno mer 19 dic 2018, 15:17 Chapman Flack ha
scritto:
> On 12/19/18 07:42, Massimo Fidanza wrote:
> > Do you know about GraalVM (https://www.graalvm.org/)? This is a new
> > polyglot VM that can run in context of Oracle and MySql, I think that
Pavel Stehule writes:
> st 19. 12. 2018 v 17:59 odesílatel Tom Lane napsal:
>> So either this is something we fixed since 9.5.5, or your summary
>> of the problem is missing many critical details.
> I got different error message "could not open critical system index". I
> checked files, and
st 19. 12. 2018 v 17:59 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > some customer has PostgreSQL 9.5.5. He cannot to login to database due
> > broken index
> > When I use single mode against to this database I got a error
> > start transaction
> > could not open critical system
Peter Eisentraut writes:
> In readfuncs.c, we have READ_ATTRNUMBER_ARRAY, READ_OID_ARRAY,
> READ_INT_ARRAY, READ_BOOL_ARRAY, but the writing side in outfuncs.c is
> coded by hand in each case. Any reason for this?
> Here is a patch that adds WRITE_ATTRNUMBER_ARRAY, WRITE_OID_ARRAY,
>
st 19. 12. 2018 v 18:07 odesílatel Alvaro Herrera
napsal:
> On 2018-Dec-19, Tom Lane wrote:
>
> > Pavel Stehule writes:
> > > some customer has PostgreSQL 9.5.5. He cannot to login to database due
> > > broken index
> > > When I use single mode against to this database I got a error
> > > start
On 2018-Dec-19, Tom Lane wrote:
> Pavel Stehule writes:
> > some customer has PostgreSQL 9.5.5. He cannot to login to database due
> > broken index
> > When I use single mode against to this database I got a error
> > start transaction
> > could not open critical system index 2679
>
> I can't
Pavel Stehule writes:
> some customer has PostgreSQL 9.5.5. He cannot to login to database due
> broken index
> When I use single mode against to this database I got a error
> start transaction
> could not open critical system index 2679
I can't reproduce this. Removing file 2679
David Rowley writes:
> On Wed, 19 Dec 2018 at 04:24, Tom Lane wrote:
>> Also, do we need to worry about integer overflow?
> Good point. I didn't think of it before, but the previous code would
> have ensured that we got an ERROR before any overflow could have
> occurred as the repalloc() would
On 12/12/18 4:44 AM, Andres Freund wrote:
On 2018-12-12 11:32:55 +0900, Michael Paquier wrote:
+1 on all that. Per the trend of this thread, I see a bunch of
committers and contributors commenting about *not* removing this code,
so sending a patch to actually remove it looks like a throw into
I wonder if this idea from seven years ago might be useful:
https://postgr.es/m/1305688547-sup-7...@alvh.no-ip.org
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi, hackers. Can you tell me which tools do you prefer when you update *.po translations? Thanks!
Andres Freund writes:
> On 2018-12-18 23:17:54 -0500, Tom Lane wrote:
>> Yeah, that would sure make things better. I was considering
>> something like
>>
>> #ifndef USE_ASSERT_CHECKING
>> default:
>> elog(ERROR, ...);
>> #endif
> Yea, that's the best I
On Wed, 19 Dec 2018 at 04:24, Tom Lane wrote:
>
> David Rowley writes:
> > I recently stumbled upon the following code in ginfast.c:
> > while (collector->ntuples + nentries > collector->lentuples)
> > {
> > collector->lentuples *= 2;
> > collector->tuples = (IndexTuple *)
"Daniel Verite" writes:
> To me it seems more natural to find a name for the other behavior, the
> one that consists of overwriting the locale-sensitive equality with
> the result of the byte-wise comparison. AFAIU the flag is meant
> to say: "don't do that".
> Some ideas that come to mind:
>
On 12/19/18 07:42, Massimo Fidanza wrote:
> Do you know about GraalVM (https://www.graalvm.org/)? This is a new
> polyglot VM that can run in context of Oracle and MySql, I think that
> supporting it on Postgresql will be a good thing.
PL/Java will run on it now ... just set
On Thu, 20 Dec 2018 at 01:58, Julien Rouhaud wrote:
> I don't see why we should drop this flag. If we know that the
> partitions are naturally ordered, they'll still be ordered after some
> partitions have been prune, so we can skip later checks if we already
> have the information. The only
On Wed, Dec 19, 2018 at 1:18 PM David Rowley
wrote:
>
> On Wed, 19 Dec 2018 at 23:25, Julien Rouhaud wrote:
> >
> > I see. But since for now the optimisation will only be done
> > considering all partitions, I still think that it's better to store a
> > bool flag in the PartitionDesc to
Do you know about GraalVM (https://www.graalvm.org/)? This is a new
polyglot VM that can run in context of Oracle and MySql, I think that
supporting it on Postgresql will be a good thing.
On Wed, Dec 19, 2018 at 2:09 PM Andres Freund wrote:
>
> Hi,
>
> The zheap patchset, even after being based on pluggable storage,
> currently has the following condition in RelationAddExtraBlocks():
> if (RelationStorageIsZHeap(relation))
> {
>
On Wed, 19 Dec 2018 at 23:25, Julien Rouhaud wrote:
> On Wed, Dec 19, 2018 at 10:51 AM David Rowley
> wrote:
> > The reason I'm keen to leave this alone today is that determining
> > which partitions are pruned requires looking at each partition's
> > RelOptInfo and checking if it's marked as a
Peter Eisentraut wrote:
> So this doesn't actually make the collation case-insensitive or
> anything, it just allows a library-provided collation that is, say,
> case-insensitive to actually work that way.
That's great news!
> So maybe "insensitive" isn't the right name for this flag,
On Thu, Nov 29, 2018 at 3:15 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Unfortunately, the patch conflict-handling-onCopy-from-v2.patch has some
> conflicts now, could you rebase it?
>
Thank you for informing, attach is rebased patch against current master
Regards
Surafel
diff --git
Hi,
On 2018-Dec-19, Andres Freund wrote:
> Well, that depends on what "non-heap layouts" you're thinking of. I
> think there'd be some further work needed to make efficient IOTs
> possible, but the patchset gets us a long way to be able to do that in a
> pluggable fashion. Biggest problem
On 2018-Dec-17, Kyotaro HORIGUCHI wrote:
> Although #1 seems cleaner to me, the fear of inadvertent removal
> of all queries with quite-common usage wins. So I vote for #4
> for now, supposing pg_stat_statements_reset(0, 0, 0) as
> all-clear.
Right -- also keeping in mind that 0 is the default
Hi,
On 2018-12-19 12:02:38 +0100, Peter Eisentraut wrote:
> On 19/12/2018 11:15, Thomas Munro wrote:
> > It just means tuples stored in no particular order (as opposed to eg
> > btree tables, in systems that support those).
>
> So would the proposed pluggable storage API allow index-organized
On 19/12/2018 11:15, Thomas Munro wrote:
> It just means tuples stored in no particular order (as opposed to eg
> btree tables, in systems that support those).
So would the proposed pluggable storage API allow index-organized base
storage and other non-heap layouts?
--
Peter Eisentraut
On Wed, Dec 19, 2018 at 10:51 AM David Rowley
wrote:
>
> On Wed, 19 Dec 2018 at 20:40, Julien Rouhaud wrote:
>
> > If I understand correctly, the new behavior is controlled by
> > partitions_are_ordered(), but it only checks for declared partitions,
> > not partitions that survived pruning. Did
On Wed, Dec 19, 2018 at 7:44 PM Arkhena wrote:
>> I'm wondering where the choice of the name "heap" originally came from
>> and what it refers to.
>
> It seems to me that "heap" is an Oracle word (as explained here[1]).
>
> > By default, a table is organized as a heap, which means that the
Meskes-san
> > I do think, though, we should change the debug output for
> > ecpg_free_params().
>
> I try to change about it. Next patch will print binary in hex-format.
I implement and attach it. Please review a new patch in this mail.
I have a question about ecpg manual when I add
Hi Tomas,
I'm a bit confused by the changes to TAP tests. Per the patch summary,
some .pl files get renamed (nor sure why), a new one is added, etc.
I added new tap test case, streaming=true option inside old stream_*
ones and incremented streaming tests number (+2) because of the
collision
On Wed, 19 Dec 2018 at 20:40, Julien Rouhaud wrote:
> I started to look at v5.
Thanks for giving this a look over.
> If I understand correctly, the new behavior is controlled by
> partitions_are_ordered(), but it only checks for declared partitions,
> not partitions that survived pruning. Did
On Wed, Dec 19, 2018 at 04:26:27PM +0900, Tatsuro Yamada wrote:
> Yep, I already did that for ALTER INDEX in
> tab_completion_alter_index_set_statistics.patch like this:
>
> + /* ALTER INDEX ALTER COLUMN SET STATISTICS */
> + else if (HeadMatches("ALTER", "INDEX") && TailMatches("SET",
>
>
>
> I'm wondering where the choice of the name "heap" originally came from
> and what it refers to.
It seems to me that "heap" is an Oracle word (as explained here[1]).
> By default, a table is organized as a heap, which means that the database
places rows where they fit best rather than in a
Hi,
The zheap patchset, even after being based on pluggable storage,
currently has the following condition in RelationAddExtraBlocks():
if (RelationStorageIsZHeap(relation))
{
Assert(BufferGetBlockNumber(buffer) != ZHEAP_METAPAGE);
On 19/12/2018 05:17, Andres Freund wrote:
> I'm concerned that naming it heap, and the corresponding functions
> fitting with that name, will be confusing. There's a lot of functions
> that have a heap_ prefix (or similar) that aren't really dependent on
> how the storage works, but much more
91 matches
Mail list logo
