Hi
Thank you for fixing the patch.
The new patch works well in my environment. :-D
This may not be important at this time since it is a
PoC patch, but I would like to inform you that there
was a line that contained multiple spaces instead of tabs.
$ git diff --check
src/backend/access/transam
On Wed, Jun 9, 2021 at 2:07 AM Robert Haas wrote:
> Then I tried to get things working on 9.6. There's a patch attached to
> back-port a couple of PostgresNode.pm methods from 10 to 9.6, and also
> a version of the main patch attached with the necessary wal->xlog,
> lsn->location renaming. Unfort
"houzj.f...@fujitsu.com" writes:
> On Tuesday, June 8, 2021 10:51 PM Robert Haas
> wrote:
>> In my opinion, you're basically taking too pure a view of this. We're
>> not trying to create a system that does such a good job checking
>> parallel safety markings that nobody can possibly find a thing
On Wednesday, June 9, 2021 12:06 PM Amit Kapila wrote:
> On Tue, Jun 8, 2021 at 6:24 PM vignesh C wrote:
> >
> > Thanks for the updated patch.
> >
> > I have few comments:
> > 1) Should we list the actual system tables like pg_class,pg_trigger,
> > etc instead of any other catalog table?
> > User
I wrote:
> Bharath Rupireddy writes:
>>> I've added a simple regression test to postgres_fdw, testing that batch
>>> sizes > 65535 work fine, and pushed the fix.
>> I was earlier thinking of adding one, but stopped because it might
>> increase the regression test execution time. It looks like tha
On Tuesday, June 8, 2021 10:51 PM Robert Haas
> On Mon, Jun 7, 2021 at 11:33 PM Amit Kapila
> wrote:
> > Note the error is raised after applying the patch, without the patch,
> > the above won't show any error (error message could be improved here).
> > Such cases can lead to unpredictable behavi
On Wed, Jun 9, 2021 at 11:37 AM Drouvot, Bertrand wrote:
>
> On 6/9/21 5:33 AM, Amit Kapila wrote:
> > On Wed, Jun 9, 2021 at 12:06 AM Jeremy Schneider
> > wrote:
> >> On 6/4/21 23:42, Amit Kapila wrote:
> >>
> >> On 2021-Jun-04, Jeremy Schneider wrote:
> >>
> >> ERROR: XX000: could not open rel
Bharath Rupireddy writes:
>> I've added a simple regression test to postgres_fdw, testing that batch
>> sizes > 65535 work fine, and pushed the fix.
> I was earlier thinking of adding one, but stopped because it might
> increase the regression test execution time. It looks like that's true
> - wi
On Wed, Jun 9, 2021 at 9:58 AM Greg Nancarrow wrote:
>
> (5) src/backend/access/transam/twophase.c
>
> Question:
>
> Is:
>
> + * do this optimization if we encounter many collisions in GID
>
> meant to be:
>
> + * do this optimization if we encounter any collisions in GID
>
No, it should be fine
On Wed, Jun 9, 2021 at 10:34 AM Ajin Cherian wrote:
>
> On Tue, Jun 8, 2021 at 4:19 PM Peter Smith wrote:
>
> > > 3.
> > > @@ -432,10 +432,19 @@ CreateInitDecodingContext(const char *plugin,
> > > MemoryContextSwitchTo(old_context);
> > >
> > > /*
> > > - * We allow decoding of prepared trans
On Tue, Jun 8, 2021 at 5:16 PM Dilip Kumar wrote:
>
> Based on the off list discussion, I have modified the test based on
> the idea showed in
> "isolation/specs/insert-conflict-specconflict.spec", other open point
> we had about the race condition that how to ensure that when we unlock
> any sess
On Mon, Jun 07, 2021 at 12:44:42PM +0300, Aleksander Alekseev wrote:
> I confirm that the bug still exists in master (be57f216). The patch
> fixes it and looks good to me. I changed the wording a little and
> added a regression test. The updated patch is in the attachment. I
> added this thread to
On Tue, Jun 08, 2021 at 05:33:31PM -0700, Jeff Davis wrote:
> New version attached, with the detoasting code removed. Could use
> another round of validation/cleanup in case I missed something during
> the merge.
This looks rather sane to me, thanks.
/* Create the transient table that will re
On Wed, Jun 2, 2021 at 10:41 PM Bharath Rupireddy
wrote:
>
> On Wed, Jun 2, 2021 at 11:43 AM Peter Smith wrote:
> > Yes, it looks better, but (since the masks are all 1 bit) I was only
> > asking why not do like:
> >
> > if (supported_opts & SUBOPT_CONNECT)
> > if (supported_opts & SUBOPT_ENABLED
On Wed, Jun 09, 2021 at 03:21:36PM +1200, Thomas Munro wrote:
> On Wed, Jun 9, 2021 at 2:44 PM Tom Lane wrote:
> > ... or we could shorten those file names. I recall an episode
> > awhile ago where somebody complained that their version of "tar"
> > couldn't handle some of the path names in our t
Hi Horiguchi-san,
On 2021/06/09 11:47, Kyotaro Horiguchi wrote:
On 2021/06/08 18:19, Tatsuro Yamada wrote:
I've tried your patch. Unfortunately, it didn't seem to have any good
effect on the script I sent to reproduce the problem.
Oops! The patch forgot about history files.
I checked the att
On Tue, Jun 8, 2021 at 4:12 PM Peter Smith wrote:
>
> Please find attached the latest patch set v83*
>
Some feedback for the v83 patch set:
v83-0001:
(1) doc/src/sgml/protocol.sgml
(i) Remove extra space:
BEFORE:
+ The transaction will be decoded and transmitted at
AFTER:
+ T
On Tue, Jun 8, 2021 at 5:28 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > On Tue, Jun 8, 2021 at 9:47 AM tsunakawa.ta...@fujitsu.com
> > wrote:
> > > Why does the client have to know the error on a remote server, whereas the
> > global transaction itself is destined to comm
On Wed, Jun 9, 2021 at 12:04 AM Tomas Vondra
wrote:
> No, the "Int16" refers to the FE/BE documentation, where we use Int16.
> But in the C code we interpret it as uint16.
Hm. I see that in protocol.sgml Int16 is being used.
> I've added a simple regression test to postgres_fdw, testing that bat
On Tue, Jun 08, 2021 at 06:59:04PM +0900, Kyotaro Horiguchi wrote:
> The cause is that the time unit is changed to usec but the patch
> forgot to convert agg_interval into the same unit in doLog. I tempted
> to change it into pg_time_usec_t but it seems that it is better that
> the unit is same wit
On Wed, Jun 9, 2021 at 12:06 AM Jeremy Schneider wrote:
>
> On 6/4/21 23:42, Amit Kapila wrote:
>
> On 2021-Jun-04, Jeremy Schneider wrote:
>
> ERROR: XX000: could not open relation with OID 0
> LOCATION: ReorderBufferToastReplace, reorderbuffer.c:305
>
> Even, if this fixes the issue, I guess it
Michael Paquier writes:
> On Tue, Jun 08, 2021 at 10:39:24AM -0400, Alvaro Herrera wrote:
>> Maybe at this point reverting is the only solution.
> That's a safe bet at this point. It would be good to conclude this
> one by beta2 IMO.
I still think it's a really dubious argument that anybody wou
On Tue, Jun 08, 2021 at 10:39:24AM -0400, Alvaro Herrera wrote:
> My unverified guess is that this code causes too many pipeline stalls
> while executing the big per-column loop. Maybe it would be better to
> scan the attribute array twice: one to collect all data from
> Form_pg_attribute for each
[Responding to two emails in one]
On Wed, Jun 9, 2021 at 2:44 PM Tom Lane wrote:
> ... or we could shorten those file names. I recall an episode
> awhile ago where somebody complained that their version of "tar"
> couldn't handle some of the path names in our tarball, so
> keeping things from ge
On Tue, Jun 8, 2021 at 6:24 PM vignesh C wrote:
>
> Thanks for the updated patch.
>
> I have few comments:
> 1) Should we list the actual system tables like pg_class,pg_trigger,
> etc instead of any other catalog table?
> User has issued an explicit LOCK on pg_class (or any other catalog table)
>
On Wed, Jun 09, 2021 at 01:57:45PM +1200, Thomas Munro wrote:
> test deadlock-simple ... ok 20 ms
> test deadlock-hard... ok10624 ms
> test deadlock-soft... ok 147 ms
> test deadlock-soft-2 ... ok 5154 ms
>
On Wed, Jun 09, 2021 at 12:28:48AM +, houzj.f...@fujitsu.com wrote:
> OK, Thanks for the explanation.
> Added to CF: https://commitfest.postgresql.org/33/3159/
At first glance, this looked to me like breaking something just for
sake of breaking it, but removing the rel argument could be helpfu
On 2021/06/08 18:19, Tatsuro Yamada wrote:
I've tried your patch. Unfortunately, it didn't seem to have any good
effect on the script I sent to reproduce the problem.
Oops! The patch forgot about history files.
I checked the attached with your repro script and it works fine.
I understand th
Thomas Munro writes:
> test detach-partition-concurrently-1 ... ok 553 ms
> test detach-partition-concurrently-2 ... ok 234 ms
> test detach-partition-concurrently-3 ... ok 2389 ms
> test detach-partition-concurrently-4 ... ok 1876 ms
> Any objections to making t
On Tue, Jun 08, 2021 at 05:47:28PM -0700, Peter Geoghegan wrote:
> I don't have time to try this out myself today, but offhand I'm pretty
> confident that this is sufficient to reproduce the underlying bug
> itself. And if that's true then I guess it can't have anything to do
> with the pg_upgrade/
Michael Paquier writes:
> On Tue, Jun 08, 2021 at 11:21:34AM -0400, Tom Lane wrote:
>> IIUC, what you are proposing to do is replace pgwin32_setenv with
>> src/port/setenv.c. I don't think that's an improvement. setenv.c
>> leaks memory on repeat calls, because it cannot know what
>> pgwin32_set
On Wed, Jun 9, 2021 at 2:17 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-06-08 14:27:14 +0200, Matthias van de Meent wrote:
> > heap_prune_satisfies_vacuum considers 1 more transaction to be
> > unvacuumable, and thus indeed won't vacuum that tuple that
> > HeapTupleSatisfiesVacuum does want to be
Hi.
On 2021/06/08 21:21, Abbas Butt wrote:
Hi Kyotaro,
I have tried to test your patches. Unfortunately even after applying the
patches
the WAL Sender is still sending too frequent keepalive messages.
Sorry for the bogus patch. I must have seen something impossible.
The keep-alive packet is
On Wed, Jun 09, 2021 at 10:17:35AM +0800, Julien Rouhaud wrote:
> On Wed, Jun 09, 2021 at 01:57:45PM +1200, Thomas Munro wrote:
>> Any objections to making these new tests line up with the rest?
>
> No objection, as the output is still way under 80 characters.
+1.
--
Michael
signature.asc
Descr
On Wed, Jun 09, 2021 at 01:57:45PM +1200, Thomas Munro wrote:
> Hi,
>
> test deadlock-simple ... ok 20 ms
> test deadlock-hard... ok10624 ms
> test deadlock-soft... ok 147 ms
> test deadlock-soft-2 ... ok
Hi,
test deadlock-simple ... ok 20 ms
test deadlock-hard... ok10624 ms
test deadlock-soft... ok 147 ms
test deadlock-soft-2 ... ok 5154 ms
test deadlock-parallel... ok 132 ms
test deta
On Tue, Jun 08, 2021 at 11:21:34AM -0400, Tom Lane wrote:
> IIUC, what you are proposing to do is replace pgwin32_setenv with
> src/port/setenv.c. I don't think that's an improvement. setenv.c
> leaks memory on repeat calls, because it cannot know what
> pgwin32_setenv knows about how putenv work
On Wed, Jun 09, 2021 at 12:25:51AM +0900, torikoshia wrote:
> BTW, I did the same thing in another patch I'm proposing[1], so I'll fix
> that as well.
Yes, it would be better to be consistent here.
--
Michael
signature.asc
Description: PGP signature
On Tue, Jun 08, 2021 at 05:44:15PM -0700, Peter Geoghegan wrote:
> On Tue, Jun 8, 2021 at 5:11 PM Tom Lane wrote:
> > I wonder if this is a variant of the problem shown at
> >
> > https://www.postgresql.org/message-id/2591376.1621196582%40sss.pgh.pa.us
> >
> > where maybe_needed was visibly quite
On Tue, Jun 8, 2021 at 5:18 PM Justin Pryzby wrote:
> I reproduced the issue on a new/fresh cluster like this:
>
> ./postgres -D data -c autovacuum_naptime=1 -c
> autovacuum_analyze_scale_factor=0.005 -c log_autovacuum_min_duration=-1
> psql -h /tmp postgres -c "CREATE TABLE t(i int); INSERT INTO
On Tue, Jun 8, 2021 at 5:11 PM Tom Lane wrote:
> I wonder if this is a variant of the problem shown at
>
> https://www.postgresql.org/message-id/2591376.1621196582%40sss.pgh.pa.us
>
> where maybe_needed was visibly quite insane. This value is
> less visibly insane, but it's still wrong. It might
On Thu, 2021-06-03 at 14:36 -0700, Jeff Davis wrote:
> Do we have general agreement on this point? Did I miss another
> purpose
> of detoasting in tablecmds.c, or can we just remove that part of the
> patch?
Per discussion with Justin, I'll drive this patch. I merged the CF
entries into https://co
On Tuesday, June 8, 2021 7:30 PM David Rowley
> On Tue, 8 Jun 2021 at 21:50, houzj.f...@fujitsu.com
> wrote:
> > I noticed that the first function parameter in
> > get_qual_from_partbound(**Relation rel**, Relation parent, is not used in
> > the
> function.
> >
> > Is it better to remove it like
On Tue, Jun 08, 2021 at 02:38:37PM -0700, Peter Geoghegan wrote:
> On Tue, Jun 8, 2021 at 2:23 PM Justin Pryzby wrote:
> > I'm not sure what you're suggesting ? Maybe I should add some NOTICES
> > there.
>
> Here is one approach that might work: Can you check if the assertion
> added by the att
Peter Geoghegan writes:
> On Tue, Jun 8, 2021 at 5:27 AM Matthias van de Meent
>>> (gdb) p GlobalVisCatalogRels
>>> $57 = {definitely_needed = {value = 926025113}, maybe_needed = {value =
>>> 926025112}}
>> This maybe_needed is older than the OldestXmin, which indeed gives us
>> this problematic
On Tue, Jun 08, 2021 at 08:02:46PM -0400, Bruce Momjian wrote:
> This involves creating an aggreate that _uses_ these array functions as
> their state transition function?
Yes
--
Justin
On Mon, May 10, 2021 at 11:42 PM Euler Taveira wrote:
>
> On Mon, May 10, 2021, at 5:19 AM, Peter Smith wrote:
>
> AFAIK this is the latest patch available, but FYI it no longer applies
> cleanly on HEAD.
>
> Peter, the last patch is broken since f3b141c4825. I'm still working on it for
> the next
On Tue, Jun 8, 2021 at 05:56:18PM -0500, Justin Pryzby wrote:
> @Bruce: Would you add something about this to the release notes before beta2?
>
> I added it as an OpenItem.
OK, see below.
> On Tue, May 25, 2021 at 11:14:58AM -0500, Justin Pryzby wrote:
> > On Thu, May 20, 2021 at 07:35:10PM -04
Mark Dilger writes:
> On Jun 8, 2021, at 3:55 PM, Tom Lane wrote:
>> I suppose that either apply_dispatch or LogicalRepApplyLoop needs to
>> grow some more snapshot management logic, but I've not looked at that
>> code much, so I don't have an opinion on just where to add it.
> I was looking at
On Tue, Jun 8, 2021 at 5:27 AM Matthias van de Meent
wrote:
> > (gdb) p *vacrel
> > $56 = {... OldestXmin = 926025113, ...}
> >
> > (gdb) p GlobalVisCatalogRels
> > $57 = {definitely_needed = {value = 926025113}, maybe_needed = {value =
> > 926025112}}
>
> This maybe_needed is older than the Olde
> On Jun 8, 2021, at 3:55 PM, Tom Lane wrote:
>
> The right way to say that is "commit 84f5c2908da exposed the pre-existing
> unsafe behavior of this code". It's not okay to run arbitrary user code
> without holding a snapshot to protect TOAST dereference operations.
Sure, I didn't expect th
@Bruce: Would you add something about this to the release notes before beta2?
I added it as an OpenItem.
On Tue, May 25, 2021 at 11:14:58AM -0500, Justin Pryzby wrote:
> On Thu, May 20, 2021 at 07:35:10PM -0400, Tom Lane wrote:
> > Justin Pryzby writes:
> > > On Wed, Nov 04, 2020 at 07:43:51PM -
Mark Dilger writes:
> On master, when a statement level trigger is fired for a replicated truncate
> command, the following stack trace is generated:
Hmm.
> I believe the issue was introduced in commit 84f5c2908da which added
> EnsurePortalSnapshotExists. That's not going to work in the case
On Tue, Jun 8, 2021 at 4:03 AM Justin Pryzby wrote:
> postgres=# SELECT lp, lp_off, lp_flags, lp_len, t_xmin, t_xmax, t_field3,
> t_ctid, t_infomask2, t_infomask, t_hoff, t_bits, t_oid FROM
> heap_page_items(pg_read_binary_file('/tmp/dump_block.page'));
> lp | lp_off | lp_flags | lp_len | t_xm
Hackers,
On master, when a statement level trigger is fired for a replicated truncate
command, the following stack trace is generated:
TRAP: FailedAssertion("portal != NULL", File: "pquery.c", Line: 1760, PID:
93854)
0 postgres0x000108e269f2 ExceptionalConditio
On Tue, Jun 8, 2021 at 2:23 PM Justin Pryzby wrote:
> I'm not sure what you're suggesting ? Maybe I should add some NOTICES there.
Here is one approach that might work: Can you check if the assertion
added by the attached patch fails very quickly with your test case?
This does nothing more than
On Tue, 2021-06-08 at 16:08 -0400, Tom Lane wrote:
> Since we don't put LSNs into unlogged tables, nor would the different
> shards be likely to have equivalent LSNs, I'm not seeing that LSN is
> remarkably better for this than a timestamp.
It requires some other bookkeeping on the part of the sha
On Tue, Jun 08, 2021 at 01:52:40PM -0700, Peter Geoghegan wrote:
> On Tue, Jun 8, 2021 at 12:27 PM Justin Pryzby wrote:
> > > They're running this:
> > > | PGOPTIONS="--deadlock_timeout=333ms -cstatement-timeout=3600s" psql -c
> > > "REINDEX INDEX CONCURRENTLY $i"
> > > And if it times out, it th
On Tue, Jun 8, 2021 at 12:27 PM Justin Pryzby wrote:
> > They're running this:
> > | PGOPTIONS="--deadlock_timeout=333ms -cstatement-timeout=3600s" psql -c
> > "REINDEX INDEX CONCURRENTLY $i"
> > And if it times out, it then runs: $PSQL "DROP INDEX CONCURRENTLY $bad"
> ...
> > $ date -d @16231212
On 2021-Jun-08, Justin Pryzby wrote:
> They're all zero except for:
>
> $201 = 1 '\001'
> $202 = 3 '\003'
> $203 = 1 '\001'
>
> src/include/storage/proc.h-#define PROC_IS_AUTOVACUUM 0x01
> /* is it an autovac worker? */
> src/include/storage/proc.h-#define PROC
On Tue, Jun 8, 2021 at 09:13:29AM +0900, Tatsuo Ishii wrote:
> In release-14.sgml:
>
>
>
>
> Remove server and libpq support
> for the version 2 wire protocol
> (Heikki Linnakangas)
>
>
>
> This was last used as the default in Postgres 7.2 (year 2002).
On Tue, Jun 8, 2021 at 12:26 PM Robert Haas wrote:
> I think the problem is here:
>
> Can't locate object method "lsn" via package "PostgresNode" at
> t/025_stuck_on_old_timeline.pl line 84.
>
> When that happens, it bails out, and cleans everything up, doing an
> immediate shutdown of all the nod
On Tue, 2021-06-08 at 17:41 +1000, Ajin Cherian wrote:
> Here's an updated patchset that adds back in the option for two-phase
> in CREATE_REPLICATION_SLOT command and a second patch that adds
> support for
> two-phase decoding in pg_recvlogical.
A few things:
* I suggest putting the TWO_PHASE ke
Jeff Davis writes:
> On Tue, 2021-06-08 at 12:52 -0400, Tom Lane wrote:
>> Yeah. If there are actually use-cases for knowing both things, then
>> we ought to record both. However, it's not real clear to me why
>> LSN would be interesting.
> Let me expand on my use case: in a sharded environment
>
> > So basically where we are dispatching to the CASCADE guts, first check
> session user’s DELETE permission and throw the normal permissions error if
> they can’t delete?
>
> Actually, you also need appropriate SELECT permissions that correspond
> to the WHERE clause of the DELETE statement.
>
On Tue, 2021-06-08 at 12:52 -0400, Tom Lane wrote:
> Yeah. If there are actually use-cases for knowing both things, then
> we ought to record both. However, it's not real clear to me why
> LSN would be interesting.
Let me expand on my use case: in a sharded environment, how do you
figure out if
On Tue, Jun 08, 2021 at 12:34:04PM -0500, Justin Pryzby wrote:
> On Tue, Jun 08, 2021 at 12:06:02PM -0400, Alvaro Herrera wrote:
> > On 2021-Jun-06, Justin Pryzby wrote:
> >
> > > However, I also found an autovacuum chewing 100% CPU, and it appears the
> > > problem is actually because autovacuum
On Mon, Jun 7, 2021 at 2:54 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 05.06.21 14:21, David Christensen wrote:
> >
> >> On Jun 5, 2021, at 2:30 AM, Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> wrote:
> >>
> >> On 03.06.21 22:49, David Christensen wrote:
> >>>
On Tue, Jun 08, 2021 at 11:40:31AM -0700, Peter Geoghegan wrote:
> Reminds me of the other bug that you also reported about a year ago,
> Justin - which was never fixed. The one with the duplicate tids from a cic
> (see pg 14 open item).
>
> Is this essentially the same environment as the one tha
On Tue, Jun 08, 2021 at 02:01:51PM -0400, Alvaro Herrera wrote:
> On 2021-Jun-08, Justin Pryzby wrote:
>
> > On Tue, Jun 08, 2021 at 12:06:02PM -0400, Alvaro Herrera wrote:
> > > On 2021-Jun-06, Justin Pryzby wrote:
> > >
> > > > However, I also found an autovacuum chewing 100% CPU, and it appear
Reminds me of the other bug that you also reported about a year ago,
Justin - which was never fixed. The one with the duplicate tids from a cic
(see pg 14 open item).
Is this essentially the same environment as the one that led to your other
bug report?
Peter Geoghegan
(Sent from my phone)
On 5/31/21 6:01 AM, Bharath Rupireddy wrote:
> On Mon, May 31, 2021 at 1:21 AM Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> I took at this patch today. I did some minor changes, mostly:
>>
>> 1) change the code limiting batch_size from
>>
>> if (fmstate->p_nums > 0 &&
>>(batch_size * fmsta
On 2021-Jun-08, Justin Pryzby wrote:
> On Tue, Jun 08, 2021 at 12:06:02PM -0400, Alvaro Herrera wrote:
> > On 2021-Jun-06, Justin Pryzby wrote:
> >
> > > However, I also found an autovacuum chewing 100% CPU, and it appears the
> > > problem is actually because autovacuum has locked a page of pg-s
On 08.06.21 15:40, David Rowley wrote:
It's almost 2 years ago now, but I'm wondering if you saw what Andres
proposed in [1]? The idea was basically to make a metadata array of
the node structs so that, instead of having to output large amounts of
.c code to do read/write/copy/equals, instead ju
On Tue, Jun 08, 2021 at 12:06:02PM -0400, Alvaro Herrera wrote:
> On 2021-Jun-06, Justin Pryzby wrote:
>
> > However, I also found an autovacuum chewing 100% CPU, and it appears the
> > problem is actually because autovacuum has locked a page of pg-statistic,
> > and
> > every other process then
Hi,
On 2021-06-08 14:27:14 +0200, Matthias van de Meent wrote:
> heap_prune_satisfies_vacuum considers 1 more transaction to be
> unvacuumable, and thus indeed won't vacuum that tuple that
> HeapTupleSatisfiesVacuum does want to be vacuumed.
>
> The new open question is now: Why is
> GlobalVisCat
Robert Haas writes:
> On Mon, Jun 7, 2021 at 11:46 PM Michael Paquier wrote:
>> On Mon, Jun 07, 2021 at 02:56:57PM -0400, Tom Lane wrote:
>>> +1. I'd support recording the time of the last crash recovery, as
>>> well as having a counter. I think an LSN would not be as useful
>>> as a timestamp.
On 08.06.21 04:50, Julien Rouhaud wrote:
On Mon, Jun 07, 2021 at 06:10:58PM -0400, Tom Lane wrote:
I'm fairly disinclined to do anything about it though, because I'm
afraid of the SQL committee standardizing some other syntax for the
same idea in future (or maybe worse, commandeering the same k
On Tue, Jun 8, 2021 at 4:47 AM Dilip Kumar wrote:
> I have changed for as per 9.6 but I am seeing some crash (both
> with/without fix), I could not figure out the reason, it did not
> generate any core dump, although I changed pg_ctl in PostgresNode.pm
> to use "-c" so that it can generate core bu
On 2021-Jun-06, Justin Pryzby wrote:
> However, I also found an autovacuum chewing 100% CPU, and it appears the
> problem is actually because autovacuum has locked a page of pg-statistic, and
> every other process then gets stuck waiting in the planner. I checked a few
> and found these:
> [...]
Julien Rouhaud writes:
> On Mon, Jun 07, 2021 at 03:24:33PM -0400, Tom Lane wrote:
>> Concretely, I think the right fix is per attached.
> +1, I agree that this approach is better.
Pushed.
regards, tom lane
Andrew Dunstan writes:
> On 6/7/21 6:10 PM, Tom Lane wrote:
>> Note that it's not like SQL hasn't heard of projections before.
>> You can always do "SELECT a, b, d FROM subquery-yielding-a-b-c-d".
>> So the proposed syntax would save a small amount of typing, but
>> it's not adding any real new fu
On 2021-06-08 11:49, Michael Paquier wrote:
On Sun, Jun 06, 2021 at 11:13:40AM -0400, Tom Lane wrote:
Julien Rouhaud writes:
However +1 for the patch, as it seems more consistent to always get a
permission failure if you're not a superuser.
Yeah, it's just weird if such a check is not the fi
Michael Paquier writes:
> Now, I also see that using pgwin32_setenv() instead of
> src/port/setenv.c causes cl to be confused once we update
> ecpg_regression.proj because it cannot find setenv(). Bringing the
> question, why is it necessary to have both setenv.c and
> pgwin32_setenv() on HEAD?
On 6/7/21 6:10 PM, Tom Lane wrote:
> "David G. Johnston" writes:
>> On Mon, Jun 7, 2021 at 1:54 PM Mark Zellers
>> wrote:
>>> What if you could use the MINUS keyword in the column
>>> list of a select statement to remove a column from the result set returned
>>> to the client?
>> I asked this a
> But patch that you propose does not support sorting build added in PG14.
It looks like the change to btree_gist is not committed yet. I'll
rebase my patch once it's committed.
It was a long thread. I couldn't read all of it. Though, the last
patches felt to me like a part of what's already b
On Mon, Jun 7, 2021 at 11:33 PM Amit Kapila wrote:
> Note the error is raised after applying the patch, without the patch,
> the above won't show any error (error message could be improved here).
> Such cases can lead to unpredictable behavior without a patch because
> we won't be able to detect t
On 2021-Jun-06, Michael Paquier wrote:
> On Fri, Jun 04, 2021 at 07:21:11PM -0400, Alvaro Herrera wrote:
> The test has been done with four configurations, and here are the
> results:
> 1) HEAD: 9659ms
> 2) REL_13_STABLE: 8310ms.
> 3) Alvaro's patch, as of
> https://postgr.es/m/202106042321.6jx54
On 2021/06/08 11:49, Michael Paquier wrote:
On Sun, Jun 06, 2021 at 11:13:40AM -0400, Tom Lane wrote:
Julien Rouhaud writes:
However +1 for the patch, as it seems more consistent to always get a
permission failure if you're not a superuser.
Yeah, it's just weird if such a check is not the
On 08.06.21 08:54, Michael Paquier wrote:
On Mon, Jun 07, 2021 at 11:34:24AM -0400, Tom Lane wrote:
Yeah, I'd include the empty-string test just because it's standard
practice in this area of libpq. Whether those tests are actually
triggerable in every case is obscure, but ...
Checking after
On Tue, 8 Jun 2021 at 08:28, Peter Eisentraut
wrote:
>
> I wrote a script to automatically generate the node support functions
> (copy, equal, out, and read, as well as the node tags enum) from the
> struct definitions.
Thanks for working on this. I agree that it would be nice to see
improvements
On Mon, Jun 7, 2021 at 11:46 PM Michael Paquier wrote:
> On Mon, Jun 07, 2021 at 02:56:57PM -0400, Tom Lane wrote:
> > +1. I'd support recording the time of the last crash recovery, as
> > well as having a counter. I think an LSN would not be as useful
> > as a timestamp.
>
> One could guess a t
On Tue, Jun 08, 2021 at 02:27:14PM +0200, Matthias van de Meent wrote:
> Thanks for the information!
I created an apparently-complete core file by first doing this:
| echo 127 |sudo tee /proc/22591/coredump_filter
*and updated wiki:Developer_FAQ to work with huge pages
I'm planning to kill the p
On Tue, Jun 8, 2021 at 1:34 PM osumi.takami...@fujitsu.com
wrote:
>
> On Monday, June 7, 2021 6:22 PM Amit Kapila wrote:
> > On Mon, Jun 7, 2021 at 10:44 AM Amit Kapila
> > wrote:
> > >
> > > One more comment is that for HEAD, first just create a patch with
> > > synchronous replication-related
On Tue, 8 Jun 2021 at 14:11, Justin Pryzby wrote:
>
> On Tue, Jun 08, 2021 at 01:54:41PM +0200, Matthias van de Meent wrote:
> > On Tue, 8 Jun 2021 at 13:03, Justin Pryzby wrote:
> > >
> > > On Sun, Jun 06, 2021 at 11:00:38AM -0700, Peter Geoghegan wrote:
> > > > On Sun, Jun 6, 2021 at 9:35 AM Ju
Hi Kyotaro,
I have tried to test your patches. Unfortunately even after applying the
patches
the WAL Sender is still sending too frequent keepalive messages.
In my opinion the fix is to make sure that wal_sender_timeout/2 has passed
before sending
the keepalive message in the code fragment I had sh
On Tue, Jun 08, 2021 at 01:54:41PM +0200, Matthias van de Meent wrote:
> On Tue, 8 Jun 2021 at 13:03, Justin Pryzby wrote:
> >
> > On Sun, Jun 06, 2021 at 11:00:38AM -0700, Peter Geoghegan wrote:
> > > On Sun, Jun 6, 2021 at 9:35 AM Justin Pryzby wrote:
> > > > I'll leave the instance running for
On Tue, 8 Jun 2021 at 13:03, Justin Pryzby wrote:
>
> On Sun, Jun 06, 2021 at 11:00:38AM -0700, Peter Geoghegan wrote:
> > On Sun, Jun 6, 2021 at 9:35 AM Justin Pryzby wrote:
> > > I'll leave the instance running for a little bit before restarting (or
> > > kill-9)
> > > in case someone requests
On Mon, Jun 7, 2021 at 6:45 PM Dilip Kumar wrote:
>>
>>
>> 2. In the test, there seems to be an assumption that we can unlock s2
>> and s3 one after another, and then both will start waiting on s-1 but
>> isn't it possible that before s2 start waiting on s1, s3 completes its
>> insertion and then
On Sun, Jun 06, 2021 at 01:59:10PM -0400, Tom Lane wrote:
> Matthias van de Meent writes:
> > On Sun, 6 Jun 2021 at 18:35, Justin Pryzby wrote:
> >> However, I also found an autovacuum chewing 100% CPU, and it appears the
> >> problem is actually because autovacuum has locked a page of pg-statist
1 - 100 of 116 matches
Mail list logo
