On Mon, Jul 01, 2019 at 02:33:39PM +0300, Sergei Kornilov wrote:
> Updated version attached. Merge conflict was about tests count in
> 001_stream_rep.pl. Nothing else was changed. My approach can be
> still incorrect, any redesign ideas are welcome. Thanks in advance!
It has been some time, and
On Sun, 28 Jul 2019 at 03:15, Andres Freund wrote:
> 1) Just depend on DBD::Pg being installed. It's fairly common, after
>all. It'd be somewhat annoying that we'd often end up using a
>different version of libpq than what we're testing against. But in
>most cases that'd not be
On Tue, Jul 30, 2019 at 5:03 PM Dilip Kumar wrote:
> On Fri, Jul 19, 2019 at 2:28 PM Amit Kapila wrote:
> > On Thu, Jul 11, 2019 at 9:17 AM Dilip Kumar wrote:
> > > On Thu, Jul 11, 2019 at 12:38 AM Robert Haas
> > > wrote:
> > > > I don't like the fact that undoaccess.c has a new global,
> >
Hi Andres,
Sorry about the delay in replying as I was on vacation for the last few days.
On Sat, Jul 20, 2019 at 1:52 AM Andres Freund wrote:
> > The first one (0001) deals with reducing the core executor's reliance
> > on es_result_relation_info to access the currently active result
> >
On Mon, Jul 29, 2019 at 6:59 PM Dilip Kumar wrote:
> On Wed, Jul 17, 2019 at 2:39 PM Amit Langote wrote:
> > I've combined the two patches into one.
> Looks fine to me, moved to ready for committer.
Thank you Dilip.
Regards,
Amit
On Tue, Jul 30, 2019 at 12:21 PM Thomas Munro wrote:
>
> On Tue, Jul 30, 2019 at 5:03 PM Dilip Kumar wrote:
> >
> > I think this idea is good for the DO time but during REDO time it will
> > not work as we will not have the transaction state. Having said that
> > the current idea of keeping in
Hi Michael,
Thanks for your inputs, really appreciate.
On Tue, Jul 30, 2019 at 9:42 AM Michael Paquier wrote:
> On Mon, Jul 29, 2019 at 10:55:29PM +0530, Jeevan Ladhe wrote:
> > I am attaching a patch that makes sure that *have_error is set to false
> in
> > pg_lsn_in_internal() itself, rather
Hi,
Amit, short note: The patches aren't attached in patch order. Obviously
a miniscule thing, but still nicer if that's not the case.
Dilip, this also contains the start of a review for the undo record
interface further down.
On 2019-07-29 16:35:20 -0700, Andres Freund wrote:
>
Here we go.
On Tue, Jul 30, 2019 at 4:04 PM Michael Paquier wrote:
>
> On Tue, Jul 23, 2019 at 02:54:20PM +0800, Ning Yu wrote:
> > MakePGDirectory() is also called in TablespaceCreateDbspace(), EEXIST is
> > considered as non-error for parent directories, however as it considers
> > EEXIST as a failure for
Thanks Arthur! I guess there is not other solution? I tried to create a
function to loop through all the distance but its very slow.
On Tuesday, July 30, 2019, Arthur Zakirov wrote:
> Hello,
>
> On 23.07.2019 09:55, Wh isere wrote:
>
>> Is this possible with the current websearch_to_tsquery
On Mon, Jul 29, 2019 at 8:35 PM Bruce Momjian wrote:
> On Sun, Jul 28, 2019 at 10:33:03PM -0400, Bruce Momjian wrote:
> > I am thinking of writing some Assert() code that checks that all buffers
> > using a single LSN are from the same relation (and therefore different
> > page numbers). I
On Fri, Jul 19, 2019 at 8:09 PM amul sul wrote:
> On Mon, Jul 8, 2019 at 5:03 PM Etsuro Fujita wrote:
>> I started reviewing this. Here is my initial review comments:
>>
>> * 0001-Hash-partition-bound-equality-refactoring-v22.patch
>> However, I don't think it's a good idea to do this
>>
On 30.07.2019 4:02, Tomas Vondra wrote:
My idea (sorry if it wasn't too clear) was that we might handle some
cases more gracefully.
For example, if we only switch between transactions, we don't quite care
about 'SET LOCAL' (but the current patch does set the tainted flag). The
same thing
On Tue, Jul 23, 2019 at 02:54:20PM +0800, Ning Yu wrote:
> MakePGDirectory() is also called in TablespaceCreateDbspace(), EEXIST is
> considered as non-error for parent directories, however as it considers
> EEXIST as a failure for the last level of the path so the logic is
> still correct,
So
On 26.07.2019 23:24, Tomas Vondra wrote:
Secondly, when trying this
pgbench -p 5432 -U x -i -s 1 test
pgbench -p 6543 -U x -c 24 -C -T 10 test
it very quickly locks up, with plenty of non-granted locks in pg_locks,
but I don't see any interventions by deadlock detector so I presume
the
On Fri, Jul 19, 2019 at 10:44 PM Robert Haas wrote:
> On Thu, Jul 18, 2019 at 2:55 AM Etsuro Fujita wrote:
> > I.e., partition_bounds_merge() is performed for each pair of input
> > partitioned relations for a join relation in try_partitionwise_join().
> > Since partition_bounds_merge() would
Hi Amit
I've been testing some undo worker workloads (more on that soon), but
here's a small thing: I managed to reach an LWLock self-deadlock in
the undo worker launcher:
diff --git a/src/backend/access/undo/undorequest.c
b/src/backend/access/undo/undorequest.c
...
+bool
+UndoGetWork(bool
On Wed, Jun 12, 2019 at 10:58 AM Richard Guo wrote:
> Hi all,
>
> Paul and I have been hacking recently to implement parallel grouping
> sets, and here we have two implementations.
>
> Implementation 1
>
>
> Attached is the patch and also there is a github branch [1] for this
>
On Tue, Jul 30, 2019 at 03:50:32PM +0800, Richard Guo wrote:
On Wed, Jun 12, 2019 at 10:58 AM Richard Guo wrote:
Hi all,
Paul and I have been hacking recently to implement parallel grouping
sets, and here we have two implementations.
Implementation 1
Attached is the patch
> On 27 Jul 2019, at 08:42, Peter Eisentraut
> wrote:
> I have committed 0002, 0003, and 0004.
Thanks!
> The implementation in 0001 (Only allow upgrades by the same exact
> version new bindir) has a problem. It compares (new_cluster.bin_version
> != PG_VERSION_NUM), but
On Tue, Jul 30, 2019 at 8:16 AM Masahiko Sawada
wrote:
> On Mon, Jul 29, 2019 at 8:18 PM Sehrope Sarkuni
> wrote:
> >
> > On Mon, Jul 29, 2019 at 6:42 AM Masahiko Sawada
> wrote:
> > > > An argument could be made to push that problem upstream, i.e. let the
> > > > supplier of the passphrase
On Mon, Jul 29, 2019 at 8:18 PM Sehrope Sarkuni wrote:
>
> On Mon, Jul 29, 2019 at 6:42 AM Masahiko Sawada wrote:
> > > An argument could be made to push that problem upstream, i.e. let the
> > > supplier of the passphrase deal with the indirection. You would still
> > > need to verify the
On Tue, Jul 30, 2019 at 07:44:20AM -0400, Sehrope Sarkuni wrote:
> On Mon, Jul 29, 2019 at 8:35 PM Bruce Momjian wrote:
> From the patch:
>
> /*
> ! * The initialization vector (IV) is used for page-level
> ! * encryption. We use the LSN and page number as the IV, and IV
> ! * values must never
Craig Ringer writes:
> On Sun, 28 Jul 2019 at 03:15, Andres Freund wrote:
>> 1) Just depend on DBD::Pg being installed. It's fairly common, after
>> all. It'd be somewhat annoying that we'd often end up using a
>> different version of libpq than what we're testing against. But in
>> most cases
On Tue, Jul 30, 2019 at 8:16 AM Bruce Momjian wrote:
> On Tue, Jul 30, 2019 at 07:44:20AM -0400, Sehrope Sarkuni wrote:
> > If each relation file has its own derived key, the derived TDEK for that
> > relation file, then there is no issue with reusing the same IV = LSN ||
> Page
> > Number. The
Hi,
On 2019-07-30 09:40:54 -0400, Tom Lane wrote:
> Craig Ringer writes:
> > On Sun, 28 Jul 2019 at 03:15, Andres Freund wrote:
> >> 1) Just depend on DBD::Pg being installed. It's fairly common, after
> >> all. It'd be somewhat annoying that we'd often end up using a
> >> different version of
Andres Freund writes:
> On 2019-07-30 09:40:54 -0400, Tom Lane wrote:
>> Now, none of these things are really a problem with DBD/DBI as such
>> --- rather, they are reasons not to depend on a pre-packaged build
>> of DBD::Pg that depends on a pre-packaged build of libpq.so.
>> I haven't looked at
On Tue, Jul 30, 2019 at 1:28 AM Robert Haas wrote:
> On Wed, Jul 10, 2019 at 2:17 PM Anastasia Lubennikova
> wrote:
> > In attachments, you can find a prototype of incremental pg_basebackup,
> > which consists of 2 features:
> >
> > 1) To perform incremental backup one should call pg_basebackup
Hi Paul,
I have rebased the patch to master (1e2fddfa33d3c7cc93ca3ee0f32852699bd3e012)
and fixed some compilation warning. Now I am reviewing the actual code.
On Fri, Jul 26, 2019 at 6:35 PM Ibrar Ahmed wrote:
> The patch requires to rebase on the master branch.
>
> The new status of this
John Naylor 于2019年7月29日周一 上午11:49写道:
> On Thu, Jul 25, 2019 at 10:21 PM Binguo Bao wrote:
> My goal for this stage of review was to understand more fully what the
>
code is doing, and make it as simple and clear as possible, starting
> at the top level. In doing so, it looks like I found some
Thanks for reviewing!
At Thu, 27 Jun 2019 16:22:56 +0200, Jehan-Guillaume de Rorthais
wrote in <20190627162256.4f4872b8@firost>
> Hi all,
>
> Being interested by this feature, I did a patch review.
>
> This features adds the GUC "max_slot_wal_keep_size". This is the maximum
> amount
> of WAL
On Tue, Jul 30, 2019 at 01:01:48PM +0300, Konstantin Knizhnik wrote:
On 30.07.2019 4:02, Tomas Vondra wrote:
My idea (sorry if it wasn't too clear) was that we might handle some
cases more gracefully.
For example, if we only switch between transactions, we don't quite care
about 'SET LOCAL'
Robert Haas writes:
> On Mon, Jul 29, 2019 at 9:48 PM Tom Lane wrote:
>> I believe the only accessible route to taking any sort of new lock
>> in a parallel worker is catalog lookups causing AccessShareLock on
>> a catalog.
> Can't the worker just query a previously-untouched table, maybe by
>
On Tue, Jul 30, 2019 at 10:06 AM Masahiko Sawada
wrote:
> On Tue, Jul 30, 2019 at 5:03 AM Sehrope Sarkuni
> wrote:
> >
> > On Mon, Jul 29, 2019 at 9:44 AM Bruce Momjian wrote:
> >>
> >> > Checking that all buffers using a single LSN are from the same
> >> > relation would be a good idea but I
At Tue, 30 Jul 2019 21:30:45 +0900 (Tokyo Standard Time), Kyotaro Horiguchi
wrote in
<20190730.213045.221405075.horikyota@gmail.com>
> I attach the revised patch. I'll repost the polished version
> sooner.
(Mainly TAP test and documentation, code comments will be revised)
regards.
--
On Tue, Jul 30, 2019 at 4:52 AM Jeevan Ladhe
wrote:
> My only concern was something that we internally treat as invalid, why do
> we allow, that as a valid value for that type. While I am not trying to
> reinvent the wheel here, I am trying to understand if there had been any
> idea behind this
On Tue, Jul 30, 2019 at 5:03 AM Sehrope Sarkuni wrote:
>
> On Mon, Jul 29, 2019 at 9:44 AM Bruce Momjian wrote:
>>
>> > Checking that all buffers using a single LSN are from the same
>> > relation would be a good idea but I think it's hard to test it and
>> > regard the test result as okay. Even
Fabien COELHO writes:
> [ pgbench-strict-tpcb-2.patch ]
TBH, I think we should reject this patch. Nobody cares about TPC-B
anymore, and they care even less about differences between one
sort-of-TPC-B test and another sort-of-TPC-B test. (As the lack
of response on this thread shows.) We don't
David Rowley writes:
> The part I wouldn't mind another set of eyes on is the ruleutils.c
> changes.
Um, sorry for not getting to this sooner.
What I had in mind was to revert 1cc29fe7c's ruleutils changes
entirely, so that ruleutils deals only in Plans not PlanStates.
Perhaps we've grown some
David Rowley writes:
> On Wed, 31 Jul 2019 at 10:27, Tom Lane wrote:
>> What I had in mind was to revert 1cc29fe7c's ruleutils changes
>> entirely, so that ruleutils deals only in Plans not PlanStates.
>> Perhaps we've grown some code since then that really needs the
>> PlanStates, but what is
Robert Haas writes:
> Agreed, but I think we should just do nothing. To actually fix this
> in general, we'd have to get rid of every instance of MAXPGPATH in the
> source tree:
> [rhaas pgsql]$ git grep MAXPGPATH | wc -l
> 611
I don't think it'd really be necessary to go that far. One of
Tomas Vondra writes:
> I've started reviewing this patch, thinking that maybe I could get it
> committed as it's marked as RFC. In general I agree with having this
> fuature, but I think we need to rethink the GUC because the current
> approach is just confusing.
> ...
> What I think we should do
Hello,
Will my patch be considered for 12.0? The calculation of the mem_usage value
might be improved later on but because the system catalog is changed I would
love to add it before 12.0 becomes stable.
Regards,
Daniel Migowski
-Ursprüngliche Nachricht-
Von: Daniel Migowski
On Tue, Jul 30, 2019 at 02:43:05PM -0700, 毛瑞嘉 wrote:
> Hi,
>
>
> I wrote a patch for adding CORRESPONDING/CORRESPONDING BY to set operation.
> It is a task in the todo list. This is how the patch works:
>
> I modified transformSetOperationStmt() to get an intersection target list
> which is the
Ok, just have read about the commitfest thing. Is the patch OK for that? Or is
there generally no love for a mem_usage column here? If it was, I really would
add some memory monitoring in our app regarding this.
-Ursprüngliche Nachricht-
Von: Tom Lane
Gesendet: Mittwoch, 31. Juli 2019
Logs are important to diagnose problems or monitor operations, but logs
can contain sensitive information which is often unnecessary for these
purposes. Redacting the sensitive information would enable easier
access and simpler integration with analysis tools without compromising
the sensitive
On 12/07/2019 16:07, Julien Rouhaud wrote:
On Fri, Jun 14, 2019 at 5:40 PM Tom Lane wrote:
Heikki Linnakangas writes:
In the patch, I documented that rd_amcache must be allocated in
CacheMemoryContext, or in rd_indexcxt if it's an index. It works, but
it's a bit weird.
Given the way the
On Tue, Jul 30, 2019 at 10:14:14AM -0400, Sehrope Sarkuni wrote:
> > In general it's fine to use the same IV with different keys. Only reuse
> of Key
> > + IV is a problem and the entire set of possible counter values (IV + 0,
> IV +
> > 1, ...) generated with a key must be
On Tue, Jul 30, 2019 at 03:43:58PM -0400, Tom Lane wrote:
Tomas Vondra writes:
I've started reviewing this patch, thinking that maybe I could get it
committed as it's marked as RFC. In general I agree with having this
fuature, but I think we need to rethink the GUC because the current
approach
On Tue, Jul 30, 2019 at 10:01:09PM +, Daniel Migowski wrote:
Hello,
Will my patch be considered for 12.0? The calculation of the mem_usage
value might be improved later on but because the system catalog is
changed I would love to add it before 12.0 becomes stable.
Nope. Code freeze for
Daniel Migowski writes:
> Ok, just have read about the commitfest thing. Is the patch OK for that? Or
> is there generally no love for a mem_usage column here? If it was, I really
> would add some memory monitoring in our app regarding this.
You should certainly put it into the next
Am 31.07.2019 um 00:29 schrieb Tom Lane:
Daniel Migowski writes:
Ok, just have read about the commitfest thing. Is the patch OK for that? Or is
there generally no love for a mem_usage column here? If it was, I really would
add some memory monitoring in our app regarding this.
You should
"osumi.takami...@fujitsu.com" writes:
> [ CREATE_OR_REPLACE_TRIGGER_v03.patch ]
I took a quick look through this just to see what was going on.
A few comments:
* Upthread you asked about changing the lock level to be
AccessExclusiveLock if the trigger already exists, but the patch doesn't
Hi,
I wrote a patch for adding CORRESPONDING/CORRESPONDING BY to set operation.
It is a task in the todo list. This is how the patch works:
I modified transformSetOperationStmt() to get an intersection target list
which is the intersection of the target lists of the left clause and right
Am 31.07.2019 um 00:17 schrieb Tomas Vondra:
FWIW not sure what mail client you're using, but it seems to be breaking
the threads for some reason, splitting it into two - see [1].
Also, please stop top-posting. It makes it way harder to follow the
discussion.
Was using Outlook because it's my
On Wed, 31 Jul 2019 at 10:27, Tom Lane wrote:
>
> David Rowley writes:
> > The part I wouldn't mind another set of eyes on is the ruleutils.c
> > changes.
>
> Um, sorry for not getting to this sooner.
>
> What I had in mind was to revert 1cc29fe7c's ruleutils changes
> entirely, so that
On Sat, Jul 27, 2019 at 2:22 AM Peter Eisentraut
wrote:
> I think if you want to make this more robust, get rid of the fixed-size
> array, use dynamic allocation with PQExpBuffer, and let the operating
> system complain if it doesn't like the directory name length.
Agreed, but I think we should
On Tue, Jul 16, 2019 at 10:22 AM Andres Freund wrote:
> Hi,
>
> On 2019-07-11 17:27:46 -0700, Ashwin Agrawal wrote:
> > Please find attached the patch to remove IndexBuildCallback's dependency
> on
> > HeapTuple, as discussed. Changed to have the argument as ItemPointer
> > instead of HeapTuple.
My 0.02 €
It seems entirely crazy that encode() and decode() are no longer in the
same section, likewise that convert_from() and convert_to() aren't
documented together anymore.
Awkward, yes. But findable if you know what the categories are.
I suppose there could be 3 different
On Tue, Jun 25, 2019 at 6:02 AM Andres Freund wrote:
> On 2019-06-24 10:41:06 -0700, Ashwin Agrawal wrote:
> > Proposing following changes to make predicate locking and checking
> > functions generic and remove dependency on HeapTuple and Heap AM. We
> > made these changes to help with Zedstore.
Daniel Migowski writes:
> Will my patch be considered for 12.0? The calculation of the mem_usage value
> might be improved later on but because the system catalog is changed I would
> love to add it before 12.0 becomes stable.
v12 has been feature-frozen for months, and it's pretty hard to
I wrote:
> This may be arguing for a change in ruleutils' existing behavior,
> not sure. But when dealing with traditional-style inheritance,
> I've always thought that Vars above the Append were referring to
> the parent rel in its capacity as the parent, not in its capacity
> as the first
Takuma Hoshiai writes:
> [ fix_to_reg_v2.patch ]
I took a quick look through this patch. I'm on board with the goal
of not having schema-access violations throw an error in these
functions, but the implementation feels pretty ugly and bolted-on.
Nobody who had designed the code to do this from
So, I've rewritten the patch to use a BufFile for the outer table
batch file tuples' match statuses and write bytes to and from the file
which start as 0 and, upon encountering a match for a tuple, I set its
bit in the file to 1 (also rebased with current master).
It, of course, only works for
On Tue, Jul 30, 2019 at 1:36 PM Tom Lane wrote:
> No, there's a sufficient reason why we should force advisory locks
> to be taken in the leader process, namely that the behavior is totally
> different if we don't: they will disappear at the end of the parallel
> worker run, not at end of
On 2019-Jul-30, Tom Lane wrote:
> OK, so just lifting DBD::Pg in toto is out for license reasons.
> However, maybe we could consider writing a new DBD driver from
> scratch (while using a platform-provided DBI layer) rather than
> doing everything from scratch. I'm not sure how much actual
>
"Karl O. Pinc" writes:
> On Mon, 15 Jul 2019 23:00:55 +0200 (CEST)
> Fabien COELHO wrote:
>> The patch clarifies the documentation about encode/decode and other
>> text/binary string conversion functions.
> Other notable changes:
> Corrects categorization of functions as string or binary.
>
On Tue, Jul 2, 2019 at 9:53 PM Amit Langote wrote:
> Thanks for the report. This seems like a bug. Documentation claims
> that the child tables inherit column storage options from the parent
> table. That's actually enforced in only some cases.
I realize I'm just repeating the same argument
On Tue, Jul 30, 2019 at 10:27 AM Tom Lane wrote:
> I also looked into whether one could use SELECT FOR UPDATE/SHARE to get
> stronger locks at a tuple level, but that's been blocked off as well.
> You guys really did a pretty good job of locking that down.
Thanks. We learned from the master.
>
Robert Haas writes:
> On Tue, Jul 30, 2019 at 10:27 AM Tom Lane wrote:
>> (BTW, why aren't these functions just "parallel restricted"?)
> ...
> But it is really pretty arguable whether we should feel responsible
> for that problem. We could just decide that if you're doing that, and
> you
Robert Haas writes:
> On Tue, Jul 30, 2019 at 1:36 PM Tom Lane wrote:
>> In any case, my question at the moment is whether we need the belt-and-
>> suspenders-too approach of having both non-parallel-safe marking and an
>> explicit check inside these functions. We've largely moved away from
>>
On Mon, Jul 29, 2019 at 12:18:33PM +0200, Tomas Vondra wrote:
On Sun, Jul 28, 2019 at 09:53:20PM -0700, Andres Freund wrote:
Hi,
On 2019-07-28 21:21:51 +0200, Tomas Vondra wrote:
AFAICS it applies to 10+ versions, because that's where extended stats
were introduced. We certainly can't mess
On Thu, Jul 18, 2019 at 9:45 AM Tom Lane wrote:
> I think this is going in the wrong direction. Nodes should *always*
> assume that a rescan is possible until ExecEndNode is called.
> If you want to do otherwise, you are going to be inventing a whole
> bunch of complicated and
Hi,
In contrib/pgcrypto/pgp.c we have a struct member int_name in digest_info which
isn’t used, and seems to have never been used (a potential copy/pasteo from the
cipher_info struct?). Is there a reason for keeping this, or can it be removed
as per the attached?
cheers ./daniel
Hi,
I've occasionally wished for a typesafe version of pg_printf() and other
varargs functions. The compiler warnings are nice, but also far from
complete.
Here's a somewhat crazy hack/prototype for how printf could get actual
argument types. I'm far from certain it's worth pursuing this
Alexander Lakhin writes:
> 01.07.2019 13:47, Thomas Munro wrote:
>> A new CF is here and this is in "Needs Review". Would you like to
>> provide a rebased patch, or should it really be withdrawn?
> The rebased patch is attached, but I still can't find anyone interested
> in reviewing it.
> So
Marc Cousin writes:
> By the way, while preparing this, I noticed that it seems that during this
> kind of index scan, the interrupt signal is masked
> for a very long time. Control-C takes a very long while to cancel the query.
> But it's an entirely different problem :)
Yeah, that seems like
On Tue, Jul 30, 2019 at 1:44 PM Tom Lane wrote:
> Well, there'd be an actual isolation test that they work ;-), if you
> override the marking. Admittedly, one test case does not prove that
> there's no way to crash the system, but that can be said of most
> parts of Postgres.
True. I'm just
Robert Haas writes:
> On Tue, Jul 30, 2019 at 1:44 PM Tom Lane wrote:
>> Well, there'd be an actual isolation test that they work ;-), if you
>> override the marking. Admittedly, one test case does not prove that
>> there's no way to crash the system, but that can be said of most
>> parts of
On Tue, 30 Jul 2019 11:40:03 -0400
Tom Lane wrote:
> "Karl O. Pinc" writes:
> > On Mon, 15 Jul 2019 23:00:55 +0200 (CEST)
> > Fabien COELHO wrote:
> >> The patch clarifies the documentation about encode/decode and
> >> other text/binary string conversion functions.
>
> > Other notable
On Tue, Jul 30, 2019 at 03:30:12PM -0400, Tom Lane wrote:
> On the whole though, I don't have a problem with the "do nothing"
> answer. There's no security risk here, and no issue that seems
> likely to arise in actual use cases rather than try-to-break-it
> test scripts.
+1.
--
Michael
On Wed, Jul 31, 2019 at 8:31 AM Tom Lane wrote:
> David Rowley writes:
> > On Wed, 31 Jul 2019 at 10:56, Tom Lane wrote:
> >> The portion of this below the Append is fine, but I argue that
> >> the Vars above the Append should say "part", not "part_p1".
> >> In that way they'd look the same
On Tue, Jul 30, 2019 at 07:20:53PM -0700, Andres Freund wrote:
> IDK, a minimal driver that just does what we need it to do is a few
> hundred lines, not more. And there's plenty of stuff that we simply
> won't be able to test with any driver that's not purposefully written
> for testing. There's
On Wed, 31 Jul 2019 at 10:20, Andres Freund wrote:
> Hi,
>
> On 2019-07-31 09:32:10 +0800, Craig Ringer wrote:
> > OK. So rather than building our own $everything from scratch, lets look
> at
> > solving that.
>
> IDK, a minimal driver that just does what we need it to do is a few
> hundred
On Tue, Jul 30, 2019 at 2:47 PM Melanie Plageman
wrote:
> I did the "needlessly dumb implementation" Robert mentioned, though,
> I thought about it and couldn't come up with a much smarter way to
> write match bits to a file. I think there might be an optimization
> opportunity in not writing the
On Tue, Jul 30, 2019 at 06:22:59PM +0800, Ning Yu wrote:
> In fact personally I'm thinking that whether could we replace all uses of
> MakePGDirectory() with pg_mkdir_p(), so we could simplify
> TablespaceCreateDbspace() and PathNameCreateTemporaryDir() and other callers
> significantly.
I would
On Tue, Jul 30, 2019 at 9:19 PM Daniel Gustafsson wrote:
>
> Hi,
>
> In contrib/pgcrypto/pgp.c we have a struct member int_name in digest_info
> which
> isn’t used, and seems to have never been used (a potential copy/pasteo from
> the
> cipher_info struct?). Is there a reason for keeping this,
David Rowley writes:
> On Wed, 31 Jul 2019 at 10:56, Tom Lane wrote:
>> The portion of this below the Append is fine, but I argue that
>> the Vars above the Append should say "part", not "part_p1".
>> In that way they'd look the same regardless of which partitions
>> have been pruned or not.
>
On Tue, Jul 30, 2019 at 03:43:58PM -0400, Tom Lane wrote:
> Well, we do not need to have a backwards-compatibility problem
> here, because we have yet to release a version containing
> log_statement_sample_rate. I do not think it's too late to decide
> that v12's semantics for that are broken,
On Tue, Jul 30, 2019 at 8:07 PM Melanie Plageman
wrote:
> For the actual write to disk, I'm pretty sure I get that for free from
> the BufFile API, no?
> I was more thinking about optimizing when I call BufFileWrite at all.
Right. Clearly several existing buffile.c users regularly have very
Hello,
When we add a new path using add_path(), it checks estimated cost and path-keys,
then it also removes dominated paths, if any.
Do we have a reasonable way to retain these "dominated" paths? Once it
is considered
lesser paths at a level, however, it may have a combined cheaper cost
with
Hi,
On 2019-07-18 16:17:22 +0800, Ning Yu wrote:
> This seems buggy as it first checks the existence of the dir and makes the
> dir if it does not exist yet, however when executing concurrently a
> possible race condition can be as below:
>
> A: does a/ exists? no
> B: does a/ exists? no
> A:
Amit Kapila writes:
> On Wed, Jul 31, 2019 at 12:05 AM Robert Haas wrote:
>> The other option is to do
>> what I understand Amit and Thomas to be proposing, which is to do a
>> better job identifying the case where we're "done for good" and can
>> trigger the shutdown fearlessly.
> Yes, this
On Wed, Jul 31, 2019 at 12:41 PM Michael Paquier wrote:
>
> On Wed, Jul 31, 2019 at 12:26:30PM +0800, Ning Yu wrote:
> > Could I double confirm with you that you made a clean rebuild after
> > applying the patches? pg_mkdir_p() is compiled as part of libpgport.a,
> > and the postgres makefile
On Tue, Jul 30, 2019 at 09:11:44PM -0700, Andres Freund wrote:
> Hm. I'm not really seing much of a point in making mkdir_p safe against
> all of this. What's the scenario for pg where this matters? I assume
> you're using it for somewhat different purposes, and that's why it is
> problematic for
On Tue, Jul 30, 2019 at 3:00 PM Tom Lane wrote:
> TBH, I think we should reject this patch. Nobody cares about TPC-B
> anymore, and they care even less about differences between one
> sort-of-TPC-B test and another sort-of-TPC-B test. (As the lack
> of response on this thread shows.) We don't
On Wed, Jul 31, 2019 at 2:38 AM Robert Haas wrote:
>
> On Tue, Jul 2, 2019 at 9:53 PM Amit Langote wrote:
> > Thanks for the report. This seems like a bug. Documentation claims
> > that the child tables inherit column storage options from the parent
> > table. That's actually enforced in only
On Tue, Jul 30, 2019 at 02:22:30PM +0530, Jeevan Ladhe wrote:
> On Tue, Jul 30, 2019 at 9:42 AM Michael Paquier wrote:
>> Agreed about making the code more defensive as you do. I would keep
>> the initialization in check_recovery_target_lsn and pg_lsn_in_internal
>> though. That does not hurt
Hi,
On 2019-07-31 09:32:10 +0800, Craig Ringer wrote:
> OK. So rather than building our own $everything from scratch, lets look at
> solving that.
IDK, a minimal driver that just does what we need it to do is a few
hundred lines, not more. And there's plenty of stuff that we simply
won't be able
On Tue, Jul 30, 2019 at 4:36 PM Robert Haas wrote:
> On Tue, Jul 30, 2019 at 2:47 PM Melanie Plageman
> wrote:
> > I did the "needlessly dumb implementation" Robert mentioned, though,
> > I thought about it and couldn't come up with a much smarter way to
> > write match bits to a file. I think
1 - 100 of 118 matches
Mail list logo