> For the general forward direction but for a backwards cursor scroll,
> we'd return the lowest value for each distinct prefix, but for the
> general backwards direction (DESC case) we'd return the highest value
> for each distinct prefix. Looking at IndexNext() the cursor direction
> seems to be
On Tue, Jul 09, 2019 at 02:23:57PM +0200, Dmitry Dolgov wrote:
> > On Mon, Jul 8, 2019 at 6:46 AM Thomas Munro wrote:
> >
> > On Fri, Jun 7, 2019 at 6:22 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > > > > >> Rebase after pg_indent. Besides, off the list there was a
> > > > > >> suggestion
On Wed, Jul 10, 2019 at 7:40 AM Dmitry Belyavsky wrote:
> [ltree_20190709.diff]
Hi Dmitry,
You need to update contrib/ltree_plpython/expected/ltree_plpython.out,
otherwise check-world fails when built with Python support. The good
news is that it looks like it fails because you fixed something!
Hello
Patch is still applied cleanly on HEAD and passes check-world. I think ignoring
FOR UPDATE clause is incorrect behavior.
PS: my note about comments in tests from my previous review is actual too.
regards, Sergei
On Thu, Jul 11, 2019 at 2:30 AM Michael Paquier wrote:
> On Wed, Jul 10, 2019 at 09:19:03AM -0700, Andres Freund wrote:
> > On July 10, 2019 9:12:18 AM PDT, Magnus Hagander
> wrote:
> >> That would be fine, if we actually knew. Should we (or have we already?)
> >> defined a rule that they are no
I have set the local build configuration to be the same as on the CI. This
patch should be correct.
Best regards,
Binguo Bao
Binguo Bao 于2019年7月11日周四 上午12:39写道：
> This is the patch that fix warnings.
>
> Best Regards,
> Binguo Bao
>
> Binguo Bao 于2019年7月10日周三 下午10:18写道：
>
>> Hi Thomas,
>> I've
On Thu, Jul 11, 2019 at 6:04 AM Michael Paquier wrote:
>
> On Wed, Jul 10, 2019 at 09:44:14PM +0200, Julien Rouhaud wrote:
> > On Wed, Jul 10, 2019 at 4:15 PM Alvaro Herrera
> > wrote:
> >> Looking good!
> >
> > Thanks!
>
> Confirmed. The last set is much easier to go through.
>
> >> I'm not s
Hi,
On 7/9/19 12:22 AM, Morris de Oryx wrote:
> I have some specific questions about pg_xact_commit_timestamp, and am hoping
> that this is the right place to ask. I read a lot of the commentary about the
> original patch, and the contributors seem to be here. If I'm asking in the
> wrong
> place
On 7/4/19 1:39 PM, Peter Eisentraut wrote:
> On 2019-03-25 12:04, Panagiotis Mavrogiorgos wrote:
>> Last November snowball added support for Greek language [1]. Following
>> the instructions [2], I wrote a patch that adds fulltext search for
>> Greek in Postgres. The patch is attached.
>
> I have
On Thu, 11 Jul 2019 at 19:41, Floris Van Nee wrote:
> SELECT DISTINCT ON (a) a,b,c FROM a WHERE c = 2 (with an index on a,b,c)
> Data (imagine every tuple here actually occurs 10.000 times in the index to
> see the benefit of skipping):
> 1,1,1
> 1,1,2
> 1,2,2
> 1,2,3
> 2,2,1
> 2,2,3
> 3,1,1
> 3,
On Tue, Jul 9, 2019 at 9:47 PM Antonin Houska wrote:
> Richard Guo wrote:
>
> > Another rebase is needed for the patches.
>
> Done.
>
I didn't fully follow the whole thread and mainly looked into the latest
patch set. So what are the considerations for abandoning the aggmultifn
concept? In my
Hello.
At Tue, 9 Jul 2019 17:38:44 +0900, Tatsuro Yamada
wrote in
<244cb241-168b-d6a9-c45f-a80c34cdc...@nttcom.co.jp>
> Hi Alvaro, Anthony, Julien and Robert,
>
> On 2019/07/09 3:47, Julien Rouhaud wrote:
> > On Mon, Jul 8, 2019 at 8:44 PM Robert Haas
> > wrote:
> >>
> >> On Mon, Jul 8, 2019
Hello
>> Attached is a very hackish patch to implement this. It works like this:
>>
>> # (assuming you have a primary already running somewhere)
>> initdb -D data2 --minimal
>> $EDITOR data2/postgresql.conf # set primary_conninfo
>> pg_ctl -D data2 start
>
> +1, very nice. How
Hi Anastasia,
On Wed, Jul 10, 2019 at 11:47 PM Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
> 23.04.2019 14:08, Anastasia Lubennikova wrote:
> > I'm volunteering to write a draft patch or, more likely, set of
> > patches, which
> > will allow us to discuss the subject in more deta
On Thu, 11 Jul 2019 at 02:48, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Tue, Jul 2, 2019 at 2:27 PM David Rowley
> > wrote:
> >
> > The more I think about these UniqueKeys, the more I think they need to
> > be a separate concept to PathKeys. For example, UniqueKeys: { x, y }
> > shoul
On Thu, 11 Jul 2019 at 10:22, David Rowley wrote:
> > A. Continue to target only heapam tables, making the bare minimum
> > changes necessary for the new tableam api.
> > B. Try to do something more general that works on all tableam
> > implementations for which it may be useful.
>
> Going by th
Hello
I noticed few warnings from my compiler (gcc version 8.3.0 (Debian 8.3.0-6))
during make check-world:
array.pgc: In function ‘main’:
array.pgc:41:16: warning: ‘%d’ directive writing between 1 and 11 bytes into a
region of size 10 [-Wformat-overflow=]
sprintf(str, "2000-1-1 0%d:00:00",
On Wed, 10 Jul 2019 at 16:34, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer wrote:
> >> I'm still a bit conflicted about what to do with search_path as I do
> believe this is potentially a security issue.
> >> It may be that we always want to report that
> >>Uh, what if a transaction modifies page 0 and page 1 of the same table
> >>--- don't those pages have the same LSN.
> >
> >No, because WAL being a physical change log, each page gets its own
> >WAL record with its own LSN.
> >
>
> What if you have wal_log_hints=off? AFAIK that won't change the
On Tue, Jul 9, 2019 at 3:31 PM Mike Palmiotto
wrote:
> Attached you will find a patch (rebased on master) that passes all
> tests on my local CentOS 7 box. Thanks again for the catch!
Hi Mike,
Here are some comments on superficial aspects of the patch:
+/* Custom partition child access hook. Pr
On Thu, Jul 11, 2019 at 11:48:20AM +0200, Julien Rouhaud wrote:
> On Thu, Jul 11, 2019 at 6:04 AM Michael Paquier wrote:
>> Get* would be my choice, because we look at the set of parallel slots,
>> and get an idle one.
>
> That's what the former GetIdleSlot (that I renamed to get_idle_slot as
> i
On Thu, Jul 11, 2019 at 03:21:15PM +0300, Sergei Kornilov wrote:
> I noticed few warnings from my compiler (gcc version 8.3.0 (Debian
> 8.3.0-6)) during make check-world:
>
> They coming from src/interfaces/ecpg tests (
> ./src/interfaces/ecpg/test/sql/array.pgc ).
> Seems this code is 4 year old b
Hi
>
> Also, I would prefer having an option to ignore all errors, e.g. with
> option ERROR_LIMIT set to -1. Because it is rather difficult to estimate
> a number of future errors if you are playing with some badly structured
> data, while always setting it to 100500k looks ugly.
>
Here are the p
Joe Conway wrote:
> Please see my other reply (and
> https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf
> appendix C as pointed out by Ryan downthread).
Thanks.
> At least in my mind, I trust a published specification from the
> nation-state level over random blogs or
Hi
> Are you using -Wformat-overflow? At which level?
I use: ./configure --prefix=somepath --enable-cassert --enable-debug
CFLAGS="-ggdb -Og -g3 -fno-omit-frame-pointer" --enable-tap-tests
No other explicit options.
pg_config reports:
CPPFLAGS = -D_GNU_SOURCE
CFLAGS = -Wall -Wmissing-prototype
Em sáb, 29 de jun de 2019 às 17:05, Peter Eisentraut
escreveu:
>
> Setting up a standby instance is still quite complicated. You need to
> run pg_basebackup with all the right options. You need to make sure
> Attached is a very hackish patch to implement this. It works like this:
>
> # (ass
On Thu, Jul 11, 2019 at 8:23 AM Dave Cramer wrote:
> See attached for an initial patch. If this is an acceptable way to go I will
> add tests and documentation
And clean up the code? Doesn't look crazy on a quick glance but I
think I see at least half a dozen coding style problems. More
substa
On Wed, 10 Jul 2019 at 05:58, Alexander Korotkov
wrote:
>
> On Mon, Jul 8, 2019 at 12:30 AM Alexander Korotkov
> wrote:
> > On Thu, Jul 4, 2019 at 4:38 PM Liudmila Mantrova
> > wrote:
> > > Thank you!
> > >
> > > I think we can make this sentence even shorter, the fix is attached:
> > >
> > > "
On Thu, 11 Jul 2019 at 10:06, Robert Haas wrote:
> On Thu, Jul 11, 2019 at 8:23 AM Dave Cramer wrote:
> > See attached for an initial patch. If this is an acceptable way to go I
> will add tests and documentation
>
> And clean up the code? Doesn't look crazy on a quick glance but I
> think I se
Robert Haas writes:
> 3. I'm not sure that just ignoring any GUCs we don't find is the right
> thing. I'm also not sure that it's the wrong thing, but it might be.
> My question is: what if there's an extension-owned GUC in play? The
> library probably isn't even loaded at this stage, unless it's
On Thu, Jul 11, 2019 at 10:11 AM Tom Lane wrote:
> Robert Haas writes:
> > 3. I'm not sure that just ignoring any GUCs we don't find is the right
> > thing. I'm also not sure that it's the wrong thing, but it might be.
> > My question is: what if there's an extension-owned GUC in play? The
> > l
On Sat, Jun 29, 2019 at 4:05 PM Peter Eisentraut
wrote:
> My idea is that the postmaster can launch a base backup worker, wait
> till it's done, then proceed with the rest of the startup. initdb gets
> a special option to create a "minimal" data directory with only a few
> files, directories, and
On Wed, Jul 10, 2019 at 09:53:04PM -0700, Peter Geoghegan wrote:
> Anyway, I think that *hundreds* or even *thousands* of rows are
> effectively locked all at once when a bitmap index needs to be updated
> in these other systems -- and I mean a heavyweight lock that lasts
> until the xact commits o
On Thu, Jul 11, 2019 at 04:30:46PM +0200, Dmitry Dolgov wrote:
> > On Thu, Jul 11, 2019 at 9:47 AM David Fetter wrote:
> >
> > Looks great!
> >
> > The tutorial piece has bit-rotted slightly. Please find attached a
> > patch atop yours that fixes it.
>
> Indeed, I've missed this change, thank you
张连壮 wrote:
> it reset statistics for a single table and update the column stats_reset of
> pg_stat_database.
> but i think that stats_reset shoud be database-level statistics, a single
> table should not update the column stats_reset.
This patch is a current CF entry at
https://commitfest
Robert Haas writes:
> I had the same thought, but I just realized that's probably
> unfriendly: at the point when the client is assembling the list of
> names to send to the server, it doesn't know the server version. I
> think we're probably best off assuming that any names we don't
> recognize
Robert Haas writes:
> On Sat, Jun 29, 2019 at 4:05 PM Peter Eisentraut
> wrote:
>> My idea is that the postmaster can launch a base backup worker, wait
>> till it's done, then proceed with the rest of the startup. initdb gets
>> a special option to create a "minimal" data directory with only a f
On Thu, Jul 11, 2019 at 09:55:01AM +0900, Michael Paquier wrote:
On Wed, Jul 10, 2019 at 11:26:09PM +0200, Tomas Vondra wrote:
Yeah, that's a bug. Will fix (not sure how yet).
Please note that I have added an open item for it.
Thanks.
--
Tomas Vondra http://www.2ndQuadrant.
Hi Peter,
Thank you very much for your attention to this patch. Let me comment
some points of your message.
On Sun, Jul 7, 2019 at 2:09 AM Peter Geoghegan wrote:
> On Thu, Jul 4, 2019 at 5:06 AM Anastasia Lubennikova
> wrote:
> > The new version of the patch is attached.
> > This version is eve
On Thu, Jul 11, 2019 at 7:53 AM Peter Geoghegan wrote:
> Anyway, I think that *hundreds* or even *thousands* of rows are
> effectively locked all at once when a bitmap index needs to be updated
> in these other systems -- and I mean a heavyweight lock that lasts
> until the xact commits or aborts,
On Wed, Jul 10, 2019 at 06:48:16PM -0400, Tom Lane wrote:
Oh ... while we're piling on here, it just sunk into me that
mcv_get_match_bitmap is deciding what the semantics of an operator
are by seeing what it's using for a selectivity estimator.
That is just absolutely, completely wrong. For star
On Thu, Jul 11, 2019 at 06:45:36AM -0600, Ryan Lambert wrote:
> > >>Uh, what if a transaction modifies page 0 and page 1 of the same table
>
> > >>--- don't those pages have the same LSN.
> > >
> > >No, because WAL being a physical change log, each page gets its own
> > >WAL record with its own LS
On Thu, Jul 11, 2019 at 5:10 PM Thom Brown wrote:
> On Wed, 10 Jul 2019 at 05:58, Alexander Korotkov
> wrote:
> >
> > On Mon, Jul 8, 2019 at 12:30 AM Alexander Korotkov
> > wrote:
> > > On Thu, Jul 4, 2019 at 4:38 PM Liudmila Mantrova
> > > wrote:
> > > > Thank you!
> > > >
> > > > I think we
On Sun, 7 Jul 2019 at 01:08, Peter Geoghegan wrote:
> * Maybe we could do compression with unique indexes when inserting
> values with NULLs? Note that we now treat an insertion of a tuple with
+1
I tried this patch and found the improvements impressive. However,
when I tried with multi-column i
On Wed, Jul 10, 2019 at 04:51:02PM -0700, Melanie Plageman wrote:
Okay, so, while I do have specific, actual code review/commitfest-y
feedback for the patch in this thread registered for this commitfest,
I wanted to defer that for a later email and use this one to cover off
on a few higher level
On 7/10/19 8:24 PM, Andres Freund wrote:
> Hi,
>
> On 2019-07-10 16:40:20 -0400, Andrew Dunstan wrote:
>> On 7/10/19 1:34 PM, Andres Freund wrote:
>>> Hm, it has gotten gcc-9 installed recently, but calliphoridae isn't
>>> using that. So it's probably not the compiler side. But I also see a
>>> b
On Wed, Jul 03, 2019 at 07:03:06PM -0700, Jeff Davis wrote:
On Wed, 2019-07-03 at 02:17 +0200, Tomas Vondra wrote:
What does "partitioned hash strategy" do? It's probably explained in
one
of the historical discussions, but I'm not sure which one. I assume
it
simply hashes the group keys and uses
On 5/2/19 12:35 PM, Fabien COELHO wrote:
>
>> Now the patch is good now.
>>
>> The new status of this patch is: Ready for Committer
>
> Ok, thanks.
>
Why aren't we instead putting the exact scripts in the documentation?
Having to call pgbench with a special flag to get the script text seems
a b
On Thu, 11 Jul 2019 at 10:19, Robert Haas wrote:
> On Thu, Jul 11, 2019 at 10:11 AM Tom Lane wrote:
> > Robert Haas writes:
> > > 3. I'm not sure that just ignoring any GUCs we don't find is the right
> > > thing. I'm also not sure that it's the wrong thing, but it might be.
> > > My question
Hello Andrew,
Now the patch is good now.
The new status of this patch is: Ready for Committer
Why aren't we instead putting the exact scripts in the documentation?
Having to call pgbench with a special flag to get the script text seems
a bit odd.
A typical use case I had is to create a ne
On Thu, Jul 11, 2019 at 3:34 PM Michael Paquier wrote:
>
> On Thu, Jul 11, 2019 at 11:48:20AM +0200, Julien Rouhaud wrote:
> > On Thu, Jul 11, 2019 at 6:04 AM Michael Paquier wrote:
> >> Get* would be my choice, because we look at the set of parallel slots,
> >> and get an idle one.
> >
> > That'
Andrew Dunstan writes:
> On 7/10/19 8:24 PM, Andres Freund wrote:
>> I think that's kinda what I'm complaining about... It seems like a bad
>> idea to have this in the buildfarm code, rather than our code. IMO the
>> buildfarm code should invoke an updated src/tools/find_typedef - that
>> way peop
Hi David,
On 7/11/19 7:38 AM, David Rowley wrote:
The UniqueKeys idea is quite separate from pathkeys. Currently, a
Path can have a List of PathKeys which define the order that the
tuples will be read from the Plan node that's created from that Path.
The idea with UniqueKeys is that a Path can
On Mon, May 6, 2019 at 9:49 PM Thomas Munro wrote:
> Stepping back a bit, I think there is something fishy about the way we
> detect extreme skew. Is that a factor in this case? Right now we
> wait until we have a batch that gets split into child batches
> containing exactly 0% and 100% of the t
On Thu, Jul 11, 2019 at 7:30 AM Bruce Momjian wrote:
> Wow, I never thought of that. The only things I know we lock until
> transaction end are rows we update (against concurrent updates), and
> additions to unique indexes. By definition, indexes with many
> duplicates are not unique, so that do
On Thu, Jul 11, 2019 at 10:35 AM Tom Lane wrote:
> All of the above is based on the assumption that this isn't a plain
> old USERSET GUC, which I'm not really seeing the argument for.
> OK, there might be *implementation* reasons why we would rather not
> deal with on-the-fly changes to the list,
On Thu, Jul 11, 2019 at 8:02 AM Alexander Korotkov
wrote:
> Could you please elaborate more on preserving the logical contents? I
> can understand it as following: "B-Tree should have the same structure
> and invariants as if each TID in posting list be a separate tuple".
That's exactly what I m
Dear Thomas,
On Thu, Jul 11, 2019 at 11:20 AM Thomas Munro
wrote:
> On Wed, Jul 10, 2019 at 7:40 AM Dmitry Belyavsky
> wrote:
> > [ltree_20190709.diff]
>
> Hi Dmitry,
>
> You need to update contrib/ltree_plpython/expected/ltree_plpython.out,
> otherwise check-world fails when built with Python
On Thu, Jul 11, 2019 at 8:09 AM Alexander Korotkov
wrote:
> BTW, I think deduplication could cause some small performance
> degradation in some particular cases, because page-level locks became
> more coarse grained once pages hold more tuples. However, this
> doesn't seem like something we shoul
On Thu, Jul 11, 2019 at 8:34 AM Rafia Sabih wrote:
> I tried this patch and found the improvements impressive. However,
> when I tried with multi-column indexes it wasn't giving any
> improvement, is it the known limitation of the patch?
It'll only deduplicate full duplicates. It works with multi
On Wed, 10 Jul 2019 at 16:22, Robert Haas wrote:
> On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer wrote:
> > I'm still a bit conflicted about what to do with search_path as I do
> believe this is potentially a security issue.
> > It may be that we always want to report that and possibly back patch
On 7/11/19 12:50 PM, Tom Lane wrote:
>
>> This looks like a bug in the version of objdump unless I'm reading it
>> wrong. Why would this be tagged as a typedef?
> Maybe. We still need to explain the other non-typedef symbols that have
> just appeared and are not being reported by calliphoridae.
On Thu, Jul 11, 2019 at 2:29 PM Dave Cramer wrote:
> So if I understand this correctly if user bob has altered his search path and
> there is a security-definer function called owned by him then
> the search path will be changed for the duration of the function and reported
> for every iteration
On Thu, Jul 11, 2019 at 10:36 AM Tom Lane wrote:
> Gotta have config files in place already, no?
Why?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, 11 Jul 2019 at 15:07, Robert Haas wrote:
> On Thu, Jul 11, 2019 at 2:29 PM Dave Cramer wrote:
> > So if I understand this correctly if user bob has altered his search
> path and there is a security-definer function called owned by him then
> > the search path will be changed for the dura
On Tue, Jun 18, 2019 at 10:33 PM Peter Eisentraut
wrote:
>
> On 2019-05-23 18:54, Peter Eisentraut wrote:
> > To recap, the idea here was to change the default authentication methods
> > that initdb sets up, in place of "trust".
> >
> > I think the ideal scenario would be to use "peer" for local a
On Tue, Jul 9, 2019 at 10:43 AM Bruce Momjian wrote:
> FYI, pg_upgrade already preserves the pg_class.oid, which is why I
> recommended it over pg_class.relfilenode:
I think it's strange that pg_upgrade does not preserve the
relfilenode. I think it would probably make more sense if it did.
Anyw
On Thu, Jul 11, 2019 at 03:47:50PM -0400, Robert Haas wrote:
> On Tue, Jul 9, 2019 at 10:43 AM Bruce Momjian wrote:
> > FYI, pg_upgrade already preserves the pg_class.oid, which is why I
> > recommended it over pg_class.relfilenode:
>
> I think it's strange that pg_upgrade does not preserve the
>
Robert Haas writes:
> On Thu, Jul 11, 2019 at 10:36 AM Tom Lane wrote:
>> Gotta have config files in place already, no?
> Why?
How's the postmaster to know that it's supposed to run pg_basebackup
rather than start normally? Where will it get the connection information?
Seem to need configurati
On Thu, Jul 11, 2019 at 4:10 PM Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Jul 11, 2019 at 10:36 AM Tom Lane wrote:
> >> Gotta have config files in place already, no?
>
> > Why?
>
> How's the postmaster to know that it's supposed to run pg_basebackup
> rather than start normally? Where w
On Thu, Jul 11, 2019 at 09:34:25PM +0200, Julien Rouhaud wrote:
> On Tue, Jun 18, 2019 at 10:33 PM Peter Eisentraut
> wrote:
> >
> > On 2019-05-23 18:54, Peter Eisentraut wrote:
> > > To recap, the idea here was to change the default authentication methods
> > > that initdb sets up, in place of "t
On Thu, Jul 11, 2019 at 8:49 AM Thomas Munro wrote:
>
>
> Here are some comments on superficial aspects of the patch:
>
> +/* Custom partition child access hook. Provides further partition pruning
> given
> + * child OID.
> + */
>
> Should be like:
>
> /*
> * Multi-line comment...
> */
Fixed
On 2019-07-11 22:20, Robert Haas wrote:
> On Thu, Jul 11, 2019 at 4:10 PM Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Jul 11, 2019 at 10:36 AM Tom Lane wrote:
Gotta have config files in place already, no?
>>
>>> Why?
>>
>> How's the postmaster to know that it's supposed to run pg_bas
Hi,
I had some spare time tonight so I started a prototype to allow
filtering the indexes that are processed using the REINDEX command, as
Peter suggested in the parallel reindexdb thread [1].
I didn't want to spend too much time enjoying bison and adding new
unreserved keywords, so for now I jus
Peter Eisentraut writes:
> On 2019-07-11 22:20, Robert Haas wrote:
>> On Thu, Jul 11, 2019 at 4:10 PM Tom Lane wrote:
>>> How's the postmaster to know that it's supposed to run pg_basebackup
>>> rather than start normally? Where will it get the connection information?
>>> Seem to need configurat
On Fri, May 10, 2019 at 8:54 AM Shawn Debnath wrote:
> On Wed, May 08, 2019 at 06:31:04PM +1200, Thomas Munro wrote:
> Looks good to me. Minor nit: update the comment for XLogRecGetBlockTag:
Fixed. Also fixed broken upgrade scripts for pg_buffercache
extension, as pointed out by Robert[1] on the
On Wed, Jul 10, 2019 at 12:26:24PM -0400, Bruce Momjian wrote:
> On Wed, Jul 10, 2019 at 08:31:17AM -0400, Joe Conway wrote:
> > Please see my other reply (and
> > https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf
> > appendix C as pointed out by Ryan downthread).
> >
>
On Mon, Jun 10, 2019 at 5:38 PM Ashwin Agrawal wrote:
>
> On Mon, Jun 10, 2019 at 2:56 PM Andres Freund wrote:
>
>> > Currently, all AM needs to build HeapTuple in
>> > index_build_range_scan function. I looked into all the callback
>> functions
>> > and only htup->t_self is used from heaptuple
On 7/11/19 6:37 PM, Bruce Momjian wrote:
> On Wed, Jul 10, 2019 at 12:26:24PM -0400, Bruce Momjian wrote:
>> On Wed, Jul 10, 2019 at 08:31:17AM -0400, Joe Conway wrote:
>>> Please see my other reply (and
>>> https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf
>>> appendix
Hello.
At Sat, 29 Jun 2019 22:05:22 +0200, Peter Eisentraut
wrote in
<61b8d18d-c922-ac99-b990-a31ba63cd...@2ndquadrant.com>
> Setting up a standby instance is still quite complicated. You need to
> run pg_basebackup with all the right options. You need to make sure
> pg_basebackup has the rig
On Wed, Jul 10, 2019 at 01:19:14PM +0900, Kyotaro Horiguchi wrote:
> Hello. Rebased the patch to master(bd56cd75d2).
It looks like you did more than just a rebase, because this v16 no longer
modifies many files that v14 did modify. (That's probably good, since you had
pending review comments.) W
On Thu, Jul 11, 2019 at 08:41:52PM -0400, Joe Conway wrote:
> On 7/11/19 6:37 PM, Bruce Momjian wrote:
> > Our first implementation will encrypt the entire cluster. We can later
> > consider encryption per table or tablespace. It is unclear if
> > encrypting different parts of the system with dif
On Thu, 2019-07-11 at 17:55 +0200, Tomas Vondra wrote:
> Makes sense. I haven't thought about how the hybrid approach would be
> implemented very much, so I can't quite judge how complicated would
> it be
> to extend "approach 1" later. But if you think it's a sensible first
> step,
> I trust you.
On Thu, Jul 11, 2019 at 06:22:25PM +0200, Julien Rouhaud wrote:
> I think t hat it makes the code quite cleaner to have the selection
> outside ConsumeIdleSlot.
Actually, you have an issue with ConsumeIdleSlot() if there is only
one parallel slot, no? In this case the current patch returns
immedi
Hello hackers,
Here is a small patch extracted from the undo log patch set that I'd
like to discuss separately and commit soon. I'm pretty sure that
zheap, zedstore and anyone else developing new AMs based on 64 bit
xids needs this, but there are no plans to extend WAL records to
actually carry 6
On Tue, Jul 09, 2019 at 08:26:52AM -0400, Andrew Dunstan wrote:
> On 4/16/19 1:22 AM, Noah Misch wrote:
> > On Thu, Mar 07, 2019 at 03:23:50PM +0100, Sandro Mani wrote:
> >> Related, no actual static libraries are produced alongside the respective
> >> dlls. The attached patch 0002-Build-static-lib
More typos in tableam.h along with a few grammar changes.
v1-more-typos-in-tableam.h.patch
Description: Binary data
On Thu, Jul 11, 2019 at 10:42 AM Peter Geoghegan wrote:
> > I think unique indexes may benefit from deduplication not only because
> > of NULL values. Non-HOT updates produce duplicates of non-NULL values
> > in unique indexes. And those duplicates can take significant space.
>
> I agree that we
On Thu, Jul 11, 2019 at 06:37:41PM -0400, Bruce Momjian wrote:
> wal_log_hints will be enabled automatically in encryption mode, like we
> do for checksum mode, so we never encrypt different 8k pages with the
> same IV.
Checksum mode can be enabled in encrypted clusters to detect modified
data, si
Hello.
In src/tools/msvc/config_default.pl, peremeter "perl" requires a
path string, not a bool differently from that of configure
script. --with-python has the same characteristics and the
comment is suggesting that.
We need to fix --with-perl and --with-uuid the same way.
regards.
--
Kyotaro
Hi,
The 2019b DST update [1] disables DST for Brazil. This would take effect
starting November 2019. The last DST update in Postgres was 2019a in v11.3
(since this update came in after the recent-most Postgres release).
Since a ~3 month release cycle may be too close for some users, are there
any
On Fri, Jul 12, 2019 at 12:15:29PM +0900, Kyotaro Horiguchi wrote:
> In src/tools/msvc/config_default.pl, parameter "perl" requires a
> path string, not a bool differently from that of configure
> script. --with-python has the same characteristics and the
> comment is suggesting that.
>
> We need
On Fri, Jul 12, 2019 at 01:42:59PM +1000, Robins Tharakan wrote:
> The 2019b DST update [1] disables DST for Brazil. This would take effect
> starting November 2019. The last DST update in Postgres was 2019a in v11.3
> (since this update came in after the recent-most Postgres release).
>
> Since a
On Thu, Jul 11, 2019 at 3:46 AM Tom Lane wrote:
>
> Amit Langote writes:
> > Attached updated patch. Thanks again.
>
> Pushed with a bit of further cleanup
Thanks a lot.
> --- most notably, the way
> you had execute_sql_string(), it was still leaking any cruft
> ProcessUtility might generate.
On Thu, Jul 11, 2019 at 04:34:20PM +0200, Daniel Verite wrote:
> I can understand why you'd want that resetting the stats for a single object
> would not reset the per-database timestamp, but this would revert a 8+ years
> old decision that seems intentional and has apparently not been criticized
>
On Fri, 12 Jul 2019 at 14:04, Michael Paquier wrote:
> On Fri, Jul 12, 2019 at 01:42:59PM +1000, Robins Tharakan wrote:
> So 2019b has been released on the 1st of July. Usually tzdata updates
> happen just before a minor release, so this would get pulled in at the
> beginning of August (https://
On Fri, Jul 12, 2019 at 7:37 AM Bruce Momjian wrote:
>
> On Wed, Jul 10, 2019 at 12:26:24PM -0400, Bruce Momjian wrote:
> > On Wed, Jul 10, 2019 at 08:31:17AM -0400, Joe Conway wrote:
> > > Please see my other reply (and
> > > https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-3
I am trying to build Postgres in an IDE (CLion on Ubuntu), and I'm getting
the following error message:
In file included from /workspace/src/postgres/src/include/c.h:61:0,
from /workspace/src/postgres/src/include/postgres.h:46,
from /workspace/src/postgres/contrib
Horiguchi-san,
Thanks for the comment. My reply is a bit late now, but
On Wed, Jul 10, 2019 at 5:39 PM Kyotaro Horiguchi
wrote:
> At Wed, 10 Jul 2019 16:35:18 +0900, Amit Langote
> wrote:
> - * Switch to appropriate context for constructing querytrees (again,
> - * these must outl
On Thu, Jul 11, 2019 at 10:21:06PM -0700, Igal Sapir wrote:
> Any thoughts? (disclaimer: I have much more experience with Java than C)
We don't support cmake directly. Here is the documentation about how
to build the beast:
https://www.postgresql.org/docs/current/install-procedure.html
--
Michae
1 - 100 of 111 matches
Mail list logo
