On Mon, Dec 9, 2019 at 2:37 PM Amit Kapila wrote:
>
> On Mon, Dec 9, 2019 at 2:27 PM Amit Kapila wrote:
> >
> > I have modified the patch for the above points and additionally ran
> > pgindent. Let me know what you think about the attached patch?
> >
>
> A new version with a slightly modified co
On Sun, Dec 8, 2019 at 10:27 PM Tom Lane wrote:
>
> I wrote:
> > So, just idly looking at the code in src/backend/port/win32/signal.c
> > and src/port/kill.c, I have to wonder why we have this baroque-looking
> > design of using *two* signal management threads. And, if I'm
> > reading it right, w
On Mon, Dec 9, 2019 at 3:08 PM amul sul wrote:
> Attached is the rebase version atop the latest master head(2d0fdfaccec).
>
>
Hi Fujita san,
I have been through your changes proposed in [1] -- the changes make sense
to me &
I didn't see any unobvious behaviour in testing as well.
Regards,
Amul
Thanks for the new version.
At Sun, 8 Dec 2019 04:03:01 +0300, Grigory Smolkin
wrote in
> On 11/21/19 1:46 PM, Peter Eisentraut wrote:
> > On 2019-11-08 05:00, Grigory Smolkin wrote:
> I`ve tested it and have some thoughts/concerns:
>
> 1. Recovery should report the exact reason why it has bee
út 10. 12. 2019 v 0:03 odesílatel Karl O. Pinc napsal:
> On Mon, 9 Dec 2019 21:04:21 +0100
> Pavel Stehule wrote:
>
> > I fixed almost all mentioned issues (that I understand)
>
> If you don't understand you might ask, or at least say.
> That way I know you've noticed my remarks and I don't
> ha
Jerry Sievers writes:
> I suspect this was due to indcheckxmin=true for the involved index and
> the documented (but IMO confusing) interplay w/broken hot-chains and
> visibility.
Yeah. The reported behavior can mostly be explained if we assume
that there's some HOT chain in the table that invol
Peter Geoghegan writes:
> On Mon, Dec 9, 2019 at 6:33 PM Michael Paquier wrote:
>
>> Something new as of 11 is that btree indexes can be built in parallel,
>> and before releasing it we found some bugs with covering indexes.
>> Perhaps we have an issue hidden behind one of these, but hard to be
On Tue, Dec 10, 2019 at 9:52 AM Amit Kapila wrote:
>
> On Mon, Dec 2, 2019 at 2:02 PM Dilip Kumar wrote:
> >
> > On Sun, Dec 1, 2019 at 7:58 AM Michael Paquier wrote:
> > >
> > > On Fri, Nov 22, 2019 at 01:18:11PM +0530, Dilip Kumar wrote:
> > > > I have rebased the patch on the latest head and
On Mon, Dec 2, 2019 at 2:02 PM Dilip Kumar wrote:
>
> On Sun, Dec 1, 2019 at 7:58 AM Michael Paquier wrote:
> >
> > On Fri, Nov 22, 2019 at 01:18:11PM +0530, Dilip Kumar wrote:
> > > I have rebased the patch on the latest head and also fix the issue of
> > > "concurrent abort handling of the (sub
On Mon, Dec 9, 2019 at 6:33 PM Michael Paquier wrote:
> Something new as of 11 is that btree indexes can be built in parallel,
> and before releasing it we found some bugs with covering indexes.
> Perhaps we have an issue hidden behind one of these, but hard to be
> sure.
I doubt it.
Jeremy did
On Fri, Dec 6, 2019 at 8:33 PM Noah Misch wrote:
> On Fri, Dec 06, 2019 at 07:56:08PM +1300, Thomas Munro wrote:
> > On Fri, Dec 6, 2019 at 7:34 PM Noah Misch wrote:
> > > We use system UTF-16 collation to implement UTF-8 collation on Windows.
> > > The
> > > PostgreSQL security team received a
On Mon, Dec 09, 2019 at 03:51:39PM -0500, Jeff Janes wrote:
> On Mon, Dec 9, 2019 at 1:00 PM Jeremy Finzel wrote:
>> I have a table with about 7 million records. I had a query in which I
>> needed 2 indexes added, one for a created timestamp field another for an id
>> field; both very high cardin
On Mon, Dec 09, 2019 at 07:02:43PM +0100, Julien Rouhaud wrote:
> On Mon, Dec 9, 2019 at 5:21 PM Robert Haas wrote:
>> Some people might prefer notices, because you can get those while the
>> thing is still running, rather than a result set, which you will only
>> see when the query finishes. Othe
Hi,
I several times, most recently for the record format in the undo
patchset, wished for a fast variable width integer implementation for
postgres. Using very narrow integers, for space efficiency, solves the
space usage problem, but leads to extensibility / generality problems.
Other cases wher
On 12/9/19 2:00 PM, Tomas Vondra wrote:
These look good to me. I added extra tests (not included in this email)
to verify the code on more interesting test cases, such as partitioned
tables and within joins. Your test cases are pretty trivial, just being
selects from a single table.
Addin
At Tue, 10 Dec 2019 00:44:09 +0100, Tomas Vondra
wrote in
> Hi,
>
> I think there's a minor bug in pg_stat_activity tracking of walsender
> processes. The issue is that xact_start is only updated at the very
> beginning when the walsender starts (so it's almost exactly equal to
> backend_start)
> On 9 Dec 2019, at 16:42, Robert Haas wrote:
> On Fri, Dec 6, 2019 at 12:17 PM Andres Freund wrote:
I've read through the patchset and played around with it to try and break it
and understand it (not in that order). Being a bit out of my comfort zone, I
can't offer the deep insights that Andre
Hi,
On 2019-12-10 00:44:09 +0100, Tomas Vondra wrote:
> I think there's a minor bug in pg_stat_activity tracking of walsender
> processes. The issue is that xact_start is only updated at the very
> beginning when the walsender starts (so it's almost exactly equal to
> backend_start) and then just
Hi,
I think there's a minor bug in pg_stat_activity tracking of walsender
processes. The issue is that xact_start is only updated at the very
beginning when the walsender starts (so it's almost exactly equal to
backend_start) and then just flips between NULL and that value.
Reproducing this is t
On Mon, Dec 09, 2019 at 05:40:40PM -0500, Tom Lane wrote:
Tomas Vondra writes:
... Perhaps a path-specific struct, referenced
from the path and built only with verbose explain would be fine?
How would that work, given that the planner doesn't know whether its
output is going to get explained?
On Mon, Dec 09, 2019 at 05:27:01PM -0500, Greg Stark wrote:
On Mon, 9 Dec 2019 at 17:14, Tomas Vondra wrote:
On Sat, Dec 07, 2019 at 11:34:12AM -0500, Tom Lane wrote:
>Justin Pryzby writes:
>> Jeff said:
>>> |What would I find very useful is a verbosity option to get the cost
>>> |estimates e
On Mon, 9 Dec 2019 21:04:21 +0100
Pavel Stehule wrote:
> I fixed almost all mentioned issues (that I understand)
If you don't understand you might ask, or at least say.
That way I know you've noticed my remarks and I don't
have to repeat them.
I have 2 remaining suggestions.
1) As previously s
Tomas Vondra writes:
> ... Perhaps a path-specific struct, referenced
> from the path and built only with verbose explain would be fine?
How would that work, given that the planner doesn't know whether its
output is going to get explained? With features like the plan cache
and auto_explain in mi
Peter Eisentraut writes:
> Per discussion in [0], here is a patch set to remove support for Python
> versions older than 2.6.
I took a brief look through this and it seems reasonable. Two
minor comments:
* In the docs section beginning "Context managers syntax using the with
keyword", could we
On Mon, 9 Dec 2019 at 17:14, Tomas Vondra wrote:
>
> On Sat, Dec 07, 2019 at 11:34:12AM -0500, Tom Lane wrote:
> >Justin Pryzby writes:
> >> Jeff said:
> >>> |What would I find very useful is a verbosity option to get the cost
> >>> |estimates expressed as a multiplier of each *_cost parameter, r
Peter Eisentraut writes:
> There appear to be several off-by-more-than-one errors in norm_test.c
> print_wchar_str(). Attached is a patch to fix this (and make the output
> a bit prettier). Result afterwards:
I concur that this looks broken and your patch improves it.
But I'm not very happy a
On Sat, Dec 07, 2019 at 11:34:12AM -0500, Tom Lane wrote:
Justin Pryzby writes:
Jeff said:
|What would I find very useful is a verbosity option to get the cost
|estimates expressed as a multiplier of each *_cost parameter, rather than
|just as a scalar.
It seems to me that's "just" a matter
Alvaro Herrera writes:
> We have a not-consistently-used convention that names in CamelCase are
> used for global variables. Naming a function parameter in that style
> seems pointlessly confusing. I would rather use redorecptr as Tom
> suggested, which fits with the style used for the other arg
Hi,
today I observed (on a r5.24xlarge AWS RDS instance, i.e. 96 logical
cores) lock contention on a buffer content lock due to taking of a
SHARED lock (I think):
Three tables were involved, simplified case:
CREATE TABLE global_config (id BIGINT PRIMARY KEY);
CREATE TABLE b (
id BIGINT PRIMAR
On 2019-Dec-09, Ranier Vilela wrote:
> --- a/src/backend/access/transam/xlogreader.c
> +++ b/src/backend/access/transam/xlogreader.c
> @@ -70,7 +70,7 @@ report_invalid_record(XLogReaderState *state, const char
> *fmt,...)
> * Returns NULL if the xlogreader couldn't be allocated.
> */
> XLogR
On Mon, Dec 09, 2019 at 11:56:39AM -0800, Mark Dilger wrote:
On 12/5/19 9:51 AM, Tomas Vondra wrote:
On Thu, Dec 05, 2019 at 06:15:54PM +0100, Tomas Vondra wrote:
On Sun, Dec 01, 2019 at 08:08:58PM +0100, Tomas Vondra wrote:
On Sat, Nov 30, 2019 at 03:01:31PM -0800, Mark Dilger wrote:
Are
On 2019-Dec-09, Kyotaro Horiguchi wrote:
> > >BTW, if we do go forward with changing the RedoRecPtr uses, I'm not
> > >in love with "XRedoRecPtr" as a replacement parameter name; it conveys
> > >nothing much, and the "X" prefix is already overused in that area of
> > >the code. Perhaps "pRedoRec
Andres Freund writes:
> On 2019-12-09 11:59:23 -0500, Robert Haas wrote:
>> On Mon, Dec 9, 2019 at 11:48 AM Tom Lane wrote:
>>> The only thing I think is really a substantial bug risk here is your
>>> point about our own macros referencing our own global variables.
>>> We might be better off fixi
On Mon, 9 Dec 2019 at 14:03, Ibrar Ahmed wrote:
> I'd
> actually argue that the segment size should be substantially smaller
> than 1 GB, like say 64MB; there are still some people running systems
> which are small enough that allocating 1 GB when we may need only 6
> bytes can drive the system in
Greg Stark writes:
> On Mon, 9 Dec 2019 at 15:17, Tom Lane wrote:
>> Meh ... people will inevitably complain that they needed to see the
>> whole value, and we'll end up having to add another configuration
>> variable. Let's not go there just yet.
> I haven't been following this whole thread bu
Hi,
On 2019-12-09 11:59:23 -0500, Robert Haas wrote:
> On Mon, Dec 9, 2019 at 11:48 AM Tom Lane wrote:
> > I think it depends a lot on the particular identifiers in use. You
> > mentioned examples like "i" and "lc", and I'd add other obviously
> > nonce variable names like "oldcxt". I'm not part
On Mon, 9 Dec 2019 at 15:17, Tom Lane wrote:
>
> Meh ... people will inevitably complain that they needed to see the
> whole value, and we'll end up having to add another configuration
> variable. Let's not go there just yet.
I haven't been following this whole thread but my initial reaction is
Alvaro Herrera writes:
> The stuff about truncating to N chars was of my own devising. If we
> don't want truncation in log_parameters_on_error either, we could do
> away with the stringinfo changes altogether. (I stand by my opinion
> that we should truncate, but if there are contrary votes I'm
Alvaro Herrera writes:
> The API is different in each case: if we want it available in frontend,
> we need to pass the encoding as a parameter rather than use
> GetDatabaseEncoding().
Hm, yeah, so that's another reason we aren't going to be sharing this
code exactly with frontend. Given that, dr
On 2019-Dec-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > Also:
> > * v18 and v19 now alwys do a "strlen(s)", i.e. they scan the whole input
> > string -- pointless when maxlen is given. We could avoid that for
> > very large input strings by doing strnlen(maxlen + MAX_MULTIBYTE_CHAR_LEN)
Hi,
On 2019-12-09 17:05:31 -0300, Alvaro Herrera wrote:
> * Thoughts from Andres, who was busily messing about with stringinfo.c
> on his patch series for programmatic out/read node functions?
I don't immediately see a need for mb functionality there. But to me it
seems pretty clear that we're
On Mon, Dec 9, 2019 at 1:00 PM Jeremy Finzel wrote:
> I have a table with about 7 million records. I had a query in which I
> needed 2 indexes added, one for a created timestamp field another for an id
> field; both very high cardinality.
>
> First I noticed the query would not use the timestamp
Alvaro Herrera writes:
> Also:
> * v18 and v19 now alwys do a "strlen(s)", i.e. they scan the whole input
> string -- pointless when maxlen is given. We could avoid that for
> very large input strings by doing strnlen(maxlen + MAX_MULTIBYTE_CHAR_LEN)
> so that we capture our input string pl
Alvaro Herrera writes:
> * Thoughts on changing the current usage of the ...Quoted() function in
> postgres.c and pl_exec.c so that they print N characters (64) instead
> of the current default of printing everything? I'm up for changing,
> but have got no +1s on that. I think bloating log
Alvaro Herrera writes:
> On 2019-Dec-09, Tom Lane wrote:
>> Good point: if we make a separate source file then we don't have
>> to solve any of the code-movement issues till somebody wants this
>> functionality in frontend. But we should expect that that day might
>> come eventually, so I don't m
Also:
* Thoughts from Andres, who was busily messing about with stringinfo.c
on his patch series for programmatic out/read node functions?
* Thoughts on changing the current usage of the ...Quoted() function in
postgres.c and pl_exec.c so that they print N characters (64) instead
of the cur
po 9. 12. 2019 v 3:51 odesílatel Karl O. Pinc napsal:
> Hi Pavel,
>
> Thanks for your changes. More inline below:
>
> On Sun, 8 Dec 2019 08:38:38 +0100
> Pavel Stehule wrote:
>
> > ne 8. 12. 2019 v 2:23 odesílatel Karl O. Pinc napsal:
>
> > > On Mon, 11 Nov 2019 15:47:37 +0100
> > > Pavel Steh
On 12/5/19 9:51 AM, Tomas Vondra wrote:
On Thu, Dec 05, 2019 at 06:15:54PM +0100, Tomas Vondra wrote:
On Sun, Dec 01, 2019 at 08:08:58PM +0100, Tomas Vondra wrote:
On Sat, Nov 30, 2019 at 03:01:31PM -0800, Mark Dilger wrote:
Are you planning to submit a revised patch for this?
Yes, I'll
po 9. 12. 2019 v 19:15 odesílatel Karl O. Pinc napsal:
> Hi Pavel,
>
> I've had some thoughts about the regression tests.
>
> It wouldn't hurt to move them to right after the
> scale() tests in numeric.sql.
>
> I believe your tests are covering all the code paths
> but it is not clear just what t
On 2019-Dec-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > So rather than mess with stringinfo.c at all I could just create
> > stringinfo_server.c and put this function there, compiled only for
> > backend ...
>
> Good point: if we make a separate source file then we don't have
> to solve any
I wrote:
> There are two things we could do about this:
> 1. Knock the hard-wired setting up a tad, maybe to 5 minutes.
> Easy but doesn't seem terribly future-proof.
> 2. Make the limit configurable somehow, probably from an
> environment variable. There's precedent for that (PGCTLTIMEOUT),
> and
Alvaro Herrera writes:
> So rather than mess with stringinfo.c at all I could just create
> stringinfo_server.c and put this function there, compiled only for
> backend ...
Good point: if we make a separate source file then we don't have
to solve any of the code-movement issues till somebody want
On Mon, Dec 9, 2019 at 11:54 PM Alvaro Herrera
wrote:
> On 2019-Dec-09, Ibrar Ahmed wrote:
>
> > Hi,
> >
> > The memory consumption of VACUUM has some issues and could be improved.
> > Some of its limitations are recorded in the comments of the
> “vacuumlazy.c”
> > file. The current design of VAC
On Fri, 6 Dec 2019 at 10:50, Amit Kapila wrote:
>
> On Thu, Dec 5, 2019 at 7:44 PM Robert Haas wrote:
> >
> > I think it might be a good idea to change what we expect index AMs to
> > do rather than trying to make anything that they happen to be doing
> > right now work, no matter how crazy. In p
On 2019-Dec-09, Ibrar Ahmed wrote:
> Hi,
>
> The memory consumption of VACUUM has some issues and could be improved.
> Some of its limitations are recorded in the comments of the “vacuumlazy.c”
> file. The current design of VACUUM memory usage is that it stores the TID
> in a fixed-size array whi
On 2019-Dec-09, Tom Lane wrote:
> I wrote:
> > Alvaro Herrera writes:
> >> 1. change enough of the build system so that pg_encoding_mbcliplen is
> >> available. (Offhand I see no reason why we couldn't move the
> >> function from mbutils.c to wchar.c, but I haven't tried.)
>
> > I'd be in favor
Andrew Dunstan writes:
> Patch 1 fixed the problems on frogmouth.
Cool, thanks. I'll push that in a bit (to the back branches as well as
HEAD).
> Patch 2 also ran without incident.
What do people think about the second patch? I'd only propose that
for HEAD, since it's not really a bug fix.
Hi,
The memory consumption of VACUUM has some issues and could be improved.
Some of its limitations are recorded in the comments of the “vacuumlazy.c”
file. The current design of VACUUM memory usage is that it stores the TID
in a fixed-size array which is allocated at the start, based upon
mainten
On 12/8/19 11:57 AM, Tom Lane wrote:
> I wrote:
>> So, just idly looking at the code in src/backend/port/win32/signal.c
>> and src/port/kill.c, I have to wonder why we have this baroque-looking
>> design of using *two* signal management threads. And, if I'm
>> reading it right, we create an enti
On Mon, 9 Dec 2019 12:15:22 -0600
"Karl O. Pinc" wrote:
> I've had some thoughts about the regression tests.
> Having written
> it out it seems like a lot of testing for such a simple function.
FYI.
I don't see trim_scale() needing such exhaustive testing because you'll
have already tested a l
Hi Pavel,
I've had some thoughts about the regression tests.
It wouldn't hurt to move them to right after the
scale() tests in numeric.sql.
I believe your tests are covering all the code paths
but it is not clear just what test does what.
I don't see a lot of comments in the tests so I don't
kno
Thanks for your answer, I will dive into the C code then.
Le 9/12/19 à 16:52, Mark Dilger a écrit :
Not all of them are real tables; some of the pg_catalog relations are
views over others of them. But many of them are real tables with C
structs that back them. Take a look in src/include/catal
On Mon, Dec 9, 2019 at 5:21 PM Robert Haas wrote:
>
> On Fri, Dec 6, 2019 at 9:51 AM Julien Rouhaud wrote:
>
> > This brings the second consideration: how to report the list corrupted
> > blocks to end users. As I said this is for now returned via the SRF,
> > but this is clearly not ideal and s
I have a table with about 7 million records. I had a query in which I
needed 2 indexes added, one for a created timestamp field another for an id
field; both very high cardinality.
First I noticed the query would not use the timestamp index no matter what
session config settings I used. I finall
I wrote:
> Alvaro Herrera writes:
>> 1. change enough of the build system so that pg_encoding_mbcliplen is
>> available. (Offhand I see no reason why we couldn't move the
>> function from mbutils.c to wchar.c, but I haven't tried.)
> I'd be in favor of this if it doesn't turn out to require nast
Hi Robert,
Thanks for your reply.
So, i have this question. I have seen a patch on similar issue with shared
catalog tables and it is fixed in PostgreSQL 9.6.10.
We are currently using 9.6.10.
Do you think we hit another bug ?
Is this because of some synchronization issue ?
Or is there something
On 12/9/19 9:28 AM, Ranier Vilela wrote:
I'll create the commitfest entry based on this email once
this has been sent.
Can you add the patch attached?
That showed up in the commitfest entry automatically when you
replied to this thread with the attachment.
You might consider signing up so
Alvaro Herrera writes:
> On 2019-Dec-07, Tom Lane wrote:
>> It is a very bad idea that this is truncating text without regard to
>> multibyte character boundaries.
> I see four possible ways forward, with nuances. In order of preference:
> 1. change enough of the build system so that pg_encodin
>I'll create the commitfest entry based on this email once
>this has been sent.
Can you add the patch attached?
regards,
Ranier Vilela
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index 8b2a2be1c0..e12f41cea4 100644
--- a/src/backend/replication/walsender.
This the second version of the global unshadow patch.
Taking into consideration made. In case anyone else revises.
regards
Ranier Vileladiff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 6bc1a6b46d..83be23d77b 100644
--- a/src/backend/access/transam/xlog.c
+++
On 2019-Dec-09, Alvaro Herrera wrote:
> I see four possible ways forward, with nuances. In order of preference:
>
> 1. change enough of the build system so that pg_encoding_mbcliplen is
>available. (Offhand I see no reason why we couldn't move the
>function from mbutils.c to wchar.c, bu
Mark Dilger writes:
> [ useful tips about finding the code that implements a SQL command ]
BTW, if it wasn't obvious already, you *really* want to have some kind
of tool that easily finds the definition of a particular C symbol.
You can fall back on "grep -r" or "git grep", but lots of people use
On Thu, Dec 5, 2019 at 03:19:50PM -0500, Robert Haas wrote:
> On Thu, Dec 5, 2019 at 1:12 PM Bruce Momjian wrote:
> > I agree with Stephen's request. We have been waiting for the executor
> > rewrite for a while, so let's just do something simple and see how it
> > performs.
>
> I'm sympathetic
Re: " It appears that the second row was in place originally, then got updated
by a trigger (and even deleted later on, although it doesn't appear that the
delete transaction got committed), and then the first row was inserted within
the same transaction that updated the second row."
If you hav
On 2019-Dec-07, Tom Lane wrote:
> 0001:
> It is a very bad idea that this is truncating text without regard to
> multibyte character boundaries.
Hmm. So it turns out that we recently made stringinfo.c exported to
frontends in libpgcommon. Clipping strings at a given character size
means we nee
On Mon, Dec 9, 2019 at 11:48 AM Tom Lane wrote:
> I think it depends a lot on the particular identifiers in use. You
> mentioned examples like "i" and "lc", and I'd add other obviously
> nonce variable names like "oldcxt". I'm not particularly concerned
> about shadowing arising from somebody wri
On Mon, Dec 9, 2019 at 11:21 AM Tom Lane wrote:
> If we did go that route, I think a disable count would be the right thing.
> It wouldn't take up any more space than a bool, probably, once you account
> for padding overhead. And the code impact in hotspots like add_path would
> be just about the
On Mon, Dec 9, 2019 at 11:21 AM rajesh kumar wrote:
> Thanks for your reply.
> So, i have this question. I have seen a patch on similar issue with shared
> catalog tables and it is fixed in PostgreSQL 9.6.10.
> We are currently using 9.6.10.
> Do you think we hit another bug ?
> Is this because o
Robert Haas writes:
> On Mon, Dec 9, 2019 at 10:23 AM Tom Lane wrote:
>> Well, again, this is a case-by-case question. I tend to agree that
>> changing that usage in subscriptioncmds.c might be a good idea.
>> That doesn't mean I need to be on board with wholesale removal
>> of shadowing warning
On 12/9/19 7:52 AM, Mark Dilger wrote:
Q1.1 If it is possible, is what is done in reality? I have the feeling
that it is not the case and that DDL queries are implemented in C
directly.
See src/backend/commands/tablecmds.c, function DefineRelation.
I realize I could be a bit more helpfu
On Fri, Dec 6, 2019 at 9:51 AM Julien Rouhaud wrote:
> This topic was discussed several times, with the most recent
> discussions found at [1] and [2]. Based on those discussions, my
> understanding is that the current approach in BASE_BACKUP has too many
> drawbacks and we should instead do this
Jim Finnerty writes:
> +1, adding that sort of structure to Cost would get rejected out of hand.
> however, having a 'disabled' bit be part of the cost structure is something
> that I would support. This has been discussed previously, but even adding
> one bit to Cost doesn't have everyone's supp
Julien Delplanque writes:
> I have a few questions about the internals of PostgreSQL and I think they
> require experts knowledge.
> Q1. Are PostgreSQL's meta-description tables (such as pg_class) the "reality"
> concerning the state of the DB or are they just a virtual representation ?
The sy
Hi Julien!
On 09/12/2019 17:35, Julien Delplanque wrote:
Q1. Are PostgreSQL's meta-description tables (such as pg_class) the "reality"
concerning the state of the DB or are they just a virtual representation ?
Yes, the catalog tables are the authoritative source. The system uses
those tables
On Mon, Dec 9, 2019 at 4:04 AM Kyotaro Horiguchi
wrote:
> Yeah, only 0.5GB of shared_buffers makes the default value of
> wal_buffers reach to the heaven. I think I can take numbers on that
> condition. (I doubt that it's meaningful if I increase only
> wal_buffers manually.)
Heaven seems a bit e
On 12/9/19 7:35 AM, Julien Delplanque wrote:
Hello PostgreSQL hackers,
I hope I am posting on the right mailing-list.
I am actually doing a PhD related to relational databases and software
engineering.
I use PostgreSQL for my research.
I have a few questions about the internals of Postgr
On Mon, Dec 9, 2019 at 10:23 AM Tom Lane wrote:
> Robert Haas writes:
> > On Sun, Dec 8, 2019 at 1:52 PM Tom Lane wrote:
> >> I don't think I'm actually on board with the goal here.
> > I don't know what to do about the RedoRecPtr mess, but surely
> > subscriptioncmds.c's use of synchronous_comm
On Fri, Dec 6, 2019 at 12:17 PM Andres Freund wrote:
> > 0001 is just a code movement patch. It puts the interrupt handling for
> > each type of background process into a subroutine, instead of having
> > it all inline in the main loop. I feel this makes things more clear.
> > Hopefully it's uncon
Hello PostgreSQL hackers,
I hope I am posting on the right mailing-list.
I am actually doing a PhD related to relational databases and software
engineering.
I use PostgreSQL for my research.
I have a few questions about the internals of PostgreSQL and I think they
require experts knowledge.
Robert Haas writes:
> On Sun, Dec 8, 2019 at 1:52 PM Tom Lane wrote:
>> I don't think I'm actually on board with the goal here.
> I don't know what to do about the RedoRecPtr mess, but surely
> subscriptioncmds.c's use of synchronous_commit as a char * when it's
> already exists as a global vari
On Mon, Dec 9, 2019 at 4:52 AM rajesh kumar wrote:
> We recently started seeing an error “ERROR: uncommitted xmin 347341220 from
> before xid cutoff 967029200 needs to be frozen” on our user tables.
> I’m unable to do ‘vacuum’, ‘vacuum freeze’ or ‘vacuum full’ on the affected
> tables.
>
> Fro
On Sun, Dec 8, 2019 at 1:52 PM Tom Lane wrote:
> Ranier Vilela writes:
> > This is the first part of the variable shadow fixes.
> > Basically it consists of renaming the variables in collision with the
> > global ones, with the minimum change in the semantics.
>
> I don't think I'm actually on b
> On 9 Dec 2019, at 12:02, Ranier Vilela wrote:
> diff --git a / src / backend / access / transam / multixact.c b / src /
> backend / access / transam / multixact.c
> index 7b2448e05b..6364014fb3 100644
> --- a / src / backend / access / transam / multixact.c
> +++ b / src / backend / access / t
De: Kyotaro Horiguchi
Enviado: segunda-feira, 9 de dezembro de 2019 03:40
>The file-scoped variable is needed to be process-persistent in any
>way. If we inhibit them, the upper-modules need to create the
>persistent area instead, for example, by calling XLogInitGlobals() or
>such, which makes thi
I was playing with the Unicode normalization test in
src/common/unicode/. I think there is something wrong with how the test
program reports failures. For example, if I manually edit the
norm_test_table.h to make a failure, like
-{ 74, { 0x00A8, 0 }, { 0x0020, 0x0308, 0 } },
+{ 74, {
Per discussion in [0], here is a patch set to remove support for Python
versions older than 2.6.
[0]:
https://www.postgresql.org/message-id/6d3b7b69-0970-4d40-671a-268c46e93...@2ndquadrant.com
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
Hi All,
We recently started seeing an error “ERROR: uncommitted xmin 347341220
from before xid cutoff 967029200 needs to be frozen” on our user tables.
I’m unable to do ‘vacuum’, ‘vacuum freeze’ or ‘vacuum full’ on the
affected tables.
>From what I read, this was a bug couple of years ago on Sy
Thanks Jeevan for reviewing the patch and offline discussion.
On Mon, Dec 9, 2019 at 11:15 AM Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
> On Fri, Dec 6, 2019 at 12:05 PM Rushabh Lathia
> wrote:
>
>>
>>
>> On Fri, Dec 6, 2019 at 1:44 AM Robert Haas wrote:
>>
>>> On Thu, Dec 5, 2
On Mon, Dec 9, 2019 at 2:27 PM Amit Kapila wrote:
>
> I have modified the patch for the above points and additionally ran
> pgindent. Let me know what you think about the attached patch?
>
A new version with a slightly modified commit message.
--
With Regards,
Amit Kapila.
EnterpriseDB: http:/
Hello.
At Sun, 8 Dec 2019 10:09:51 -0800, Noah Misch wrote in
> I reviewed your latest code, and it's nearly complete. mdimmedsync() syncs
> only "active segments" (as defined in md.c), but smgrDoPendingSyncs() must
> sync active and inactive segments. This matters when mdtruncate() truncated
1 - 100 of 103 matches
Mail list logo
