On Fri, Feb 21, 2020 at 12:35:03AM +, Andrew Gierth wrote:
> > "Stephen" == Stephen Frost writes:
>
> >> I figure something along these lines for the fix. Anyone in a
> >> position to test this?
>
> Stephen> At least at first blush, I tend to agree with your analysis
> Stephen> and p
Executive summary: the "MyWalSnd->write < sentPtr" in WalSndWaitForWal() is
important for promptly updating pg_stat_replication. When caught up, we
should impose that logic before every sleep. The one-line fix is to sleep in
WalSndLoop() only when pq_is_send_pending(), not when caught up.
On my
On Tue, 31 Mar 2020 at 14:13, Masahiko Sawada
wrote:
>
> On Tue, 31 Mar 2020 at 12:58, Amit Kapila wrote:
> >
> > On Mon, Mar 30, 2020 at 12:31 PM Masahiko Sawada
> > wrote:
> > >
> > > The patch for vacuum conflicts with recent changes in vacuum. So I've
> > > attached rebased one.
> > >
> >
>
Hi,
On 2020-04-06 14:26:48 +0900, Michael Paquier wrote:
> 2PC shines with the code of xlogreader.c in this case because it keeps
> opening and closing XLogReaderState for a short amount of time. So it
> is not surprising to me to see this error only months after the fact
> because recovery or pg
On Sun, Apr 05, 2020 at 07:56:51PM -0700, Andres Freund wrote:
> I found this while trying to benchmark the effect of my snapshot changes
> on 2pc. I just used the attached pgbench file.
>
> I've not yet reviewed the change sufficiently to pinpoint the issue.
Indeed. It takes seconds to show up.
Hello,
Do I need to precede those with some recursive chmod commands? Perhaps
the client should refuse to run if there is still something left after
these.
I think the latter would be a very good idea, just so that this sort of
failure is less obscure. Not sure about whether a recursive chm
Hi,
Due to the change below, when using the default postgres configuration
of ynchronous_commit = on, max_wal_senders = 10, will now acquire a new
exclusive lwlock after writing a commit record.
commit 48c9f4926562278a2fd2b85e7486c6d11705f177
Author: Simon Riggs
Date: 2017-12-29 14:30:33 +
On Sun, Apr 5, 2020 at 8:56 PM Andres Freund wrote:
> Perhaps put it on a wiki page?
I added a new major section to the "getting a stack trace" wiki page:
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Recording_Postgres_using_rr_Record_and_Re
On Sun, Apr 5, 2020 at 9:39 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Sun, Apr 05, 2020 at 04:30:51PM +0530, Dilip Kumar wrote:
> >
> > I was just wondering how the distinct will work with the "skip scan"
> > if we have some filter? I mean every time we select the unique row
> > base
Hi,
On 2020-04-05 20:35:50 -0700, Peter Geoghegan wrote:
> I have found that it's useful to use rr to debug Postgres by following
> certain recipes. I'll share some of the details now, in case anybody
> else wants to start using rr and isn't sure where to start.
Perhaps put it on a wiki page?
>
On Sun, Apr 5, 2020 at 6:54 PM Andres Freund wrote:
> I just pushed that.
Great!
I have found that it's useful to use rr to debug Postgres by following
certain recipes. I'll share some of the details now, in case anybody
else wants to start using rr and isn't sure where to start.
I have a scrip
On Sat, Apr 4, 2020 at 2:50 PM Julien Rouhaud wrote:
>
> On Sat, Apr 04, 2020 at 02:39:32PM +0530, Amit Kapila wrote:
> > On Sat, Apr 4, 2020 at 2:24 PM Julien Rouhaud wrote:
> > > >
> > > > We can add if we want but I am not able to convince myself for that.
> > > > Do you have any use case in m
Hi,
Using 2PC with master very quickly leads to:
2020-04-05 19:42:18.368 PDT [2298126][5/2009:0] LOG: out of file descriptors:
Too many open files; release and retry
2020-04-05 19:42:18.368 PDT [2298126][5/2009:0] STATEMENT: COMMIT PREPARED
'ptx_2';
This started with:
commit 0dc8ead46363fec
On Fri, Apr 03, 2020 at 03:54:38PM +0900, Michael Paquier wrote:
> Now, would it be better to apply the refactoring patch for HEAD before
> feature freeze, or are people fine if this is committed a bit after?
> Patch 0002 is neither a new feature, nor an actual bug, and just some
> code cleanup, bu
On 2020-04-04 21:02:56 -0700, Peter Geoghegan wrote:
> On Fri, Mar 27, 2020 at 11:22 AM Andres Freund wrote:
> > I've found rr [1] very useful to debug issues in postgres. The ability
> > to hit a bug, and then e.g. identify a pointer with problematic
> > contents, set a watchpoint on its contents
At Sat, 4 Apr 2020 15:32:12 -0700, Noah Misch wrote in
> On Sat, Apr 04, 2020 at 06:24:34PM -0400, Tom Lane wrote:
> > Shouldn't the CF entry get closed?
>
> Once the buildfarm is clean for a day, sure. The buildfarm has already
> revealed a missing perl2host call.
Thank you for (re-) committi
On Tue, Mar 24, 2020 at 1:00 AM Anastasia Lubennikova
wrote:
> > I think you're right. However, it still seems like we should check
> > that "kitem->indexOffset" is consistent among all of the BTScanPosItem
> > entries that we have for each TID that we believe to be from the same
> > posting list
Hi,
On 2020-04-05 19:54:19 -0400, Alvaro Herrera wrote:
> Isn't it the case that you can create an inner block with a constant
> whose size is determined by a containing block's variable? I mean as in
> the attached, which refuses to compile because of our -Werror=vla -- but
> if I remove it, it
Hello, hackers!
I`m investigating a complains from our clients about archive recovery
speed been very slow, and I`ve noticed a really strange and, I think, a
very dangerous recovery behavior.
When running multi-timeline archive recovery, for every requested segno
startup process iterates thr
On 2020-Apr-05, Tom Lane wrote:
> What I wish we had was alloca(), so you don't need a FUNC_MAX_ARGS-sized
> array to parse a two-argument function call. Too bad C99 didn't add
> that. (But some sniffing around suggests that an awful lot of systems
> have it anyway ... even MSVC. Hmmm.)
Isn't
Hi,
On 2020-03-27 17:21:10 -0700, Jeff Davis wrote:
> Attached refactoring patch. There's enough in here that warrants
> discussion that I don't think this makes sense for v13 and I'm adding
> it to the July commitfest.
IDK, adding a commit to v13 that we know we should do architecturally
differe
Hi,
When starting with on a data directory with an older WAL page magic we
currently make that hard to debug. E.g.:
2020-04-05 15:31:04.314 PDT [1896669][:0] LOG: database system was shut down
at 2020-04-05 15:24:56 PDT
2020-04-05 15:31:04.314 PDT [1896669][:0] LOG: invalid primary checkpoint
Amit Langote writes:
> Okay, I tried that in the updated patch. I didn't try to come up with
> examples that might break it though.
I looked through this.
* Wasn't excited about inventing makeCoalesceExpr(); the fact that it only
had two potential call sites seemed to make it not worth the troub
v17 is a rebase fixing a minor parse_coerce.c edit; v16 lasted little
:-( I chose to change the wording of the conflicting comment in
enforce_generic_type_consistency():
* 3) Similarly, if return type is ANYRANGE or ANYMULTIRANGE, and any
*argument is ANYRANGE or ANYMULTIRANGE, use that
On 2020-Apr-05, Fabien COELHO wrote:
> > > As the definitions are short and to the point, maybe the HTML display
> > > could (also) "hover" the definitions when the mouse passes over the word,
> > > using the "title" attribute?
> >
> > I like that idea, if it doesn't conflict with accessibility s
On 2020-04-05 15:38:29 -0400, Tom Lane wrote:
> Andres Freund writes:
> > We could print the error using :LAST_ERROR_MESSAGE after removing a
> > potential trailing "at character ..." if we're worried about the loss of
> > specificity.
>
> Oh, actually it seems that :LAST_ERROR_MESSAGE is already
On Wed, Dec 11, 2019 at 09:29:17PM +0500, Ibrar Ahmed wrote:
> > Did you modify Claudio's patch or write a totally new one?
>
> I wrote completely new patch. I tried multiple techniques like using a list
> instead of fixed size array which I thought was most suitable here, but
> leave that because
Andrew Dunstan writes:
> Hmm, the buildfarm client does this at the beginning of each run to
> remove anything that might be left over from a previous run:
> rmtree("inst");
> rmtree("$pgsql") unless ($from_source && !$use_vpath);
Right, the point is precisely that some versions of rmtre
On 4/5/20 9:10 AM, Mikael Kjellström wrote:
> On 2020-04-04 04:43, Robert Haas wrote:
>
>> I think I've done about as much as I can do for tonight, though. Most
>> things are green now, and the ones that aren't are failing because of
>> stuff that is at least plausibly fixed. By morning it should
Hi Michail,
On Fri, Jan 24, 2020 at 6:16 AM Michail Nikolaev
wrote:
> Some of issues your mentioned (reporting feedback to the another
> cascade standby, processing queries after restart and newer xid
> already reported) could be fixed in provided design, but your
> intention to have "independent
Andres Freund writes:
> On 2020-04-05 15:04:30 -0400, Tom Lane wrote:
>> That would only reduce the chance of getting a stack overflow there,
>> and not by that much, especially not for a CLOBBER_CACHE_ALWAYS animal
>> which is going to be doing catalog accesses inside there too.
> It'd certainly
Andres Freund writes:
> On 2020-04-05 14:33:19 -0400, Tom Lane wrote:
>> 1. Change the test to do "\set VERBOSITY sqlstate" so that all that
>> is printed is
>> ERROR: 54001
>> ERRCODE_STATEMENT_TOO_COMPLEX is used in few enough places that
>> this wouldn't be too much of a loss of specificity.
Hi,
On 2020-04-03 15:22:23 -0400, Robert Haas wrote:
> I've pushed all the patches.
Seeing new warnings in an optimized build
/home/andres/src/postgresql-master/src/bin/pg_validatebackup/parse_manifest.c:
In function 'json_manifest_object_end':
/home/andres/src/postgresql-master/src/bin/pg_vali
Hi,
On 2020-04-05 15:04:30 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Another avenue could be to make ParseFuncOrColumn et al use less stack,
> > and hope that it avoids the problem. It's a bit insane that we use this
> > much.
>
> That would only reduce the chance of getting a stack ove
Andres Freund writes:
> Another avenue could be to make ParseFuncOrColumn et al use less stack,
> and hope that it avoids the problem. It's a bit insane that we use this
> much.
That would only reduce the chance of getting a stack overflow there,
and not by that much, especially not for a CLOBBER
On 2020-Apr-05, Jürgen Purtz wrote:
> a) Some rearrangements of the sequence of terms to meet alphabetical order.
Thanks, will get this pushed.
> b) --> in
> two cases. Or should it be a ?
Ah, yeah, those should be linkend.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Pos
Hi,
On 2020-04-05 14:33:19 -0400, Tom Lane wrote:
> It's a bit surprising perhaps that we run out of stack here and not
> somewhere else; but ParseFuncOrColumn and its subroutines consume
> quite a lot of stack, because of FUNC_MAX_ARGS-sized local arrays,
> so it's not *that* surprising.
>
> So,
Over in the thread at [1] we were wondering how come buildfarm member
hyrax has suddenly started to fail like this:
diff -U3
/home/buildfarm/buildroot/HEAD/pgsql.build/src/test/regress/expected/errors.out
/home/buildfarm/buildroot/HEAD/pgsql.build/src/test/regress/results/errors.out
---
/home/b
Hello, Peter.
> I added
> something about this to the nbtree README in commit 9f83468b353.
I have added some updates to your notes in the updated patch version.
I also was trying to keep the original wrapping of the paragraph, so
the patch looks too wordy.
Thanks,
Michail.
btree-race-and-do
On Sun, Apr 5, 2020 at 8:00 PM Tomas Vondra
wrote:
> On Sun, Apr 05, 2020 at 07:33:40PM +0300, Alexander Korotkov wrote:
> >On Sun, Apr 5, 2020 at 6:53 PM Tomas Vondra
> > wrote:
> >> On Sun, Apr 05, 2020 at 06:29:15PM +0300, Alexander Korotkov wrote:
> >> >On Thu, Apr 2, 2020 at 5:29 AM Tomas Von
On Sun, Apr 05, 2020 at 07:33:40PM +0300, Alexander Korotkov wrote:
On Sun, Apr 5, 2020 at 6:53 PM Tomas Vondra
wrote:
On Sun, Apr 05, 2020 at 06:29:15PM +0300, Alexander Korotkov wrote:
>On Thu, Apr 2, 2020 at 5:29 AM Tomas Vondra
> wrote:
>> On Sun, Dec 01, 2019 at 10:55:02AM +0900, Michael P
Jaime Casanova writes:
> Another one caught by sqlsmith, on the regression database run this
> query (using any non-partitioned table works fine):
> select currtid('pagg_tab'::regclass::oid, '(0,156)'::tid) >= '(1,158)'::tid;
Hm, so
(1) currtid_byreloid and currtid_byrelname lack any check to se
On Mon, Mar 23, 2020 at 8:28 PM Nikita Glukhov wrote:
> Attached 47th version of the patches.
>
> On 21.03.2020 22:38, Pavel Stehule wrote:
>
>
> On 21. 3. 2020 v 11:07 Nikita Glukhov wrote:
>>
>> Attached 46th version of the patches.
>>
>> On 20.03.2020 22:34, Pavel Stehule wrote:
>>
>>
>> On 19
On Sun, Apr 5, 2020 at 6:53 PM Tomas Vondra
wrote:
> On Sun, Apr 05, 2020 at 06:29:15PM +0300, Alexander Korotkov wrote:
> >On Thu, Apr 2, 2020 at 5:29 AM Tomas Vondra
> > wrote:
> >> On Sun, Dec 01, 2019 at 10:55:02AM +0900, Michael Paquier wrote:
> >> >On Thu, Sep 26, 2019 at 09:01:48PM +0200, T
On Sun, Apr 5, 2020 at 6:51 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'd like to give this patchset a chance for v13. I'm going to make
> > another pass trough this patchset. If I wouldn't find serious issues,
> > I'm going to commit it. Any objections?
>
> I think it is way too lat
> On Sun, Apr 05, 2020 at 04:30:51PM +0530, Dilip Kumar wrote:
>
> I was just wondering how the distinct will work with the "skip scan"
> if we have some filter? I mean every time we select the unique row
> based on the prefix key and that might get rejected by an external
> filter right?
Not exac
On Sun, Apr 05, 2020 at 06:29:15PM +0300, Alexander Korotkov wrote:
Hi!
On Thu, Apr 2, 2020 at 5:29 AM Tomas Vondra
wrote:
On Sun, Dec 01, 2019 at 10:55:02AM +0900, Michael Paquier wrote:
>On Thu, Sep 26, 2019 at 09:01:48PM +0200, Tomas Vondra wrote:
>> Yeah, the opclass params patches got bro
Alexander Korotkov writes:
> I'd like to give this patchset a chance for v13. I'm going to make
> another pass trough this patchset. If I wouldn't find serious issues,
> I'm going to commit it. Any objections?
I think it is way too late to be reviving major features that nobody
has been lookin
Hi!
On Thu, Apr 2, 2020 at 5:29 AM Tomas Vondra
wrote:
> On Sun, Dec 01, 2019 at 10:55:02AM +0900, Michael Paquier wrote:
> >On Thu, Sep 26, 2019 at 09:01:48PM +0200, Tomas Vondra wrote:
> >> Yeah, the opclass params patches got broken by 773df883e adding enum
> >> reloptions. The breakage is som
Hi,
For the record, here is the relevant part of the Incremental Sort patch
series, updating add_partial_path and add_partial_path_precheck to also
consider startup cost.
The changes in the first two patches are pretty straight-forward, plus
there's a proposed optimization in the precheck functi
On Sun, Apr 05, 2020 at 03:01:10PM +0200, Tomas Vondra wrote:
On Thu, Apr 02, 2020 at 09:40:45PM -0400, James Coleman wrote:
On Thu, Apr 2, 2020 at 8:46 PM James Coleman wrote:
On Thu, Apr 2, 2020 at 8:20 PM Tomas Vondra
wrote:
...
5) Overall, I think the costing is OK. I'm sure we'll find
On 2020-04-04 04:43, Robert Haas wrote:
I think I've done about as much as I can do for tonight, though. Most
things are green now, and the ones that aren't are failing because of
stuff that is at least plausibly fixed. By morning it should be
clearer how much broken stuff is left, although that
Attached is an attempt at improving things. I have added a explicit note and
hijacked an existing example to better illustrate the purpose of the
function.
A significant part of the complexity of the patch is the overflow-handling
implementation of (a * b % c) for 64 bits integers.
Howeve
On Sun, 1 Mar 2020 at 21:47, Andres Freund wrote:
> On 2020-03-01 00:36:01 -0800, Andres Freund wrote:
> > conns tps mastertps pgxact-split
> >
> > 1 26842.49284526524.194821
> > 10 246923.158682 249224.782661
> > 50 695956.539704 70983
On Sun, Apr 05, 2020 at 08:01:36PM +0900, Masahiko Sawada wrote:
> On Sun, 5 Apr 2020 at 18:45, Julien Rouhaud wrote:
> >
> > On Sun, Apr 05, 2020 at 06:08:06PM +0900, Masahiko Sawada wrote:
> > >
> > > Why do we need two rows in the doc? For instance, replication slot
> > > functions have some op
On Sun, 5 Apr 2020 at 18:45, Julien Rouhaud wrote:
>
> On Sun, Apr 05, 2020 at 06:08:06PM +0900, Masahiko Sawada wrote:
> >
> > Why do we need two rows in the doc? For instance, replication slot
> > functions have some optional arguments but there is only one row in
> > the doc. So I think we don'
On Wed, Mar 25, 2020 at 2:19 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Wed, Mar 25, 2020 at 11:31:56AM +0530, Dilip Kumar wrote:
> >
> > Seems like you forgot to add the uniquekey.c file in the
> > v33-0001-Unique-key.patch.
>
> Oh, you're right, thanks. Here is the corrected patch.
On 2020-03-27 15:58, David Steele wrote:
Hi Peter,
On 12/27/19 3:22 PM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think it'd be great if this behavior could be implemented
within the notation, because we could then just set up a
non-empty default pg_ident.conf with useful
Hello Yuri,
PDEP is indeed first thing that comes up when you start googling
z-curve and bit interleaving :)
We had the code with z-curve generating PDEP instruction in PostGIS,
and dropped it since. In sorting, we now utilize sort support / prefix
search, and key generated as Hilbert curve, with
On Sun, Apr 05, 2020 at 06:08:06PM +0900, Masahiko Sawada wrote:
>
> Why do we need two rows in the doc? For instance, replication slot
> functions have some optional arguments but there is only one row in
> the doc. So I think we don't need to change the doc from the previous
> version patch.
>
On Sun, 5 Apr 2020 at 17:44, Julien Rouhaud wrote:
>
> On Sun, Apr 05, 2020 at 01:13:30PM +0900, Masahiko Sawada wrote:
> >
> > Thank you for updating the patch! The patch looks good to me. Here are
> > some random comments mostly about cosmetic changes.
> >
>
> Thanks a lot for the review!
Thank
On Sun, Apr 05, 2020 at 01:13:30PM +0900, Masahiko Sawada wrote:
>
> Thank you for updating the patch! The patch looks good to me. Here are
> some random comments mostly about cosmetic changes.
>
Thanks a lot for the review!
>
> 1.
> I think we can have two separate SQL functions:
> pg_check_r
a) Some rearrangements of the sequence of terms to meet alphabetical order.
b) -->
in two cases. Or should it be a ?
Kind regards, Jürgen
diff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml
index 8c6cb6e942..25762b7c3a 100644
--- a/doc/src/sgml/glossary.sgml
+++ b/doc/s
Hi,
Another one caught by sqlsmith, on the regression database run this
query (using any non-partitioned table works fine):
"""
select currtid('pagg_tab'::regclass::oid, '(0,156)'::tid) >= '(1,158)'::tid;
"""
This works on 11 (well it gives an error because the file doesn't
exists) but crash the
On 2020-04-02 08:21, Michael Paquier wrote:
On Wed, Apr 01, 2020 at 04:26:25PM +0200, Peter Eisentraut wrote:
Good catch. How about the attached patch?
WFM. Another trick would be to call LWLockRelease() after generating
the log, but I find your patch more consistent with the surroundings.
Hi Corey,
ISTM that occurrences of these words elsewhere in the documentation should
link to the glossary definitions?
Yes, that's a big project. I was considering writing a script to compile
all the terms as search terms, paired with their glossary ids, and then
invoke git grep to identify
Hi,
vacuum_rel() has the following comment:
/*
* Functions in indexes may want a snapshot set. Also, setting a
snapshot
* ensures that RecentGlobalXmin is kept truly recent.
*/
PushActiveSnapshot(GetTransactionSnapshot());
which was added quite a while
67 matches
Mail list logo
