Is this possible with the current websearch_to_tsquery function?
Thanks.
Hello everyone, I am wondering if
> AROUND(N) or is still possible? I found this thread below and the
> original post
> https://www.postgresql.org/message-id/fe93ff7e9ad79196486ada79e268%40postgrespro.ru
> mentioned the
Hi Michael,
The patches are attached. To make reviewing easier we spilt them into small
pieces:
- v1-0001-Fix-race-condition-in-pg_mkdir_p.patch: the fix to pg_mkdir_p()
itself, basically we are following the `mkdir -p` logic;
- v1-0002-Test-concurrent-call-to-pg_mkdir_p.patch: the tests for
p
On Tue, Jun 18, 2019 at 09:59:08AM +0900, Michael Paquier wrote:
> On Mon, Jun 17, 2019 at 10:50:39AM -0400, Alvaro Herrera wrote:
> > I think this should be note() rather than print(), or maybe diag(). (I
> > see that we have a couple of other cases which use print() in the tap
> > tests, which I
On 2019-07-22 21:16, Andrew Dunstan wrote:
> Modulo this issue, experimentation shows that adding '-A trust' to the
> line in run_build.pl where initdb is called fixes the issue. If we're
> going to rely on a buildfarm client fix that one seems simplest.
Yes, that is the right fix. It's what the
On Tue, 23 Jul 2019 at 15:47, Tsunakawa, Takayuki
wrote:
> OTOH, how about my original patch that is based on the local lock list? I
> expect that it won't that significant slowdown in the same test case. If
> it's not satisfactory, then v6 is the best to commit.
I think we need to move beyon
On Mon, Jul 22, 2019 at 11:18:06AM -0400, Alvaro Herrera wrote:
> BTW "progname" is a global variable in logging.c, and it's initialized
> by pg_logging_init(), so there's no point in having a local variable in
> main() that's called the same and initialized the same way. You could
> just remove i
On Tue, Jul 16, 2019 at 1:11 AM Robert Haas wrote:
> On Fri, Jul 12, 2019 at 11:03 PM Thomas Munro wrote:
> > I pushed this too. It's a separate commit, because I think there is
> > at least a theoretical argument that it should be back-patched. I'm
> > not going to do that today though, becaus
Hi Horiguchi-san, Alvaro, Anthony, Julien and Robert,
On 2019/07/22 17:30, Kyotaro Horiguchi wrote:
Hello.
# It's very good timing, as you came in while I have a time after
# finishing a quite nerve-wrackig task..
At Mon, 22 Jul 2019 15:02:16 +0900, Tatsuro Yamada
wrote in <0876b4fe-26fb-ca
From: David Rowley [mailto:david.row...@2ndquadrant.com]
> Another counter-argument to this is that there's already an
> unexplainable slowdown after you run a query which obtains a large
> number of locks in a session or use prepared statements and a
> partitioned table with the default plan_cache
On Fri, Jul 19, 2019 at 3:00 PM Amit Kapila wrote:
> On Thu, Jul 18, 2019 at 7:15 PM Tom Lane wrote:
> > Thomas Munro writes:
> > > Hmm, so something like a new argument "bool final" added to the
> > > ExecXXXShutdown() functions, which receives false in this case to tell
> > > it that there cou
Hello. I happened to find that I cannot obtain a patch from the
Emails field of a patch on the CF-App.
https://commitfest.postgresql.org/23/1525/
Emails:
> Latest attachment (crash_dump_before_main_v2.patch) at 2018-03-01 05:13:34
> from "Tsunakawa, Takayuki"
The link directly shown in Emails
On Mon, Jul 22, 2019 at 8:39 PM Amit Khandekar wrote:
>
> On Mon, 22 Jul 2019 at 14:21, Amit Kapila wrote:
>
> -
>
> +UndoWorkerGetSlotInfo(int slot, UndoRequestInfo *urinfo)
> +{
> + /* Block concurrent access. */
> + LWLockAcquire(UndoWorkerLock, LW_EXCLUSIVE);
> +
> + MyUndoWorker
On Thu, 18 Jul 2019 at 07:01, Tom Lane wrote:
> Seems like maybe what we need is to transpose the tests at issue into
> a TAP test? That could grep for the messages we care about and disregard
> other ones.
That seems like a good idea. I guess that's a vote in favour of
having DEBUG1 for ATTAC
Kyotaro-san
Thank you for your review.
> First, this patch looks broken.
I took a serious mistake.
> You also need to update the corresponding documentation.
I attach a new patch that includes updating of document.
Regards
Ryo Matasumura
libpq_state_change_bugfix.ver1.1.patch
Description: l
On Mon, Jul 22, 2019 at 01:25:41PM -0400, Jesper Pedersen wrote:
> Hi,
>
> On 7/21/19 9:48 PM, Michael Paquier wrote:
> > > Since pg_receivewal does not apply WAL, you should not allow it to
> > > become a synchronous standby when synchronous_commit = remote_apply.
> > > If it does, it will appear
On Tue, Jul 23, 2019 at 6:19 AM Peter Eisentraut
wrote:
> On 2019-07-09 11:43, Peter Eisentraut wrote:
> > After further research I'm thinking about dropping the libunwind
> > support. The backtrace()/backtrace_symbols() API is more widely
> > available: darwin, freebsd, linux, netbsd, openbsd (v
On Mon, Jul 22, 2019 at 11:25 PM Nikita Glukhov wrote:
> Columns "Handler" and "Description" were added to \dA+.
>
> \dA [NAME] now shows only amname and amtype.
Cool!
> Also added support for pre-9.6 server versions to both \dA and \dA+.
I was going to ask about that. You got ahead of me :-)
On 7/22/19 3:20 PM, Andrew Dunstan wrote:
>
> On 7/22/19 3:15 PM, Tom Lane wrote:
>>
>> Frankly, this episode makes me wonder whether changing the default is
>> even a good idea at this point. People who care about security have
>> already set up their processes to select a useful-to-them auth op
On 2019-Jul-17, Alvaro Herrera wrote:
> On 2019-Jul-17, Alvaro Herrera wrote:
> > I wonder if there are other AT subcommands that are similarly broken,
> > because many of them skip the CheckTableNotInUse for the partitions.
>
> I suppose the question here is where else do we need to call the ne
Hello Peter,
About the pg_dump code, I'm wondering whether it is worth generating
LOCALE as it breaks backward compatibility (eg dumping a new db to load it
into a older version).
We don't really care about backward compatibility here. Moving forward,
with ICU and such, we don't want to hav
I wrote:
> I tried doing a run on gaur (old HPUX, so no "peer" auth) before the
> revert happened. It got as far as initdb-check [1], which failed quite
> thoroughly with lots of the same error as above.
> ...
> Presumably Noah's AIX menagerie would have failed in about the
> same way if it had ru
Alvaro Herrera writes:
> On 2019-Jul-22, Tom Lane wrote:
>> I nearly missed the need for that because of all the noise that
>> check-world emits in pre-v12 branches. We'd discussed back-patching
>> eb9812f27 at the time, and I think now it's tested enough that doing
>> so is low risk (or at least
Thanks a lot for the fix!
Best,
Manuel
On Mon, Jul 22, 2019 at 9:35 PM Alvaro Herrera wrote:
>
> On 2019-Jul-22, Tom Lane wrote:
>
> > I nearly missed the need for that because of all the noise that
> > check-world emits in pre-v12 branches. We'd discussed back-patching
> > eb9812f27 at the tim
Attached 8th version of the patches.
On 22.07.2019 15:58, Alexander Korotkov wrote:
On Mon, Jul 22, 2019 at 6:29 AM Alvaro Herrera wrote:
On 2019-Jul-21, Alexander Korotkov wrote:
I've one note. Behavior of "\dA" and "\dA pattern" look
counter-intuitive to me. I would rather expect that "\
I wrote:
> Just noticing that ExceptionalCondition has an "fflush(stderr);"
> in front of what you added --- perhaps you should also add one
> after the backtrace_symbols_fd call? It's not clear to me that
> that function guarantees to fflush, nor do I want to assume that
> abort() does.
Oh, wait
Peter Eisentraut writes:
> Here is an updated patch without the libunwind support, some minor
> cleanups, documentation, and automatic back traces from assertion failures.
Just noticing that ExceptionalCondition has an "fflush(stderr);"
in front of what you added --- perhaps you should also add o
On 2019-Jul-22, Peter Eisentraut wrote:
> On 2019-07-09 11:43, Peter Eisentraut wrote:
> > After further research I'm thinking about dropping the libunwind
> > support. The backtrace()/backtrace_symbols() API is more widely
> > available: darwin, freebsd, linux, netbsd, openbsd (via port), solari
On 2019-Jul-22, Tom Lane wrote:
> I nearly missed the need for that because of all the noise that
> check-world emits in pre-v12 branches. We'd discussed back-patching
> eb9812f27 at the time, and I think now it's tested enough that doing
> so is low risk (or at least, lower risk than the risk of
On 7/22/19 3:15 PM, Tom Lane wrote:
> I wrote:
>> BTW, it looks like the Windows buildfarm critters have a
>> separate problem: they're failing with
>> initdb: error: must specify a password for the superuser to enable md5
>> authentication
> I tried doing a run on gaur (old HPUX, so no "peer" a
On 7/22/19 12:39 PM, Tom Lane wrote:
> I wrote:
>> I'm afraid we're going to have to revert this, at least till
>> such time as a fixed buildfarm client is in universal use.
>> As for the nature of that fix, I don't quite understand why
>> the forced -U is there --- maybe we could just remove it?
I wrote:
> BTW, it looks like the Windows buildfarm critters have a
> separate problem: they're failing with
> initdb: error: must specify a password for the superuser to enable md5
> authentication
I tried doing a run on gaur (old HPUX, so no "peer" auth) before the
revert happened. It got as f
I wrote:
> Here's a proposed patch for that. It's mostly pretty straightforward,
> except I had to add some recursion defenses in findDependentObjects that
> weren't there before. But those seem like a good idea anyway to prevent
> infinite recursion in case of bogus entries in pg_depend.
> Per a
On 2019-07-13 19:20, Fabien COELHO wrote:
> The second error message about conflicting option could more explicit than
> a terse "conflicting or redundant options"? The user may expect later
> options to superseedes earlier options, for instance.
done
> About the pg_dump code, I'm wondering whe
Peter Eisentraut writes:
> On 2019-07-18 00:45, Tom Lane wrote:
>> +1 for using the C11-standard name, even if that's not anywhere
>> in the real world yet.
> ISTM that a problem is that you cannot implement a replacement
> memset_s() as a wrapper around explicit_bzero(), unless you also want to
On 2019-07-09 11:43, Peter Eisentraut wrote:
> After further research I'm thinking about dropping the libunwind
> support. The backtrace()/backtrace_symbols() API is more widely
> available: darwin, freebsd, linux, netbsd, openbsd (via port), solaris,
> and of course it's built-in, whereas libunwi
On 2019-07-18 00:45, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2019-Jul-11, Thomas Munro wrote:
>>> Following a trail of crumbs beginning at OpenSSH's fallback
>>> implementation of this[1], I learned that C11 has standardised
>>> memset_s[2] for this purpose. Macs have memset_s but no
>>> e
On 2019-07-11 03:11, Michael Paquier wrote:
> On Mon, Jun 24, 2019 at 02:08:50PM +0900, Michael Paquier wrote:
>> CreateRole() and AlterRole() can manipulate a password in plain format
>> in memory. The cleanup could be done just after calling
>> encrypt_password() in user.c.
>>
>> Could it be pos
Alvaro Herrera writes:
> So with this patch we end up with:
> list_union (copies list1, appends list2 element not already in list1)
> list_concat_unique (appends list2 elements not already in list)
> list_concat (appends all list2 elements)
> list_concat_copy (copies list1, appends all list2 elem
On 2019-Jul-22, Tom Lane wrote:
> David Rowley writes:
> > If we do end up with another function, it might be nice to stay away
> > from using "concat" in the name. I think we might struggle if there
> > are too many variations on concat and there's a risk we'll use the
> > wrong one. If we nee
Hi,
On 7/21/19 9:48 PM, Michael Paquier wrote:
Since pg_receivewal does not apply WAL, you should not allow it to
become a synchronous standby when synchronous_commit = remote_apply.
If it does, it will appear to be a standby which never catches up,
which may cause commits to block. To avoid th
Hi,
On 7/22/19 1:44 AM, David Rowley wrote:
Here are the comments I noted down during the review:
cost_index:
I know you've not finished here, but I think it'll need to adjust
tuples_fetched somehow to account for estimate_num_groups() on the
Path's unique keys. Any Eclass with an ec_has_const
On 2019-Jul-22, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Jul-22, Julien Rouhaud wrote:
> >> On Mon, Jul 22, 2019 at 5:11 PM Alvaro Herrera
> >> wrote:
> >>> Can we use List for this instead?
>
> >> Isn't that for backend code only?
>
> > Well, we already have palloc() on the front
On 7/22/19 12:25 PM, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut writes:
>>> Pushed with that note. Thanks.
>> This has completely broken the buildfarm.
> On inspection, it seems the reason for that is that the buildfarm
> script runs initdb with '-U buildfarm', so that peer-auth connections
On 2019-Jul-22, Michael Paquier wrote:
> On Sat, Jul 20, 2019 at 10:04:19AM +0900, Michael Paquier wrote:
> > This restriction is unlikely going to be removed, still I would rather
> > keep the escaped logic in pg_basebackup. This is the usual,
> > recommended coding pattern, and there is a risk
I wrote:
> I'm afraid we're going to have to revert this, at least till
> such time as a fixed buildfarm client is in universal use.
> As for the nature of that fix, I don't quite understand why
> the forced -U is there --- maybe we could just remove it?
> But there are multiple places in the buil
On Mon, 2019-07-22 at 18:16 +0200, Tomas Vondra wrote:
> * I changed it to only update mem_allocated for the current
> > > context,
> > > not recursively for all parent contexts. It's now up to the
> > > function
> > > that reports memory usage to recurse or not (as needed).
> >
> > Is that OK for
I wrote:
> Peter Eisentraut writes:
>> Pushed with that note. Thanks.
> This has completely broken the buildfarm.
On inspection, it seems the reason for that is that the buildfarm
script runs initdb with '-U buildfarm', so that peer-auth connections
will only work if the buildfarm is being run
On Mon, Jul 22, 2019 at 11:30:37AM +0300, Heikki Linnakangas wrote:
On 18/07/2019 21:24, Jeff Davis wrote:
Previous discussion:
https://postgr.es/m/1407012053.15301.53.camel%40jeff-desktop
This patch introduces a way to ask a memory context how much memory it
currently has allocated. Each time
Alvaro Herrera writes:
> On 2019-Jul-22, Dagfinn Ilmari Mannsåker wrote:
>
>> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>>
>> > I noticed a lot of these are appending one StringInfo onto another;
>> > would it make sense to introduce a helper funciton
>> > appendStringInfoStringInfo(S
Alvaro Herrera writes:
> On 2019-Jul-22, Julien Rouhaud wrote:
>> On Mon, Jul 22, 2019 at 5:11 PM Alvaro Herrera
>> wrote:
>>> Can we use List for this instead?
>> Isn't that for backend code only?
> Well, we already have palloc() on the frontend side, and list.c doesn't
> have any elog()/erep
On 2019-Jul-22, Dagfinn Ilmari Mannsåker wrote:
> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>
> > I noticed a lot of these are appending one StringInfo onto another;
> > would it make sense to introduce a helper funciton
> > appendStringInfoStringInfo(StringInfo str, StringInfo str2) t
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> David Rowley writes:
>
>> On Thu, 4 Jul 2019 at 13:51, David Rowley
>> wrote:
>>> Instead of having 0004, how about the attached?
>>>
>>> Most of the calls won't improve much performance-wise since they're so
>>> cheap anyway, but there is
On 2019-Jul-22, Julien Rouhaud wrote:
> On Mon, Jul 22, 2019 at 5:11 PM Alvaro Herrera
> wrote:
> >
> > > I considered this, but it would require to adapt all code that declare
> > > SimpleStringList stack variable (vacuumdb.c, clusterdb.c,
> > > createuser.c, pg_dumpall.c and pg_dump.c), so it
On Mon, Jul 22, 2019 at 5:11 PM Alvaro Herrera wrote:
>
> On 2019-Jul-22, Julien Rouhaud wrote:
>
> > On Mon, Jul 22, 2019 at 6:11 AM Michael Paquier wrote:
>
> > >simple_string_list_append(&tables, optarg);
> > > + tbl_count++;
> > >break;
> > > The number of items in a simp
On 2019-Jul-19, Julien Rouhaud wrote:
> > For the second patch, could you send a rebase with a fix for the
> > connection slot when processing the reindex commands?
>
> Attached, I also hopefully removed all the now unneeded progname usage.
BTW "progname" is a global variable in logging.c, and i
On Fri, 19 Jul 2019 at 17:24, Amit Khandekar wrote:
>
> On Thu, 9 May 2019 at 12:04, Dilip Kumar wrote:
>
> > Patches can be applied on top of undo branch [1] commit:
> > (cb777466d008e656f03771cf16ec7ef9d6f2778b)
> >
> > [1] https://github.com/EnterpriseDB/zheap/tree/undo
>
> Below are some revi
On 2019-Jul-22, Julien Rouhaud wrote:
> On Mon, Jul 22, 2019 at 6:11 AM Michael Paquier wrote:
> >simple_string_list_append(&tables, optarg);
> > + tbl_count++;
> >break;
> > The number of items in a simple list is not counted, and vacuumdb does
> > the same thing to count o
On Mon, 22 Jul 2019 at 14:21, Amit Kapila wrote:
I have started review of
0014-Allow-execution-and-discard-of-undo-by-background-wo.patch. Below
are some quick comments to start with:
+++ b/src/backend/access/undo/undoworker.c
+#include "access/xact.h"
+#include "access/undorequest.h"
Order is
David Rowley writes:
> I looked over this and only noted down one thing:
> In estimate_path_cost_size, can you explain why list_concat_copy() is
> needed here? I don't see remote_param_join_conds being used after
> this, so might it be better to just get rid of remote_param_join_conds
> and pass
Peter Eisentraut writes:
> Pushed with that note. Thanks.
This has completely broken the buildfarm.
regards, tom lane
Hello Peter,
I'd go further and suggest that there shouldn't be a variable
controlling this. All results that come in should be processed, period.
I agree with that.
I kind of agree as well, but I was pretty sure that someone would complain
if the current behavior was changed.
Should I
David Rowley writes:
> On Thu, 4 Jul 2019 at 13:51, David Rowley
> wrote:
>> Instead of having 0004, how about the attached?
>>
>> Most of the calls won't improve much performance-wise since they're so
>> cheap anyway, but there is xmlconcat(), I imagine that should see some
>> speedup.
>
> I'v
On 2019-07-13 18:58, Julien Rouhaud wrote:
>>> The default client authentication setup is such that users can connect
>>> over the Unix-domain socket to the same database user name as their
>>> operating system user names (on operating systems that support this,
>>> which are most modern Unix-like
On 28/06/2019 01:02, Thomas Munro wrote:
On Thu, Jun 27, 2019 at 11:38 PM Heikki Linnakangas wrote:
* I moved the logic to extend a 32-bit XID to 64-bits to a new helper
function in varsup.c.
I'm a bit uneasy about making this into a generally available function
for reuse. I think we should
On Mon, Jul 22, 2019 at 6:29 AM Alvaro Herrera wrote:
> On 2019-Jul-21, Alexander Korotkov wrote:
> > I've one note. Behavior of "\dA" and "\dA pattern" look
> > counter-intuitive to me. I would rather expect that "\dA pattern"
> > would just filter results of "\dA", but it displays different
>
On Mon, Jul 22, 2019 at 6:11 AM Michael Paquier wrote:
>
> On Fri, Jul 19, 2019 at 08:29:27AM +0200, Julien Rouhaud wrote:
> > On Fri, Jul 19, 2019 at 2:35 AM Michael Paquier wrote:
> >> For the second patch, could you send a rebase with a fix for the
> >> connection slot when processing the rein
On Thu, 4 Jul 2019 at 13:51, David Rowley wrote:
> Instead of having 0004, how about the attached?
>
> Most of the calls won't improve much performance-wise since they're so
> cheap anyway, but there is xmlconcat(), I imagine that should see some
> speedup.
I've pushed this after having found a c
On 2019-07-10 09:51, Fabien COELHO wrote:
>> One approach for making the currently non-monospaced ones into monospace
>> would be to make the xref targets point to elements
>> but *don't* put xreflabels on those.
>
> I understand that you mean turning function usages:
>
>PQbla
>
> into:
>
Dear Surafel
Thank you for your check of my patch.
I’ve made the version 03 to
fix what you mentioned about my patch.
I corrected my wrong bracing styles and
also reduced the amount of my regression test.
Off course, I erased unnecessary
white spaces and the C++ style comment.
Regards,
On 2019-05-15 18:41, Daniel Verite wrote:
> I'd go further and suggest that there shouldn't be a variable
> controlling this. All results that come in should be processed, period.
I agree with that.
> It's not just about \; If the ability of CALL to produce multiple
> resultsets gets implemented
Hello hackers,
Here are the stats at the end of week 3 of the CF:
status | w1 | w2 | w3
+-+-+-
Committed | 32 | 41 | 49
Moved to next CF | 5 | 6 | 6
Needs review | 146 | 128 | 114
Ready for Committer
On Sat, Jul 20, 2019 at 11:28 AM Peter Geoghegan wrote:
> On Fri, Jul 19, 2019 at 4:14 PM Robert Haas wrote:
> > I don't think this matters here at all. As long as there's only DML
> > involved, there won't be any lock conflicts anyway - everybody's
> > taking RowExclusiveLock or less, and it's a
On Mon, 22 Jul 2019 at 12:48, Tsunakawa, Takayuki
wrote:
>
> From: David Rowley [mailto:david.row...@2ndquadrant.com]
> > I went back to the drawing board on this and I've added some code that
> > counts
> > the number of times we've seen the table to be oversized and just shrinks
> > the table b
On Mon, Jul 22, 2019 at 2:21 PM Amit Kapila wrote:
>
I have reviewed 0012-Infrastructure-to-execute-pending-undo-actions,
Please find my comment so far.
1.
+ /* It shouldn't be discarded. */
+ Assert(!UndoRecPtrIsDiscarded(xact_urp));
I think comments can be added to explain why it shouldn't be
On 2019-05-08 16:49, Laurenz Albe wrote:
> I believe we should have both:
>
> - Identity columns should only use sequences with an INTERNAL dependency,
> as in Peter's patch.
I have committed this.
> - When a column default is dropped, remove all dependencies between the
> column and sequenc
Hello.
At Mon, 22 Jul 2019 02:28:22 +, "Matsumura, Ryo"
wrote in
<03040DFF97E6E54E88D3BFEE5F5480F74AC15BBD@G01JPEXMBYT04>
> Hi
>
> # I rewrote my previous mail.
>
> PQconnectPoll() is used as method for asynchronous using externally or
> internally.
> If a caller confirms a socket ready
On Thu, Jul 18, 2019 at 4:41 PM Thomas Munro wrote:
>
> On Tue, Jul 16, 2019 at 8:39 AM Robert Haas wrote:
> > Thomas has already objected to another proposal to add functions that
> > turn 32-bit XIDs into 64-bit XIDs. Therefore, I feel confident in
> > predicting that he will likewise object t
On 2019-04-04 15:40, Daniel Gustafsson wrote:
> On Wednesday, March 27, 2019 1:43 PM, Christoph Berg wrote:
>
>> Re: Daniel Gustafsson 2019-03-26
>> pC-NMmh4vQLQP76YTwY4AuoD4OdNw9egikekyQpXFpgqmTlGjIZXOTd2W5RDZPpRski5N3ADRrLYgLk6QUuvmuT5fWC9acPAYyDU1AVxJcU=@yesql.se
>>
>>> 0003 - Make -B default
On Mon, 22 Jul 2019 at 08:01, Tom Lane wrote:
>
> I wrote:
> >> * Rationalize places that are using combinations of list_copy and
> >> list_concat, probably by inventing an additional list-concatenation
> >> primitive that modifies neither input.
>
> > I poked around to see what we have in this de
Hello.
# It's very good timing, as you came in while I have a time after
# finishing a quite nerve-wrackig task..
At Mon, 22 Jul 2019 15:02:16 +0900, Tatsuro Yamada
wrote in
<0876b4fe-26fb-ca32-f179-c696fa3dd...@nttcom.co.jp>
> >> 3785|13599|postgres|16384|f|16384|analyzing complete|0|0 <-- Ad
On 18/07/2019 21:24, Jeff Davis wrote:
Previous discussion:
https://postgr.es/m/1407012053.15301.53.camel%40jeff-desktop
This patch introduces a way to ask a memory context how much memory it
currently has allocated. Each time a new block (not an individual
chunk, but a new malloc'd block) is al
On Mon, Jul 22, 2019 at 04:01:46PM +0800, Peifeng Qiu wrote:
>> but it's really only a major issue for VS2019
>
> VS2019 will use the latest v10 SDK by default. So no need to install 8.1
> for VS2019.
Yes, FWIW, I have tested with VS2019 when committing 2b1394f, and in
this case only the v10 SDK g
> For VS2017, the 8.1 SDK is part of the optional package set
Yeah, if you install 8.1 SDK VS2017 can compile. I install VS2017 using the
GUI installer.
The main page are big checkboxs for packages sets like C++, .NET, Azure etc.
Checking C++ will only install the IDE and 10 SDK. 8.1 SDK is on the
On Mon, 22 Jul 2019 at 19:25, David Rowley
> On Sat, 20 Jul 2019 at 06:21, Andres Freund wrote:
> > Yea, I was thinking of something like 2. We already have a few extra
> > types of scan nodes (bitmap heap and sample scan), it'd not be bad to
> > add another. And as you say, they can just share
On Sat, Jul 20, 2019 at 10:04:19AM +0900, Michael Paquier wrote:
> This restriction is unlikely going to be removed, still I would rather
> keep the escaped logic in pg_basebackup. This is the usual,
> recommended coding pattern, and there is a risk that folks refer to
> this code block for their
On Sat, 20 Jul 2019 at 06:21, Andres Freund wrote:
>
> Hi,
>
> On 2019-07-19 13:54:59 +1200, David Rowley wrote:
> > Did you imagined two additional callbacks, 1 to set the TID range,
> > then one to scan it? Duplicating the logic in heapgettup_pagemode()
> > and heapgettup() looks pretty horribl
86 matches
Mail list logo
