Hi,
On 2019-07-31 11:19:08 +0530, vignesh C wrote:
> I noticed that there are many header files being
> included which need not be included.
> I have tried this in a few files and found the
> compilation and regression to be working.
> I have attached the patch for the files that
> I tried.
> I tr
On Wed, Jul 31, 2019 at 11:55:37AM +0530, Amit Kapila wrote:
> If we can come up with some such tool, we might be able to integrate
> it with Thomas's patch tester [1] wherein it can apply the patch,
> verify if there are unnecessary includes in the patch and report the
> same.
>
> [1] - http://co
On Wed, Jul 31, 2019 at 11:55 AM Amit Kapila wrote:
>
> On Wed, Jul 31, 2019 at 11:31 AM vignesh C wrote:
> >
> > On Wed, Jul 31, 2019 at 11:26 AM Michael Paquier
> > wrote:
> > >
> > > On Wed, Jul 31, 2019 at 11:19:08AM +0530, vignesh C wrote:
> > > > I noticed that there are many header files
On Mon, Jul 29, 2019 at 10:44 PM Bruce Momjian wrote:
>
> On Mon, Jul 29, 2019 at 08:43:06PM +0900, Masahiko Sawada 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)
On Wed, Jul 31, 2019 at 11:31 AM vignesh C wrote:
>
> On Wed, Jul 31, 2019 at 11:26 AM Michael Paquier wrote:
> >
> > On Wed, Jul 31, 2019 at 11:19:08AM +0530, vignesh C wrote:
> > > I noticed that there are many header files being included which need
> > > not be included. I have tried this in
On Wed, Jul 31, 2019 at 02:02:03PM +0800, Ning Yu wrote:
> Yes, in current postgres source code there are several wrappers of
> mkdir() that do similar jobs. If we could have a safe mkdir_p()
> implementation then we could use it directly in all these wrappers, that
> could save a lot of maintenan
On Wed, Jul 31, 2019 at 1:31 PM Michael Paquier wrote:
>
> On Tue, Jul 30, 2019 at 10:19:45PM -0700, Andres Freund wrote:
> > I don't really have a problem fixing this case if we think it's
> > useful. But I'm a bit bothered by all the "fixes" being submitted that
> > don't matter for PG itself. T
On Wed, Jul 31, 2019 at 11:26 AM Michael Paquier wrote:
>
> On Wed, Jul 31, 2019 at 11:19:08AM +0530, vignesh C wrote:
> > I noticed that there are many header files being included which need
> > not be included. I have tried this in a few files and found the
> > compilation and regression to be
On Wed, Jul 31, 2019 at 11:19:08AM +0530, vignesh C wrote:
> I noticed that there are many header files being included which need
> not be included. I have tried this in a few files and found the
> compilation and regression to be working. I have attached the patch
> for the files that I tried.
On Tue, 30 Jul 2019 12:24:13 -0400
Tom Lane wrote:
> 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
Hi,
I noticed that there are many header files being
included which need not be included.
I have tried this in a few files and found the
compilation and regression to be working.
I have attached the patch for the files that
I tried.
I tried this in CentOS, I did not find the header
files to be pla
On Tue, Jul 30, 2019 at 6:00 PM Etsuro Fujita wrote:
> 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
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,
On Tue, Jul 30, 2019 at 10:19:45PM -0700, Andres Freund wrote:
> I don't really have a problem fixing this case if we think it's
> useful. But I'm a bit bothered by all the "fixes" being submitted that
> don't matter for PG itself. They do eat up resources.
Sure. In this particular case, we can s
Hi,
On 2019-07-31 13:48:23 +0900, Michael Paquier wrote:
> 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 som
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 lines
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 wil
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 y
On Tue, Jul 30, 2019 at 5:26 PM Thomas Munro wrote:
>
> Hi Amit
>
> I've been testing some undo worker workloads (more on that soon),
>
One small point, there is one small bug in the error queues which is
that the element pushed into error queue doesn't have an updated value
of to_urec_ptr which
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 will not relink the initdb binary
> automatically, for myself I must '
On Wed, Jul 31, 2019 at 12:11 PM Andres Freund wrote:
>
> 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 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 sou
On Wed, Jul 31, 2019 at 12:04 PM Michael Paquier wrote:
>
> 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 PathNam
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 e
On Tue, Jul 30, 2019 at 1:32 PM Andres Freund wrote:
>
> 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.
>
Noted, I will try to ensure that patches are in order in future posts.
--
With Regards,
Amit Ka
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: try
On Wed, Jul 31, 2019 at 12:05 AM Robert Haas wrote:
>
> 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 i
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 s
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 uppe
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
small
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 t
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 rega
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 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
signatu
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, and
On Tue, Jul 30, 2019 at 04:44:11PM -0400, Tom Lane wrote:
> We do not test \h output in any existing regression test, and we're
> not going to start doing so in this one. For one thing, the expected
> URL would break every time we forked off a new release branch.
> (There would surely be value in
On Tue, 30 Jul 2019 at 21:40, 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 libp
On Tue, Jul 30, 2019 at 05:48:49PM +0200, Daniel Gustafsson wrote:
> 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, o
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 an
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 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.
Feature freeze
Peter Geoghegan writes:
> On Tue, Jul 30, 2019 at 3:00 PM Tom Lane wrote:
>> I'm also highly dubious about labeling this script "standard TPC-B",
>> when it resolves only some of the reasons why our traditional script
>> is not really TPC-B. That's treading on being false advertising.
> IANAL,
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 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 n
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.
> T
On Wed, 31 Jul 2019 at 10:56, Tom Lane wrote:
>
> OK, so experimenting, I see that it is a change: HEAD does
>
> regression=# explain verbose select * from part order by a;
>QUERY PLAN
> ---
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 child.
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 th
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 ce
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 ruleutils
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
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 commitfest.
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 c
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 PG
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
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 pai
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
Gesende
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
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. I
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
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 categories:
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
clause
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 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.
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 uniq
"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
actual
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
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
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 pat
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 info
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 j
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 par
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
> func
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 doubtless-initially
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 chan
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
further
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 wit
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 Pos
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 tal
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
>> h
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 transact
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 I'
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 don't
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
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 le
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.
>
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 t
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
pgcrypto_int_
"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 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 new_cluster.bin_versio
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 a
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
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 l
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
> c
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 t
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 T
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
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 dea
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 th
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
1 - 100 of 123 matches
Mail list logo
