Hi
> The default should always be to shrink, unless either the VACUUM
> option or the reloption turn that off. (So it doesn't make sense to set
> either the VACUUM option or the reloption to "on").
I think VACUUM option can be set to "on" by hand in order to override reloption
only for this
On 2019/02/27 18:37, Dean Rasheed wrote:
> On Tue, 12 Feb 2019 at 10:33, Dean Rasheed wrote:
>> Here's an updated patch ...
>
> So I pushed that. However, ...
>
> Playing around with it some more, I realised that whilst this appeared
> to fix the reported problem, it exposes another issue which
On Thu, Feb 28, 2019 at 5:37 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Thu, Feb 28, 2019 at 7:08 PM Tom Lane wrote:
> >> I agree that smgrtype as it stands is pretty pointless, but what
> >> will we be using instead to get to those other implementations?
>
> > Our current thinking is
On Thu, Feb 28, 2019 at 7:37 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Thu, Feb 28, 2019 at 7:08 PM Tom Lane wrote:
> >> I agree that smgrtype as it stands is pretty pointless, but what
> >> will we be using instead to get to those other implementations?
>
> > Our current thinking is
Alvaro Herrera wrote:
> I think we should have a VACUUM option and a reloption, but no
> GUC. The default should always be to shrink, unless either the VACUUM
> option or the reloption turn that off. (So it doesn't make sense to set
> either the VACUUM option or the reloption to "on").
+1
Hello
postgresql.conf.sample was changed recently in REL_10_STABLE (commit
ab1d9f066aee4f9b81abde6136771debe0191ae8)
So config will be changed in next minor release anyway. We have another reason
to not fix bgwriter_lru_maxpages comment?
regards, Sergei
Thomas Munro writes:
> On Thu, Feb 28, 2019 at 7:08 PM Tom Lane wrote:
>> I agree that smgrtype as it stands is pretty pointless, but what
>> will we be using instead to get to those other implementations?
> Our current thinking is that smgropen() should know how to map a small
> number of
Andrew Gierth writes:
> To get a reliable measurement of timing changes less than around 3%,
> what you have to do is this: pick some irrelevant function and add
> something like an asm directive that inserts a variable number of NOPs,
> and do a series of test runs with different values.
Good
On Thu, Feb 28, 2019 at 7:08 PM Tom Lane wrote:
> Thomas Munro writes:
> > Motivation: A couple of projects propose to add new smgr
> > implementations alongside md.c in order to use bufmgr.c for more kinds
> > of files, but it seems entirely bogus to extend the unused smgr type
> > to cover
Dear Michael, Chris and Tom,
> Adding special cases to extensions strikes me as adding more
> funny corners to the behavior of the db in this regard.
I understand your arguments and its utility.
> For most of extensions, this can randomly finish with strange error
> messages, say that:
> =#
Thomas Munro writes:
> Motivation: A couple of projects propose to add new smgr
> implementations alongside md.c in order to use bufmgr.c for more kinds
> of files, but it seems entirely bogus to extend the unused smgr type
> to cover those.
I agree that smgrtype as it stands is pretty
Hello hackers,
The type smgr has only one value 'magnetic disk'. ~15 years ago it
also had a value 'main memory', and in Berkeley POSTGRES 4.2 there was
a third value 'sony jukebox'. Back then, all tables had an associated
block storage manager, and it was recorded as an attribute relsmgr of
Alvaro Herrera writes:
> Hopefully we'll get Tom's patch that addresses the failure-to-truncate
> issues in pg12.
Hm, are you speaking of the handwaving I did in
https://www.postgresql.org/message-id/2348.1544474...@sss.pgh.pa.us
?
I wasn't really working on that for v12 --- I figured it was
> "David" == David Rowley writes:
David> I went and had a few adventures with this patch to see if I
David> could figure out why the small ~1% regression exists.
Just changing the number of instructions (even in a completely unrelated
place that's not called during the test) can generate
David Rowley writes:
> I went and had a few adventures with this patch to see if I could
> figure out why the small ~1% regression exists.
Thanks for poking around!
> ... I had
> suspected it was the lcons() calls being expensive because then need
> to push the elements up one place each time,
Hi Alvaro,
I looked at the latest patch and most of the issues/bugs that I was going
to report based on the late January version of the patch seem to have been
taken care of; sorry that I couldn't post sooner which would've saved you
some time. The patch needs to be rebased on top of ff11e7f4b9
On 2019-Feb-28, Tsunakawa, Takayuki wrote:
> From: Michael Paquier [mailto:mich...@paquier.xyz]
> > So we could you consider adding an option for the VACUUM command as well
> > as vacuumdb? The interactions with the current patch is that you need to
> > define the behavior at the beginning of
On Tue, 26 Feb 2019 at 18:34, Tom Lane wrote:
>
> David Rowley writes:
> > Using the attached patch (as text file so as not to upset the CFbot),
> > which basically just measures and logs the time taken to run
> > pg_plan_query. ...
> > Surprisingly it took 1.13% longer. I did these tests on an
On Thu, Feb 28, 2019 at 10:25 AM Amit Kapila wrote:
>
> Here's an updated patch based on comments by you. I will proceed with
> this unless you have any more comments.
Looks good to me. I would just adjust the grammar in the comment, from
"This prevents us to use the map", to "This prevents us
David Rowley writes:
> On Thu, 28 Feb 2019 at 09:26, Tom Lane wrote:
>> 0002 below does this. I'm having a hard time deciding whether this
>> part is a good idea or just code churn. It might be more readable
>> (especially to newbies) but I can't evaluate that very objectively.
> I'm less
On Thu, 28 Feb 2019 at 09:26, Tom Lane wrote:
>
> I wrote:
> > I did find a number of places where getting rid of explicit lnext()
> > calls led to just plain cleaner code. Most of these were places that
> > could be using forboth() or forthree() and just weren't. There's
> > also several
Peter Eisentraut writes:
> On 2019-02-27 22:27, Tom Lane wrote:
>>> OID collision doesn't seem to be a significant problem (for me).
>> Um, I beg to differ. It's not at all unusual for pending patches to
>> bit-rot for no reason other than suddenly getting an OID conflict.
>> I don't have to
From: Michael Paquier [mailto:mich...@paquier.xyz]
> So we could you consider adding an option for the VACUUM command as well
> as vacuumdb? The interactions with the current patch is that you need to
> define the behavior at the beginning of vacuum for a given heap, instead
> of reading the
On Wed, Feb 27, 2019 at 03:37:23PM -0300, Alvaro Herrera wrote:
> It should have listed t2 too, but it doesn't. Since these functions
> aren't supposed to work on legacy inheritance anyway, I think the right
> action is to return the empty set. In the current version I just do
> what
On Thu, Feb 28, 2019 at 8:10 AM Amit Kapila wrote:
>
> On Thu, Feb 28, 2019 at 7:45 AM John Naylor
> wrote:
> >
> > On Thu, Feb 28, 2019 at 7:24 AM Amit Kapila wrote:
> > > > The flaw in my thinking was treating extension too similarly too
> > > > finding an existing block. With your patch
On Tue, Feb 26, 2019 at 01:25:29PM -0500, Tom Lane wrote:
> Since my commits 9e138a401 et al on Saturday, buildfarm members
> blobfish, brotula, and wunderpus have been showing core dumps
> in the ecpg preprocessor. This seemed inexplicable given what
> the commits changed, and even more so
Hi,
I rewrote two TCP_USER_TIMEOUT patches.
I changed the third argument of setsockopt() from 18 to TCP_USER_TIMEOUT.
This revision has the following two merits.
* Improve readability of source
* Even if the definition of TCP_USER_TIMEOUT is changed, it is not affected.
e.g., in the current
Hi,
On Tue, Feb 19, 2019 at 8:20 PM, Euler Taveira wrote:
> Em seg, 18 de fev de 2019 às 19:21, Tom Lane escreveu:
> >
> > Euler Taveira writes:
> > > Since no one has stepped up, I took a stab at it. It will prohibit
> > > standard output unless '-f -' be specified. -l option also has the
> >
On Thu, Feb 28, 2019 at 7:45 AM John Naylor wrote:
>
> On Thu, Feb 28, 2019 at 7:24 AM Amit Kapila wrote:
> > > The flaw in my thinking was treating extension too similarly too
> > > finding an existing block. With your patch clearing the local map in
> > > the correct place, it seems the call
Paul Ramsey writes:
> I added three indexes to my test table:
> CREATE INDEX foo_g_gist_x ON foo USING GIST (g);
> CREATE INDEX foo_g_gist_nd_x ON foo USING GIST (g gist_geometry_ops);
> CREATE INDEX foo_g_spgist_x ON foo USING SPGIST (g);
> They all support the overlaps (&&) operator.
>
On Thu, Feb 28, 2019 at 01:05:07AM +, Tsunakawa, Takayuki wrote:
> From: Robert Haas [mailto:robertmh...@gmail.com]
>> I don't think that a VACUUM option would be out of place, but a GUC
>> sounds like an attractive nuisance to me. It will encourage people to
>> just flip it blindly instead
Hi,
On 2019/02/28 10:45, Michael Paquier wrote:
> On Wed, Feb 27, 2019 at 03:48:08PM -0300, Alvaro Herrera wrote:
>> I just happened to come across the result of this rationale in
>> pg_partition_tree() (an SRF) while developing a new related function,
>> pg_partition_ancestors(), and find the
On Thu, Feb 28, 2019 at 7:24 AM Amit Kapila wrote:
> > The flaw in my thinking was treating extension too similarly too
> > finding an existing block. With your patch clearing the local map in
> > the correct place, it seems the call at hio.c:682 is now superfluous?
>
> What if get some valid
On Mon, Feb 25, 2019 at 06:38:16PM +0300, Konstantin Knizhnik wrote:
> Small issue with readir implementation for Windows.
> Right now it returns ENOENT in case of any error returned by FindFirstFile.
> So all places in Postgres where opendir/listdir are used will assume that
> directory is empty
From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
> I measured the memory context accounting overhead using Tomas's tool
> palloc_bench,
> which he made it a while ago in the similar discussion.
> https://www.postgresql.org/message-id/53f7e83c.3020...@fuzzy.cz
>
> This tool is a
On Wed, Feb 27, 2019 at 12:02:43PM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
>> I think we should save such a patch for whenever we next update the
>> archive version number, which could take a couple of years given past
>> history. I'm inclined to add a comment near K_VERS_SELF to remind
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> Attached are the updated patches.
Thanks, all look fixed.
> The target_server_type option yet to be implemented.
Please let me review once more and proceed to testing when the above is added,
to make sure the final code looks good. I'd
On Wed, Feb 27, 2019 at 03:48:08PM -0300, Alvaro Herrera wrote:
> I just happened to come across the result of this rationale in
> pg_partition_tree() (an SRF) while developing a new related function,
> pg_partition_ancestors(), and find the resulting behavior rather absurd
> -- it returns one row
From: Robert Haas [mailto:robertmh...@gmail.com]
> I don't think that a VACUUM option would be out of place, but a GUC
> sounds like an attractive nuisance to me. It will encourage people to
> just flip it blindly instead of considering the particular cases where
> they need that behavior, and I
If you are trying to get around the issue for now, what my team did was
cron an insert statement on the database server. We have a queue table that
has some of these triggers setup so it was easy to write a no-op row to the
queue. This had the side effect of flushing the notification queue.
We
On Wed, Feb 27, 2019 at 07:45:11PM -0500, Joe Conway wrote:
> It seems to me that OpenTransientFile() is more appropriate. Patch done
> that way attached.
Works for me, thanks for sending a patch! While on it, could you
clean up the comment on top of get_controlfile()? "char" is mentioned
On Wed, Feb 27, 2019 at 11:50:17AM +0100, Fabien COELHO wrote:
>> Shouldn't be necessary - the control file fits into a single page, and
>> writes of that size ought to always be atomic. And I also think
>> introducing flock usage for this would be quite disproportional.
There are static
Hi,
On 2019-02-27 11:50:17 +0100, Fabien COELHO wrote:
> Note that my concern is not about the page size, but rather that as more
> commands may change the cluster status by editing the control file, it would
> be better that a postmaster does not start while a pg_rewind or enable
> checksum or
From: Michael Paquier [mailto:mich...@paquier.xyz]
> This makes the test page-size sensitive. While we don't ensure that tests
> can be run with different page sizes, we should make a maximum effort to
> keep the tests compatible if that's easy enough. In this case you could
> just use > 0 as
On 2/27/19 10:26 AM, Joe Conway wrote:
> On 2/27/19 2:47 AM, Michael Paquier wrote:
>> Hi all,
>> (CC-ing Joe as of dc7d70e)
> According to that comment BasicOpenFile does not seem to solve the issue
> you are pointing out (leaking of file descriptor on ERROR). Perhaps
> OpenTransientFile() is
On Wed, Feb 27, 2019 at 11:07 AM John Naylor
wrote:
>
> On Wed, Feb 27, 2019 at 5:06 AM Amit Kapila wrote:
> > I have tried this test many times (more than 1000 times) by varying
> > thread count, but couldn't reproduce it. My colleague, Kuntal has
> > tried a similar test overnight, but the
> On Feb 27, 2019, at 3:40 PM, Tom Lane wrote:
>
>> Variable SupportRequestCost is very exciting, but given that variable cost
>> is usually driven by the complexity of arguments, what kind of argument is
>> the SupportRequestCost call fed during the planning stage? Constant
>> arguments
Paul Ramsey writes:
> The documentation says that a support function should have a signature
> "supportfn(internal) returns internal”, but doesn’t say which (if any)
> annotations should be provided. IMMUTABLE? PARALLEL SAFE? STRICT? None? All?
It doesn't matter much given that these things
Thanks Kumar. actually I was asking what the the cursor did in the
server. By looking the code, looks it cache the previous Portal with the
name is the cursor name, whenever we run the fetch from the portal, it
will restore the previous Portal and run it.
But your minimized and interactive
On 2019-Feb-05, Jerry Jelinek wrote:
> First, since last fall, we have found another performance problem related
> to initializing WAL files. I've described this issue in more detail below,
> but in order to handle this new problem, I decided to generalize the patch
> so the tunable refers to
A few more questions…
The documentation says that a support function should have a signature
"supportfn(internal) returns internal”, but doesn’t say which (if any)
annotations should be provided. IMMUTABLE? PARALLEL SAFE? STRICT? None? All?
Variable SupportRequestCost is very exciting, but
On 2/20/19 11:24 AM, Tom Lane wrote:
> Pierre Ducroquet writes:
>> For simple functions like enum_eq/enum_ne, marking them leakproof is an
>> obvious fix (patch attached to this email, including also textin/textout).
>
> This is not nearly as "obvious" as you think. See prior discussions,
>
Peter Geoghegan writes:
> On Wed, Feb 27, 2019 at 2:44 PM Peter Eisentraut
> wrote:
>> If this is the problem (although I think we'd find that OID collisions
>> are rather rare compared to other gratuitous cfbot failures), why not
>> have the cfbot build with a flag that ignores OID collisions?
On Wed, Feb 27, 2019 at 2:44 PM Peter Eisentraut
wrote:
> If this is the problem (although I think we'd find that OID collisions
> are rather rare compared to other gratuitous cfbot failures), why not
> have the cfbot build with a flag that ignores OID collisions?
How would that work?
--
Peter
On 2019-02-27 22:50, Peter Geoghegan wrote:
> However, the continuous
> integration stuff has created an expectation that your patch shouldn't
> be left to bitrot for long. Silly mechanical bitrot now seems like a
> much bigger problem than it was before these developments. It unfairly
> puts
On Wed, Feb 27, 2019 at 2:39 PM Peter Eisentraut
wrote:
> The changes of a patch (a) allocating a new OID, (b) a second patch
> allocating a new OID, (c) both being in flight at the same time, (d)
> actually picking the same OID, are small.
But...they are. Most patches don't create new system
On 2019-02-27 22:27, Tom Lane wrote:
>> OID collision doesn't seem to be a significant problem (for me).
>
> Um, I beg to differ. It's not at all unusual for pending patches to
> bit-rot for no reason other than suddenly getting an OID conflict.
> I don't have to look far for a current example:
Peter Geoghegan writes:
> On Wed, Feb 27, 2019 at 1:27 PM Tom Lane wrote:
>>> OID collision doesn't seem to be a significant problem (for me).
>> Um, I beg to differ. It's not at all unusual for pending patches to
>> bit-rot for no reason other than suddenly getting an OID conflict.
>> I don't
I wrote:
> We do need a couple of pieces of new infrastructure to make this idea
> conveniently workable. One is a tool to allow automatic OID renumbering
> instead of having to do it by hand; Naylor has a draft for that upthread.
Oh: arguably, something else we'd need to do to ensure that OID
On Wed, Feb 27, 2019 at 1:27 PM Tom Lane wrote:
> > OID collision doesn't seem to be a significant problem (for me).
>
> Um, I beg to differ. It's not at all unusual for pending patches to
> bit-rot for no reason other than suddenly getting an OID conflict.
> I don't have to look far for a
On Thu, Feb 28, 2019 at 10:27 AM Shawn Debnath wrote:
> We had a quick offline discussion to get on the same page and we agreed
> to move forward with Andres' approach above. Attached is patch v10.
> Here's the overview of the patch:
Thanks. I will review, and try to rebase my undo patches on
On 2019-Feb-27, Tom Lane wrote:
> I'm particularly unsure about whether we need two macros; though the
> way I initially tried it with just list_cell_is_last() seemed kind of
> double-negatively confusing in the places where the test needs to be
> not-last. Also, are these macro names too long,
Peter Eisentraut writes:
> On 2019-02-08 19:14, Tom Lane wrote:
>> Quite a few people have used OIDs up around 8000 or 9000 for this purpose;
>> I doubt we need a formally reserved range for it. The main problem with
>> doing it is the hazard that the patch'll get committed just like that,
>>
Robert Haas writes:
> On Wed, Feb 27, 2019 at 3:27 PM Tom Lane wrote:
>> 0001 below does this. I found a couple of places that could use
>> forfive(), as well. I think this is a clear legibility and
>> error-proofing win, and we should just push it.
> It sounds like some of these places might
On Wed, Feb 27, 2019 at 3:27 PM Tom Lane wrote:
> 0001 below does this. I found a couple of places that could use
> forfive(), as well. I think this is a clear legibility and
> error-proofing win, and we should just push it.
It sounds like some of these places might need a bigger restructuring
Hi,
On 2015-05-12 14:24:34 -0400, Tom Lane wrote:
> I did a very basic update of your postgres_fdw patch to test this with,
> and attach that so that you don't have to repeat the effort. I'm not sure
> whether we want to try to convert that into something committable. I'm
> afraid that the
I wrote:
> I did find a number of places where getting rid of explicit lnext()
> calls led to just plain cleaner code. Most of these were places that
> could be using forboth() or forthree() and just weren't. There's
> also several places that are crying out for a forfour() macro, so
> I'm not
Tomas Vondra writes:
> On 2/27/19 6:36 AM, Markus Winand wrote:
> On 27.02.2019, at 00:22, Tom Lane wrote:
>>> For example, given a filter condition like "1.0/c > 0.1", people
>>> would complain if it still got zero-divide failures even after they'd
>>> deleted all rows with c=0 from their
On 2019-Feb-27, Michael Paquier wrote:
> On Tue, Feb 26, 2019 at 07:27:57PM -0300, Alvaro Herrera wrote:
> > Thanks for committing pg_partition_root ... but it turns out to be
> > useless for this purpose.
>
> Well, what's done is done. The thing is useful by itself in my
> opinion.
Eh, of
On 2018-Dec-09, Tom Lane wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> ... especially in code that's highly unlikely to break once written.
>
> > I don't entirely buy off on the argument that it's code that's 'highly
> > unlikely to break once written' though-
> On Feb 26, 2019, at 11:38, Magnus Hagander wrote:
> That should not be a wiki page, really, that should be part of the main
> documentation.
I was just suggesting using a wiki page to draft it before we drop it into the
main documentation. I'm open to other suggestions, of course!
--
On Fri, Feb 15, 2019 at 08:57:04AM -0600, Justin Pryzby wrote:
> I propose that the prepared statement associated with an EXECUTE should be
> included in log "DETAIL" only when log_error_verbosity=VERBOSE, for both SQL
> EXECUTE and PQexecPrepared (if at all). I'd like to be able to continue
>
On 2/27/19, 2:08 AM, "Masahiko Sawada" wrote:
>> + if (skip_index_vacuum)
>> + appendStringInfo(, ngettext("%.0f tuple is left as
>> dead.\n",
>> +
>>"%.0f tuples are left as dead.\n",
>> +
On Thu, Feb 14, 2019 at 5:17 AM Masahiko Sawada wrote:
> Thank you. Attached the rebased patch.
Here are some review comments.
+ started by a single utility command. Currently, the parallel
+ utility commands that support the use of parallel workers are
+ CREATE INDEX
On 2/27/19 6:36 AM, Markus Winand wrote:
>
>
>> On 27.02.2019, at 00:22, Tom Lane wrote:
>>
>> Markus Winand writes:
>>> I think Bitmap Index Scan should take advantage of B-tree INCLUDE columns,
>>> which it doesn’t at the moment (tested on master as of yesterday).
>>
>> Regular index
On 2019-02-26 19:06, Mike Palmiotto wrote:
> The desired effect would be to have `SELECT * from test.partpar;`
> return check only the partitions where username can see any row in the
> table based on column b. This is applicable, for instance, when a
> partition of test.partpar (say
Hi,
On 2019-02-27 18:00:12 +0800, Heikki Linnakangas wrote:
> I haven't been following this thread closely, but I looked briefly at some
> of the patches posted here:
Thanks!
> On 21/01/2019 11:01, Andres Freund wrote:
> > The patchset is now pretty granularly split into individual pieces.
>
> On Wed, Feb 27, 2019 at 1:32 PM Alvaro Herrera
> wrote:
>
> > > I think it would be better to just put back the .defn = "" (etc) to the
> > > ArchiveEntry calls.
> >
> > Then we should do this not only for defn, but for owner and dropStmt too.
>
> Yeah, absolutely.
Done, please find the
Alvaro Herrera writes:
> On 2019-Feb-27, Dmitry Dolgov wrote:
>> But I hope there are no objections if I'll then submit the original
>> changes with more consistent null handling separately to make decision
>> about them more consciously.
> I think we should save such a patch for whenever we
Markus Winand writes:
>> On 27.02.2019, at 02:00, Justin Pryzby wrote:
>> On Tue, Feb 26, 2019 at 09:07:01PM +0100, Markus Winand wrote:
>>> (As a side node: I also dislike it how Bitmap Index Scan mixes search
>>> conditions and filters in “Index Cond”)
>> I don't think it's mixing them;
Hello Andrey,
we would like to see ICU collations become the default for entire
databases as well. Therefore we would also review the patch.
Unfortunately your Patch from late October does not apply on the current
master.
Besides of that I noticed the patch applies on master of October but
On Mon, Feb 25, 2019 at 4:25 AM Michael Paquier wrote:
> Another thing that seems worth thinking about is a system-level GUC,
> and an option in the VACUUM command to control if truncation should
> happen or not. We have a lot of infrastructure to control such
> options between vacuum and
On Tue, Feb 26, 2019 at 7:26 AM Etsuro Fujita
wrote:
> The parallel safety of the final scan/join target is determined from the
> grouping target, not that target, which [ is wrong ]
OOPS. That's pretty embarrassing.
Your patch looks right to me. I will now go look for a bag to put over my
On Wed, Feb 27, 2019 at 7:46 AM Etsuro Fujita
wrote:
> Yet another thing I noticed while working on [1] is this in
> grouping_planner:
>
> /*
> * If the input rel is marked consider_parallel and there's nothing
> that's
> * not parallel-safe in the LIMIT clause, then the final_rel
On Tue, Feb 26, 2019 at 5:44 PM Thomas Munro wrote:
> Then perhaps we could do some more involved surgery on master that
> achieves smart shutdown's stated goal here, and lets parallel queries
> actually run? Better ideas welcome.
I have noticed before that the smart shutdown code does not
On Wed, Feb 27, 2019 at 4:42 PM Andy Fan wrote:
>
> actually I'm hacking pg for a function like :
> 1. define a select query.
> 2. client ask for some data. and server reply some data. server will do
> NOTHING if client doesn't ask any more..
> 3. client ask some data more data with a batch
On 2/27/19 2:47 AM, Michael Paquier wrote:
> Hi all,
> (CC-ing Joe as of dc7d70e)
>
> I was just looking at the offline checksum patch, and noticed some
> sloppy coding in controldata_utils.c. The control file gets opened in
> get_controlfile(), and if it generates an error then the file
>
On Tue, Feb 26, 2019 at 1:06 PM Mike Palmiotto
wrote:
>
> On Tue, Feb 26, 2019 at 1:55 AM Tsunakawa, Takayuki
> wrote:
> >
> > From: Mike Palmiotto [mailto:mike.palmio...@crunchydata.com]
> > > Attached is a patch which attempts to solve a few problems:
Updated patch attached.
> > >
> > What
Originally bug was reported by Yuri Kurenkov:
https://github.com/postgrespro/pg_probackup/issues/48
As pg_probackup rely on readdir() for listing files to backup, wrong
permissions could lead to a broken backup.
On 02/25/2019 06:38 PM, Konstantin Knizhnik wrote:
Hi hackers,
Small issue with
Hi,
I got a failure in pg_dump/pg_restore as below:
pg_dump/pg_restore fails with 'ERROR: schema "public" already exists' for
TAR_DUMP and CUSTOM_DUMP from v94/v95/v96 to v11/master.
-- Take pg_dump in v94/v95/v96:
[prabhat@localhost bin]$ ./pg_dump -f /tmp/*tar_dump_PG94.tar* -Ft postgres
-p
Hi,
Yet another thing I noticed while working on [1] is this in
grouping_planner:
/*
* If the input rel is marked consider_parallel and there's nothing
that's
* not parallel-safe in the LIMIT clause, then the final_rel can be
marked
* consider_parallel as well. Note that if
On 2019-Feb-27, Dmitry Dolgov wrote:
> > On Tue, Feb 26, 2019 at 11:53 PM Alvaro Herrera
> > wrote:
> >
> > I think it would be better to just put back the .defn = "" (etc) to the
> > ArchiveEntry calls.
>
> Then we should do this not only for defn, but for owner and dropStmt too.
Yeah,
actually I'm hacking pg for a function like :
1. define a select query.
2. client ask for some data. and server reply some data. server will do
NOTHING if client doesn't ask any more..
3. client ask some data more data with a batch and SERVER reply some data
then. then do NOTHING.
currently the
Thanks you Andres for your time! this context is free with AllocSetReset
rather than AllocSetDelete, that makes my breakpoint doesn't catch it.
On Wed, Feb 27, 2019 at 2:15 PM Andres Freund wrote:
> On 2019-02-27 14:08:47 +0800, Andy Fan wrote:
> > Hi :
> > I run a query like "select * from
However, while at it, there is also the question of whether the control file
should be locked when updated, eg with flock(2) to avoid race conditions
between concurrent commands. ISTM that there is currently not such thing in
the code, but that it would be desirable.
Shouldn't be necessary -
On Wed, Feb 27, 2019 at 10:02 AM Bossart, Nathan wrote:
>
> Sorry for the delay. I finally got a chance to look through the
> latest patches.
>
> On 2/3/19, 1:48 PM, "Masahiko Sawada" wrote:
> > On Fri, Feb 1, 2019 at 11:43 PM Bossart, Nathan wrote:
> >>
> >> + if
On 2019-02-21 01:36, Euler Taveira wrote:
>> By default, the fallback_application_name for a physical walreceiver is
>> "walreceiver". This means that multiple standbys cannot be
>> distinguished easily on a primary, for example in pg_stat_activity or
>> synchronous_standby_names.
>>
> Although
I haven't been following this thread closely, but I looked briefly at
some of the patches posted here:
On 21/01/2019 11:01, Andres Freund wrote:
The patchset is now pretty granularly split into individual pieces.
Wow, 42 patches, very granular indeed! That's nice for reviewing, but
are you
On 2019-02-08 19:14, Tom Lane wrote:
> Quite a few people have used OIDs up around 8000 or 9000 for this purpose;
> I doubt we need a formally reserved range for it. The main problem with
> doing it is the hazard that the patch'll get committed just like that,
> suddenly breaking things for
(2019/02/26 21:25), Etsuro Fujita wrote:
> While working on [1], I noticed $Subject, that is:
>
> /*
> * If we have grouping or aggregation to do, the topmost scan/join
> * plan node must emit what the grouping step wants; otherwise, it
> * should emit
1 - 100 of 107 matches
Mail list logo
