at the feature is desirable, but I think getting there is
> going to require a huge amount of effort that may amount to a total
> rewrite of the patch.
Agreed. I think this needs very fundamental design work, and the patch itself
isn't worth reviewing until that's tackled.
Greetings,
Andres Freund
MT [5504][postmaster] LOG: database system is ready
to accept connections
Greetings,
Andres Freund
Hi,
On 2022-03-04 09:10:14 -0800, Andres Freund wrote:
> > I find it a little suspicious that startcreate is merrily starting
> > the postmaster on port 5432, without concern for the possibility
> > that that port is in use or blocked by a packet filter.
>
> It's a
server is
listening on ::1 as we know from the log, and quite evidently psql is trying
to connect to that too. This output also looked this way before the failures.
pg_regress outputs the above message when neither PGHOST, PGPORT or
--host/--port are set. On windows that nevertheless ends up with connecting to
localhost.
Greetings,
Andres Freund
Hi,
On 2022-03-04 09:30:37 -0800, Andres Freund wrote:
> I wonder if we're missing some steps, at least on windows, to make pg_ctl
> start independent of the starting shell?
Sure looks that way. On windows, if I do pg_ctl start, then hit ctrl-c, the
server shuts down.
Greetings,
Andres Freund
On 2022-03-04 09:46:44 -0800, Andres Freund wrote:
> On 2022-03-04 09:30:37 -0800, Andres Freund wrote:
> > I wonder if we're missing some steps, at least on windows, to make pg_ctl
> > start independent of the starting shell?
>
> Sure looks that way. On windows, if I
Hi,
On 2022-03-04 09:57:35 -0800, Andres Freund wrote:
> On 2022-03-04 09:46:44 -0800, Andres Freund wrote:
> > On 2022-03-04 09:30:37 -0800, Andres Freund wrote:
> > > I wonder if we're missing some steps, at least on windows, to make pg_ctl
> > > start i
Hi,
On 2022-03-04 09:57:35 -0800, Andres Freund wrote:
> On 2022-03-04 09:46:44 -0800, Andres Freund wrote:
> > On 2022-03-04 09:30:37 -0800, Andres Freund wrote:
> > > I wonder if we're missing some steps, at least on windows, to make pg_ctl
> > > start i
Hi,
On 2022-03-05 09:29:01 +1300, Thomas Munro wrote:
> On Sat, Mar 5, 2022 at 7:10 AM Andres Freund wrote:
> > Or perhaps pg_ctl ought to pass CREATE_NEW_PROCESS_GROUP to CreateProcess()?
> > The lack of a process group would explain why we're getting signalled on
> >
Hi,
On 2022-03-04 16:51:32 -0500, Tom Lane wrote:
> Andres Freund writes:
> > That fixed the immediate problem, but dblink, postgres_fdw tests failed:
> > +ERROR: could not establish connection
> > +DETAIL: connection to server at "localhost" (::1), port 543
On 2022-03-04 14:04:44 -0800, Andres Freund wrote:
> Trying to make it use the current user now - I don't know what
> permissions services are needed to run a service as a user or such.
My first attempt of using %USERNAME% failed:
[22:10:20.862] c:\cirrus>call tmp_install\bin\pg_ct
Hi,
On 2022-03-03 22:56:15 -0600, Justin Pryzby wrote:
> On Sun, Feb 20, 2022 at 12:47:31PM -0800, Andres Freund wrote:
> > On 2022-02-20 13:36:55 -0600, Justin Pryzby wrote:
> > > Have you tried to use the yet-to-be-released ccache with MSVC ?
> >
> > Yes, it doe
Hi,
On 2022-03-05 13:21:26 +1300, Thomas Munro wrote:
> On Sat, Mar 5, 2022 at 10:56 AM Andres Freund wrote:
> > I suspect one also needs the console detach thing.
>
> I tried adding DETACHED_PROCESS (which should be like calling
> FreeConsole() in child process
Hi,
On 2022-03-05 16:39:21 +1300, Thomas Munro wrote:
> On Sat, Mar 5, 2022 at 4:19 PM Andres Freund wrote:
> > https://github.com/cirruslabs/cirrus-ci-agent/issues/218#issuecomment-1059657781
>
> Oof. Nice detective work.
Thanks.
> > As indicated in the messag
On 2022-03-04 20:06:43 -0800, Andres Freund wrote:
> On 2022-03-05 16:39:21 +1300, Thomas Munro wrote:
> > I vote for committing that workaround into the tree temporarily,
> > because it's not just cfbot, it's also everyone's dev branches on
> > Github + the off
Hi,
On 2022-03-05 14:14:54 +0530, Bharath Rupireddy wrote:
> I understand. Even if we use the SyncRepWaitForLSN approach, the async
> walsenders will have to do nothing in WalSndLoop() until the sync
> walsender wakes them up via SyncRepWakeQueue.
I still think we should flat out reject this appr
pgrade. Just dumping data isn't going to touch indices at all.
A sequence of
pg_upgrade; amcheck; upgrade all extensions; amcheck;
would make sense.
Greetings,
Andres Freund
Hi,
On 2022-03-07 01:12:07 +0200, Victor Yegorov wrote:
> пн, 7 мар. 2022 г. в 00:34, Andres Freund :
>
> > One thing that's likely worth doing as part of the cross version upgrade
> > test,
> > even if it wouldn't even help in this case, is to run amcheck p
Hi,
On 2022-03-06 17:30:15 -0800, Andres Freund wrote:
> 0003, the removal of code level support for Python 2, is now a good bit bigger
> bigger, due to the removal of the last remnants of the Py2/3 porting layer.
Oh, huh. Something here seems to be broken, causing a crash on windows, b
ill work to squash it into a reasonable
number of patches and then repost that.
Greetings,
Andres Freund
Hi,
On 2022-03-06 10:16:54 -0600, Justin Pryzby wrote:
> On Fri, Mar 04, 2022 at 05:30:03PM -0800, Andres Freund wrote:
> > I tried to use it, but saw that no caching was happening, and debugged
> > it. Which yielded that it can't be used due to the way output files are
>
On 2022-03-07 20:11:52 -0500, Tom Lane wrote:
> This version seems ready-to-go to me, or at least ready to see
> what the buildfarm makes of it.
Pushed. Let's see...
rtability fixes, builds on net/openbsd without changes now
- improvements to a number of "configure" tests
- lots of ongoing rebasing changes
- ...
Greetings,
Andres Freund
v6-0001-meson-prereq-output-and-depencency-tracking-work.patch.gz
Description: application/patch-gzip
binY
On 2022-03-07 09:58:41 -0800, Andres Freund wrote:
> On 2022-03-07 14:56:24 +0100, Peter Eisentraut wrote:
> > Is there a current patch set to review in this thread at the moment?
>
> I've been regularly rebasing and improving the patchset, but didn't post to
> the
Hi,
On 2022-03-07 23:39:39 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-03-07 20:11:52 -0500, Tom Lane wrote:
> >> This version seems ready-to-go to me, or at least ready to see
> >> what the buildfarm makes of it.
>
> > Pushed. Let's see.
;
| ^~~~
It seems we should just remove the use of register? It's currently only used
in
src/include/storage/s_lock.h
src/include/port/atomics/arch-x86.h
>From what I understand compilers essentially have been ignoring it for quite a
while...
Greetings,
Andres Freund
Hi,
On 2022-03-07 20:59:16 -0800, Andres Freund wrote:
> On 2022-03-07 23:39:39 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > wrasse says you were too quick to drop plpython_error_5.out.
>
> Does look like it. I'll try to find a distribution with an old python.
Hi,
On 2022-03-08 13:46:36 -0500, Tom Lane wrote:
> Andres Freund writes:
> > When running cpluspluscheck I get many many complaints like
> > /tmp/pg-test-repo/src/include/port/atomics/arch-x86.h:143:23: warning: ISO
> > C++17 does not allow ‘register’ storage class
Hi,
On 2022-03-08 13:49:15 -0500, Tom Lane wrote:
> Andres Freund writes:
> > A bit depressing to have a 500 line alternative output file for a one line
> > diff :(.
>
> Yeah. How badly do we need that particular test case?
A bit hard to tell. The test was
Hi,
On 2022-03-08 10:42:31 -0800, Andres Freund wrote:
> > crake also failed. Looks like plpy_plpymodule.h needs to include
> > plpython.h. A
> > pre-existing issue that just didn't happen to cause problems...
>
> Fixed that.
Hm. Now crake failed in XversionUpgr
vity,
pg_stat_replication, pg_stat_progress_*, ...) and accumulated stats
(pg_stat_user_tables, pg_stat_database, etc) in the same namespace. Should we
try to move towards something more coherent, at least going forward?
Greetings,
Andres Freund
Hi,
On 2022-03-08 18:15:43 +1300, Thomas Munro wrote:
> I'm now starting to think about committing this soon.
+1
Are you thinking of committing both patches at once, or with a bit of
distance?
I think something in the regression tests ought to enable
recovery_prefetch. 027_stream_regress or 001
On 2022-03-08 15:55:04 -0700, David G. Johnston wrote:
> On Tue, Mar 8, 2022 at 1:54 PM Andres Freund wrote:
> > One thing I'm not yet happy around the shared memory stats patch is
> > naming. Currently a lot of comments say things like:
> >
> > * [...] We co
Hi,
On 2022-03-06 12:27:52 +0530, Bharath Rupireddy wrote:
> On Sun, Mar 6, 2022 at 1:57 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2022-03-05 14:14:54 +0530, Bharath Rupireddy wrote:
> > > I understand. Even if we use the SyncRepWaitForLSN approach, the
Hi,
On 2022-03-08 19:13:45 -0700, David G. Johnston wrote:
> On Tue, Mar 8, 2022 at 6:50 PM Andres Freund wrote:
>
> > On 2022-03-08 15:55:04 -0700, David G. Johnston wrote:
> > > On Tue, Mar 8, 2022 at 1:54 PM Andres Freund wrote:
> > > > One thing I'm
e merrier, although I'm a little bit worried about pointing
> to a /usr/local/share/examples/ directory.
It's where the files are in the package :/.
> v6-0012-wip-split-TESTDIR-into-two.patch.gz
> v6-0013-meson-Add-meson-based-buildsystem.patch.gz
> v6-0014-meson-ci-Build-both
de/storage/lwlocknames.h but has no dependency on it
I wonder if it's worth having a build target invoking it? But how to get the
path to the script? We could just copy it into src/tools? It's permissively
licensed...
Greetings,
Andres Freund
(*) It seems architecturally pretty darn ugly for pgcommon to acquire lwlocks.
e enough difference just for backtraces etc.
I'm far less convinced that using "MaxSpeed" for the msvc build is a good
idea. I've looked at one or two backtraces of optimized msvc builds and
backtraces were quite a bit worse - and they're not great to start with. What
was the win there?
Greetings,
Andres Freund
Hi,
On 2021-10-22 11:55:05 -0400, John Naylor wrote:
> On Thu, Oct 21, 2021 at 5:48 PM Andres Freund wrote:
>
> > However, update-unicode is a bit harder. Partially not directly because
> of
> > meson, but because update-unicode as-is afaict doesn't support VPA
ch...
Yea. I used -ggdb because I didn't know -glldb existed :). And there's also
the advantage that -ggdb works both with gcc and clang, whereas -glldb doesn't
seem to be known to gcc.
Greetings,
Andres Freund
On 2022-03-10 10:43:06 -0500, Andrew Dunstan wrote:
> On 3/6/22 17:33, Andres Freund wrote:
> > One thing that's likely worth doing as part of the cross version upgrade
> > test,
> > even if it wouldn't even help in this case, is to run amcheck post
> > upgr
eficial to shuffle it through
shared buffers, even if we benefit from using s_b for the main fork...
> + /*
> + * If not using shared buffers, for a WAL-logged relation, save the redo
> + * pointer location in case a checkpoint begins during the index build.
> + */
> + if (wstate->_bt_bl_unbuffered_prep)
> + wstate->_bt_bl_unbuffered_prep(&wstate->ub_wstate,
> + wstate->btws_use_wal, wstate->btws_use_wal);
Code would probably look cleaner if an empty callback were used when no
_bt_bl_unbuffered_prep callback is needed.
> /*
> - * allocate workspace for a new, clean btree page, not linked to any
> siblings.
> + * Set up workspace for a new, clean btree page, not linked to any siblings.
> + * Caller must allocate the passed in page.
More interesting bit seems to be whether the passed in page needs to be
initialized?
> @@ -1154,20 +1285,24 @@ _bt_uppershutdown(BTWriteState *wstate, BTPageState
> *state)
>* back one slot. Then we can dump out the page.
>*/
> _bt_slideleft(s->btps_page);
> - _bt_blwritepage(wstate, s->btps_page, s->btps_blkno);
> + wstate->_bt_blwritepage(wstate, s->btps_page, s->btps_blkno,
> s->btps_buf);
> + s->btps_buf = InvalidBuffer;
> s->btps_page = NULL;/* writepage freed the workspace */
> }
Do we really have to add underscores even to struct members? That just looks
wrong.
Greetings,
Andres Freund
ts are a bad idea and should not exist. We repeatedly have
had bugs where we were missing wakeups etc but those bugs were harder to
notice because of timeouts. I'm against entrenching this stuff further.
Greetings,
Andres Freund
warnings_script
>
> I'm not sure how to write this test in windows shell; it's also not easy to
> write it in posix sh, since windows shell is somehow interpretting && and
> ||...
That comment isn't accurate anymore now that it's in an external script,
right?
Greetings,
Andres Freund
On March 10, 2022 9:31:13 PM PST, Thomas Munro wrote:
> The other thing I need to change is that I should turn on
>recovery_prefetch for platforms that support it (ie Linux and maybe
>NetBSD only for now), in the tests.
Could a setting of "try" make sense?
--
Sent from my Android device wi
ll list.
FWIW, this branch I'm a tad more concerned about - it's in a loop body where
plausibly a lot of branches could be outstanding at the same time.
ISTM that this could just be an assert?
Greetings,
Andres Freund
ely GNU tar requires -i to read concated compressed
archives, so perhaps that's not quite an alternative.
Greetings,
Andres Freund
nflict with another
RowExclusiveLock.
What is the AcceptInvalidationMessages() intending to do here?
> + if (runlist == NULL)/* list is still empty,
> so clear the
> +
> * flag */
> + {
> + db->dathasloginevt = false;
> + CatalogTupleUpdate(pg_db,
> &tuple->t_self, tuple);
> + }
> + else
> + CacheInvalidateRelcacheByTuple(tuple);
Copy of the bogus relcache stuff.
Greetings,
Andres Freund
ariable numbered stats
individiually resettable is a bad idea.
Greetings,
Andres Freund
On 2022-03-11 10:38:22 +0300, Aleksander Alekseev wrote:
> > Here is an updated patch that includes the commit message.
>
> Since this is a trivial change and no one seems to object to it so far, I'm
> going to re-check the patch against the recent `master` and change its
> status to "Ready for Co
Hi,
On 2020-10-29 16:10:37 -0700, Andres Freund wrote:
> I run my development instances with track_io_timing=on, as I've found
> that to be really useful. Unfortunately that causes tests to fail
> whenever I forget to turn that off to run installcheck.
>
> The diffs are caus
Hi,
On 2022-03-13 23:31:03 +0100, Daniel Gustafsson wrote:
> > On 12 Mar 2022, at 03:46, Andres Freund wrote:
>
> >> +
> >> + The login event occurs when a user logs in to the
> >> + system.
> >> + Any bugs in a trigger pr
Hi,
On 2022-03-13 19:57:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-03-13 23:31:03 +0100, Daniel Gustafsson wrote:
> >> Something like a '-c ignore_event_trigger=' GUC perhaps?
>
> > Did you mean login instead of event?
>
> > So
On 2022-03-13 20:35:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I was thinking that the way to use it would be to specify it as a client
> > option. Like PGOPTIONS='-c ignore_event_trigger=login' psql.
>
> Ugh ... that would allow people (at least su
Hi,
On 2022-03-14 14:47:09 +0100, Daniel Gustafsson wrote:
> > On 14 Mar 2022, at 01:08, Andres Freund wrote:
>
> > I was thinking that the way to use it would be to specify it as a client
> > option. Like PGOPTIONS='-c ignore_event_trigger=login' psql.
>
&
wait for more data to arrive.
Greetings,
Andres Freund
ore data per
> + * buffer than can be handled by the physical record format.
> + */
> + if (unlikely(num_rdatas >= max_rdatas ||
> + regbuf->rdata_len + len > UINT16_MAX))
> elog(ERROR, "too much WAL data");
> +
> rdata = &rdatas[num_rdatas++];
Given the repeated check it might be worth to just put it in a static inline
used from the relevant places (which'd generate less code because the same
line number would be used for all the checks).
Greetings,
Andres Freund
Hi
On March 15, 2022 6:25:09 PM PDT, Kyotaro Horiguchi
wrote:
>Hello, this is a derived topic from [1], summarized as $SUBJECT.
>
>This just removes useless hyphens from the words
>"(crash|emergency)-recovery". We don't have such wordings for "archive
>recovery" This patch fixes non-user-facing
Hi,
On March 15, 2022 8:16:58 PM PDT, "zk.wang" wrote:
>Generally, we should define struct in the header file(.h).
Why? It's perfectly sensible to define types in .c files when they're not used
elsewhere.
Greetings,
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevi
ou see the problems?
Only stuff tying into transport encryption is clearly not doable via the
proposed API, but that's hardly the fault of an authentication API?
Greetings,
Andres Freund
Hi,
On 2022-03-17 14:03:31 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> > > Looking at the existing authentication methods
> > >
> > > # METHOD can be "trust"
On 2022-03-16 18:50:23 -0400, Stephen Frost wrote:
> First, let's be clear- we aren't actually talking about custom or
> pluggable authentication here, at least when it comes to PG as a
> project. For it to actually be pluggable, it needs to be supported on
> both the client side and the server si
ed. See
https://cirrus-ci.com/task/6194007767252992?logs=test_world#L378
So it looks like older ICU versions don't work?
Greetings,
Andres Freund
PS: I had not yet passed with_icu in the initdb tests for meson, that's why
there's two failures with autoconf but only one with meson.
t (although the protocol likely can be fairly
generic).
Given that there's benefit from the server side extensibility alone, I don't
see much benefit in tying the server side extensibility to the client side
extensibility.
Greetings,
Andres Freund
Hi,
On 2022-03-18 00:03:37 -0400, Stephen Frost wrote:
> On Thu, Mar 17, 2022 at 23:25 Andres Freund wrote:
> > It's imo a separate project to make the client side extensible. There's
> > plenty
> > of authentication methods that don't need any further
ters.
I'm not talking about going ahead and committing. Just not continuing
discussing this topci and spending my time more fruitfully on something else.
Greetings,
Andres Freund
Hi,
On 2022-03-18 15:23:21 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2022-03-18 00:45:49 -0400, Stephen Frost wrote:
> > > > I also don’t think that I agree that it’s acceptable to only have the
> > > > > ability to ext
Hi,
On 2022-03-18 00:28:37 -0700, Noah Misch wrote:
> On Tue, Feb 15, 2022 at 08:58:56AM -0800, Andres Freund wrote:
> > Pushed the test yesterday evening, after Tom checked if it is likely to be
> > problematic. Seems to worked without problems so far.
>
> wrasse
ide of pg_locale.c. There might be an argument for
moving *more* into such a function though.
Greetings,
Andres Freund
Hi,
Pushed 0001, 0002. Only change I made was to add
DEBIAN_FRONTEND=noninteractive to the apt-get invocations, because some
packages will fail / complain verbosely if there's no interactive prompt
during installation.
Greetings,
Andres Freund
removed=" UINT64_FORMAT ", synced=" UINT64_FORMAT ",
> time=%ld.%03d s, cutoff LSN=%X/%X"),
> +
> CheckpointStats.repl_map_files_rmvd_cnt,
> +
> CheckpointStats.repl_map_files_syncd_cnt,
> + t_msecs / 1000, (int)
> (t_msecs % 1000),
> +
> LSN_FORMAT_ARGS(CheckpointStats.repl_map_cutoff_lsn));
> + }
> +
> + ereport(LOG, errmsg_internal("%s", logmsg.data));
> + pfree(logmsg.data);
> }
This practically doubles the size of the log message - doesn't that seem a bit
disproportionate? Can we make this more dense? "logical decoding rewrite
mapping file(s) removed=" and "logical decoding snapshot file(s) removed=" is
quite long.
Greetings,
Andres Freund
ps://www.postgresql.org/message-id/CAJ7c6TPDOYBYrnCAeyndkBktO0WG2xSdYduTF0nxq%2BvfkmTF5Q%40mail.gmail.com
Greetings,
Andres Freund
uff gets
touched, perhaps worth moving to uint64 instead?
https://www.postgresql.org/message-id/20220318231430.m5g56yk4ztlz2man%40alap3.anarazel.de
Greetings,
Andres Freund
refactoring
FWIW, 0006 still does way way too many things at once, even with 0001-0003
split out. I don't really see a point in reviewing / posting new versions
until that's done.
Greetings,
Andres Freund
t;set-valued function called in context
> that cannot accept a set")));
> + if (!(rsinfo->allowedModes & SFRM_Materialize))
> + ereport(ERROR,
> + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> + errmsg("materialize mode required, but it is
> not allowed in this context")));
> +
> + /* Build a tuple descriptor for our result type. */
> + if (get_call_result_type(fcinfo, NULL, &tupdesc) != TYPEFUNC_COMPOSITE)
> + elog(ERROR, "return type must be a row type");
> +
> + /* Build tuplestore to hold the result rows. */
> + per_query_ctx = rsinfo->econtext->ecxt_per_query_memory;
> + oldcontext = MemoryContextSwitchTo(per_query_ctx);
> + tupstore = tuplestore_begin_heap(true, false, work_mem);
> + rsinfo->returnMode = SFRM_Materialize;
> + rsinfo->setResult = tupstore;
> + rsinfo->setDesc = tupdesc;
This should likely use the infrastructure introduced in
5b81703787bfc1e6072c8e37125eba0c5598b807.
> + for (;;)
> + {
> + (void) ReadNextXLogRecord(xlogreader, first_record);
> +
> + /*
> + * Let's not show the record info if it is spanning more than
> the
> + * end_lsn. EndRecPtr is "end+1" of the last read record, hence
> + * use "end" here.
> + */
> + if ((xlogreader->EndRecPtr - 1) <= end_lsn)
> + {
> + GetXLogRecordInfo(xlogreader, xlogreader->currRecPtr,
> values, nulls,
> +
> PG_GET_WAL_RECORDS_INFO_COLS);
> +
> + tuplestore_putvalues(tupstore, tupdesc, values, nulls);
> + }
> +
> + /* Exit loop if read up to end_lsn. */
> + if (xlogreader->EndRecPtr >= end_lsn)
> + break;
Seems weird to have both of these conditions separately.
Greetings,
Andres Freund
│ length │ pg_column_size │
├───┼┼┤
│ pg_stat_progress_checkpoint │ 43290 │ 5409 │
│ pg_stat_progress_create_index │ 23293 │ 4177 │
│ pg_stat_progress_cluster │ 18390 │ 3704 │
│ pg_stat_progress_analyze │ 16121 │ 3339 │
│ pg_stat_progress_vacuum │ 16076 │ 3392 │
│ pg_stat_progress_copy │ 15124 │ 3080 │
│ pg_stat_progress_basebackup │ 8406 │ 2094 │
└───┴┴┘
(7 rows)
pg_rewrite without pg_stat_progress_checkpoint: 745472, with: 753664
pg_rewrite is the second biggest relation in an empty database already...
template1[1164827][1]=# SELECT relname, pg_total_relation_size(oid) FROM
pg_class WHERE relkind = 'r' ORDER BY 2 DESC LIMIT 5;
┌┬┐
│relname │ pg_total_relation_size │
├┼┤
│ pg_proc│1212416 │
│ pg_rewrite │ 745472 │
│ pg_attribute │ 704512 │
│ pg_description │ 630784 │
│ pg_collation │ 409600 │
└┴┘
(5 rows)
Greetings,
Andres Freund
der;
| ^~~
I'd fixed that for nearby variables in 3f6b3be39ca9... Gonna just NULL
initialize it as well.
Greetings,
Andres Freund
Hi,
On 2022-03-04 22:01:22 -0800, Andres Freund wrote:
> On 2022-03-04 20:06:43 -0800, Andres Freund wrote:
> > On 2022-03-05 16:39:21 +1300, Thomas Munro wrote:
> > > I vote for committing that workaround into the tree temporarily,
> > > because it's not just
ore annoying to work with for
reviewers.
It's somewhat annoying. If you e.g. append a few graphs of performance changes
and a patch it's pretty easy to get into the range where compressing won't
help anymore.
And sure, any limit may be hit by somebody. But 1MB across the whole email
seems pretty low these days.
Greetings,
Andres Freund
On 2022-03-19 11:16:48 -0700, Andres Freund wrote:
> Cirrus now provides a way to get the old behaviour back without pinning an old
> agent version. See attached
I've pushed that now. If we can come up with a better recipe for starting
postgres in the background, cool. But until then...
Hi,
On 2022-03-20 11:03:38 +0100, Peter Eisentraut wrote:
> committed
Thanks. Rebasing over that fixed the meson Centos 7 build in my meson
tree. https://cirrus-ci.com/build/5265480968568832
Greetings,
Andres Freund
S)
Should we revoke stats for this one from PUBLIC (similar to the reset
functions)?
> +# Set track_functions to all on standby
> +$node_standby->append_conf('postgresql.conf', "track_functions = 'all'");
That should already be set, cloning from the primary includ
t failures be encountered without such an elaborate setup? If not,
then I don't really see why we need to do anything here?
Greetings,
Andres Freund
build: 22:21 min
meson w/ ninja: 19:24
meson runs quite a few tests that the "current buildsystem" doesn't, so the
win is actually bigger than the time difference indicates...
Greetings,
Andres Freund
the timeout based "scheduling
iterations", but perhaps at a lower frequency?
Greetings,
Andres Freund
e task inside the
circle, instead of the "check" and x. Right now the letters are unique.
Greetings,
Andres Freund
Hi,
On 2022-03-21 11:27:15 +0530, Bharath Rupireddy wrote:
> On Sat, Mar 19, 2022 at 4:39 AM Andres Freund wrote:
> >
> > before we further change this (as done in this patch) we should deduplicate
> > these huge statements in a separate patch / commit.
>
> Someth
ance of using IOS etc.
Yea. Even just avoid avoiding SPI / planner + executor seems likely to be a
big win.
It seems one more of the cases where we really need logic to recognize "cheap"
vs "expensive" plans, so that we only do sampling when useful. I don't think
that's solved just by having a declarative syntax.
Greetings,
Andres Freund
On 2022-01-14 11:25:45 -0500, Tom Lane wrote:
> Julien Rouhaud writes:
> > Like many I previously had to investigate a slowdown due to sub-transaction
> > overflow, and even with the information available in a monitoring view (I
> > had
> > to rely on a quick hackish extension as I couldn't patch
_world#L21
Looks like something around isolationtester is broken?
Unfortunately there's no useful backtraces for isolationtester. Not sure
what's up there.
Seems like we might not have energy to push this forward in the next two
weeks, so maybe the CF entry should be marked returned or moved for now?
Greetings,
Andres Freund
Hi,
On 2022-03-07 13:10:32 +0100, Magnus Hagander wrote:
> Meanwhile here is an updated based on your other comments above, as
> well as those from Julien.
This fails on cfbot, due to compiler warnings:
https://cirrus-ci.com/task/5127667648299008?logs=mingw_cross_warning#L390
Greetings,
On 2021-06-07 16:16:58 +0500, Andrey Lepikhov wrote:
> Second version of the patch fixes problems detected by the FDW regression
> tests and shows differences of error reports in tuple-by-tuple and batched
> COPY approaches.
Patch doesn't apply and likely hasn't for a while...
On 2022-02-13 19:34:05 +0530, vignesh C wrote:
> Thanks for the comments, the attached v14 patch has the changes for the same.
The patch needs a rebase, it currently fails to apply:
http://cfbot.cputube.org/patch_37_2957.log
_2490.log
Greetings,
Andres Freund
Hi,
On 2022-03-10 17:42:14 +, Simon Riggs wrote:
> Shall I set this as Ready For Committer?
Currently this CF entry fails on cfbot:
https://cirrus-ci.com/task/4531771134967808?logs=test_world#L1158
[16:27:35.772] # Failed test 'no parameters missing from
postgresql.conf.sample'
[16:27:35
Hi,
On 2022-01-25 19:21:01 +0800, Julien Rouhaud wrote:
> I rebased the pathset in attached v9. Please double check that I didn't miss
> anything in the rebase.
Fails to apply at the moment: http://cfbot.cputube.org/patch_37_2947.log
Marked as waiting for author.
- Andres
On 2022-02-28 18:08:48 -0500, Tom Lane wrote:
> =?UTF-8?B?U29maWEgS29waWtvdmE=?= writes:
> > ACL lists in tables may potentially be large in size. I suggest adding
> > TOAST support for system tables, namely pg_class, pg_attribute and
> > pg_largeobject_metadata, for they include ACL columns.
>
Hi,
On 2022-02-04 10:58:24 +0100, Sergey Dudoladov wrote:
> Thank you for the contribution. I included both of your diffs with
> minor changes.
This currently doesn't apply: http://cfbot.cputube.org/patch_37_3405.log
Could you rebase? Marking as waiting on author for now.
- Andres
Hi,
On 2022-02-19 11:06:18 -0500, Melanie Plageman wrote:
> v21 rebased with compile errors fixed is attached.
This currently doesn't apply (mea culpa likely):
http://cfbot.cputube.org/patch_37_3272.log
Could you rebase? Marked as waiting-on-author for now.
- Andres
Hi,
On 2022-02-25 19:44:27 +0300, Melih Mutlu wrote:
> I've been working on adding Windows+MinGW environment into cirrus-ci tasks
> (discussion about ci is here [1]).
This doesn't apply anymore: http://cfbot.cputube.org/patch_37_3575.log
Could you rebase?
Greetings,
Andres Freund
101 - 200 of 9854 matches
Mail list logo
