On Wed, 22 Dec 2021 at 11:35, Simon Riggs wrote:
>
> On Mon, 15 Nov 2021 at 22:45, Alvaro Herrera wrote:
> >
> > On 2021-Nov-15, Alvaro Herrera wrote:
> >
> > > Thanks everyone for the feedback. I attach a version with the fixes
> > > that were submitted, as well as some additional changes:
> >
On Sun, Jan 02, 2022 at 01:34:45PM -0800, Andres Freund wrote:
> The tests don't seem to pass on windows:
> https://cirrus-ci.com/task/5412456754315264?logs=test_bin#L47
> https://api.cirrus-ci.com/v1/artifact/task/5412456754315264/tap/src/bin/pg_ctl/tmp_check/log/regress_log_004_logrotate
>
>
On Wednesday, January 5, 2022 2:45 PM Amit Kapila
wrote:
>
> On Wed, Jan 5, 2022 at 11:04 AM Peter Smith
> wrote:
> >
> >
> > 11. src/backend/utils/cache/relcache.c - GetRelationPublicationActions
> >
> > Something seemed slightly fishy with the code doing the memcpy,
> > because IIUC is
Thomas Munro writes:
> On Wed, Jan 5, 2022 at 2:49 AM Dag Lem wrote:
>> However I guess this won't make any difference wrt. actually running the
>> tests, as long as there seems to be an encoding problem in the cfbot
>
> Fixed -- I told it to pull down patches as binary, not text. Now it
>
On Wed, Jan 5, 2022 at 11:04 AM Peter Smith wrote:
>
>
> 11. src/backend/utils/cache/relcache.c - GetRelationPublicationActions
>
> Something seemed slightly fishy with the code doing the memcpy,
> because IIUC is possible for the GetRelationPublicationInfo function
> to return without setting
At Tue, 28 Dec 2021 12:28:07 +0530, Bharath Rupireddy
wrote in
> On Wed, Dec 15, 2021 at 8:32 AM Kyotaro Horiguchi
> wrote:
> > > Here's the patch that adds a LOG message whenever a replication slot
> > > becomes active and inactive. These logs will be extremely useful on
> > > production
Thank you for the new patch!
On 2021-12-15 15:40, kuroda.hay...@fujitsu.com wrote:
Dear Kato-san,
Thank you for giving comments! And sorry for late reply.
I rebased my patches.
Even for local-only transaction, I thought it useless to execute
CallCheckingRemoteServersCallbacks() and
On Tue, Jan 4, 2022 at 9:58 AM Peter Smith wrote:
>
> Here is the v58* patch set:
>
> Main changes from v57* are
> 1. Couple of review comments fixed
>
> ~~
>
> Review comments (details)
> =
>
> v58-0001 (main)
> - PG docs updated as suggested [Alvaro, Euler 26/12]
>
>
On Wed, Dec 22, 2021 at 5:26 AM Peter Smith wrote:
>
> On Mon, Dec 20, 2021 at 9:30 PM Amit Kapila wrote:
> >
> > On Mon, Dec 20, 2021 at 8:41 AM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > Thanks for the comments, I agree with all the comments.
> > > Attach the V49 patch set, which addressed
On Thu, Dec 9, 2021 at 7:34 PM Himanshu Upadhyaya
wrote:
> 3)
> Is not that result of the two below queries should match because both are
> trying to retrieve the information from the JSON object.
>
> postgres=# SELECT JSON_OBJECT('track' VALUE '{
> "segments": [
> {
>
On Wednesday, January 5, 2022 9:31 AM Michael Paquier
wrote:
> On Fri, Dec 24, 2021 at 01:27:26PM +, houzj.f...@fujitsu.com wrote:
> > Here is the perf result of pgoutput_change after applying the patch.
> > I didn't notice something else that stand out.
> >
> >
On 2021/12/30 21:15, Maxim Orlov wrote:
Hi, hackers!
Long time wraparound was a really big pain for highly loaded systems. One
source of performance degradation is the need to vacuum before every wraparound.
And there were several proposals to make XIDs 64-bit like [1], [2], [3] and [4]
to
On Wed, Jan 5, 2022 at 4:34 PM Peter Smith wrote:
>
> I have reviewed again the source code for v58-0001.
>
> Below are my review comments.
>
> Actually, I intend to fix most of these myself for v59*, so this post
> is just for records.
>
> v58-0001 Review Comments
>
>
>
I have reviewed again the source code for v58-0001.
Below are my review comments.
Actually, I intend to fix most of these myself for v59*, so this post
is just for records.
v58-0001 Review Comments
1. doc/src/sgml/ref/alter_publication.sgml - reword for consistency
+
On Tue, Jan 4, 2022 at 12:15 PM Peter Smith wrote:
>
> On Fri, Dec 31, 2021 at 12:39 AM houzj.f...@fujitsu.com
> wrote:
> > > 3) v55-0002
> > > +static bool pgoutput_row_filter_update_check(enum
> > > ReorderBufferChangeType changetype, Relation relation,
> > > +
> > >HeapTuple oldtuple,
On Tue, Jan 04, 2022 at 09:06:48PM -0600, Justin Pryzby wrote:
> I think pg_get_guc_flags() may be best, but I'm interested to hear other
> opinions.
My opinion on this matter is rather close to what you have here with
handling things through one extra attribute. But I don't see the
point of
On Wed, Jan 5, 2022 at 10:24 AM Bharath Rupireddy
wrote:
>
> Hi,
>
> Postgres server emits a message at DEBUG1 level when it skips a
> checkpoint. At times, developers might be surprised after figuring out
> from server logs that there were no checkpoints happening at all
> during a certain
"Andrey V. Lepikhov" writes:
> On 1/5/22 4:02 AM, Tom Lane wrote:
>> I've been saying from day one that pushing the query-hashing code into the
>> core was a bad idea, and I think this patch perfectly illustrates why.
> +1.
> Let me suggest, that the core should allow an extension at least to
04.01.2022 22:19, Tom Lane wrote:
> Alexander Lakhin writes:
>> While testing the index-only scan fix, I've discovered that replacing
>> the index-only scan with the index scan changes contrib/btree_gist
>> output because index-only scan for btree_gist returns a string without
>> padding.
> Ugh,
Hi,
Postgres server emits a message at DEBUG1 level when it skips a
checkpoint. At times, developers might be surprised after figuring out
from server logs that there were no checkpoints happening at all
during a certain period of time when DEBUG1 messages aren't captured.
How about emitting the
On 1/5/22 4:02 AM, Tom Lane wrote:
Dmitry Dolgov <9erthali...@gmail.com> writes:
And now for something completely different, here is a new patch version.
It contains a small fix for one problem we've found during testing (one
path code was incorrectly assuming find_const_walker results).
I've
On Wed, Jan 5, 2022 at 9:01 AM Amit Kapila wrote:
>
> On Mon, Dec 27, 2021 at 9:54 AM Masahiko Sawada wrote:
>
> Do you mean to say that you want to omit it even when we are
> committing the changes?
>
> > Apart from that, I'm vaguely concerned that the logic seems to be
> > getting complex.
On Mon, Dec 27, 2021 at 9:54 AM Masahiko Sawada wrote:
>
> On Thu, Dec 16, 2021 at 2:42 PM Masahiko Sawada wrote:
> >
> > On Thu, Dec 16, 2021 at 2:21 PM Amit Kapila wrote:
> > >
> > > On Thu, Dec 16, 2021 at 10:37 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Thu, Dec 16, 2021 at 11:43
Greetings,
On Tue, Jan 4, 2022 at 18:56 Jacob Champion wrote:
> On Mon, 2022-01-03 at 19:42 -0500, Stephen Frost wrote:
> > * Jacob Champion (pchamp...@vmware.com) wrote:
> > >
> > > That last point was my motivation for the authn_id patch [1] -- so that
> > > auditing could see the actual user
>
> currently a failed cast throws an error. It would be useful to have a
> way to get a default value instead.
>
I've recently encountered situations where this would have been helpful.
Recently I came across some client code:
CREATE OR REPLACE FUNCTION is_valid_json(str text) RETURNS boolean
On Wed, Jan 05, 2022 at 11:47:57AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 28 Dec 2021 20:32:40 -0600, Justin Pryzby
> wrote in
> > On Thu, Dec 09, 2021 at 09:53:23AM -0600, Justin Pryzby wrote:
> > > On Thu, Dec 09, 2021 at 05:17:54PM +0900, Michael Paquier wrote:
> > > One option is to
On Tue, Jan 4, 2022 at 5:31 PM Tom Lane wrote:
>
> Greg Nancarrow writes:
> > The patch LGTM.
> > I have set the status to "Ready for Committer".
>
> I don't really see why this patch is even a little bit safe.
> The argument for it seems to be that a lateral subquery will
> necessarily be
On Tue, Jan 4, 2022 at 9:00 AM Masahiko Sawada wrote:
>
> According to the doc, the two_phase field has:
>
> True if the slot is enabled for decoding prepared transactions. Always
> false for physical slots.
>
> It's unnatural a bit to me that replication slots have such a property
> since the
At Tue, 28 Dec 2021 20:32:40 -0600, Justin Pryzby wrote
in
> On Thu, Dec 09, 2021 at 09:53:23AM -0600, Justin Pryzby wrote:
> > On Thu, Dec 09, 2021 at 05:17:54PM +0900, Michael Paquier wrote:
> > One option is to expose the GUC flags in pg_settings, so this can all be
> > done
> > in SQL
On Tue, Jan 04, 2022 at 10:47:47AM -0300, Fabrízio de Royes Mello wrote:
> I used it in the past during a major upgrade process from 9.2 to 9.6.
>
> What we did was decode the 9.6 wal files and apply transactions to the
> old 9.2 to keep it in sync with the new promoted version. This was our
>
On Thu, Jan 4, 2022 at 00:54 PM Peter Smith wrote:
> Modified in v58 [1] as suggested
Thanks for updating the patches.
A few comments about v58-0001 and v58-0002.
v58-0001
1.
How about modifying the following loop in copy_table by using for_each_from
instead of foreach?
Like the invocation of
On Fri, Dec 24, 2021 at 01:27:26PM +, houzj.f...@fujitsu.com wrote:
> Here is the perf result of pgoutput_change after applying the patch.
> I didn't notice something else that stand out.
>
> |--2.99%--pgoutput_change
> |--1.80%--get_rel_sync_entry
>
On Tue, Jan 04, 2022 at 06:10:07PM +0100, Erik Rijkers wrote:
> The replacement is a ~200 euro pdf (2021). I'd be thankful if someone would
> send the pdf to me; maybe I can update my JSON tests.
>
> And we should remove that entry from the bibliography (or have it point to
> the new page [1]).
On 2021-12-23 15:33:35 +0900, Kyotaro Horiguchi wrote:
> At Thu, 23 Dec 2021 15:01:41 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > I added TAP test to excecise the in-place persistence change.
>
> We don't need a base table for every index. TAP test revised.
The tap tests seems to fail on all
Hi,
On 2021-06-27 19:55:24 +0200, Tomas Vondra wrote:
> estimating joins is one of the significant gaps related to extended
> statistics, and I've been regularly asked about what we might do about
> that. This is an early experimental patch that I think might help us
> with improving this,
On Mon, 2022-01-03 at 19:42 -0500, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> >
> > That last point was my motivation for the authn_id patch [1] -- so that
> > auditing could see the actual user _and_ the generic role. The
> > information is already there to be used,
On 2022-01-01 18:21:06 +0100, Tomas Vondra wrote:
> Here's an updated patch, rebased and fixing a couple typos reported by
> Justin Pryzby directly.
FWIW, cfbot reports a few compiler warnings:
https://cirrus-ci.com/task/6067262669979648?logs=gcc_warning#L505
[18:52:15.132] time make -s
Dmitry Dolgov <9erthali...@gmail.com> writes:
> And now for something completely different, here is a new patch version.
> It contains a small fix for one problem we've found during testing (one
> path code was incorrectly assuming find_const_walker results).
I've been saying from day one that
Hi,
For genam.c:
+ UseDirtyCatalogSnapshot = dirtysnap;
+
Does the old value of UseDirtyCatalogSnapshot need to be restored at the
end of the func ?
+systable_recheck_tuple(SysScanDesc sysscan, HeapTuple tup, bool dirtysnap)
Considering that parameter dirtysnap is a bool, I think it should
On Thu, 2021-12-16 at 18:44 +, Jacob Champion wrote:
> It sounds like both you and Andrew might be comfortable with that same
> behavior? I think it looks like a sane solution, so I'll implement that
> and we can see what it looks like. (My work on this will be paused over
> the end-of-year
Greg Nancarrow writes:
> The patch LGTM.
> I have set the status to "Ready for Committer".
I don't really see why this patch is even a little bit safe.
The argument for it seems to be that a lateral subquery will
necessarily be executed in such a way that each complete iteration
of the subquery,
On 1/4/22, 2:35 PM, "Stephen Frost" wrote:
>>
>>Not saying that I've got any idea how to fix that case offhand, and we
>>don't really support such a thing today as the server would just stop
>>instead, ...
>> Perhaps that's a
>> worthwhile tradeoff for being able to generally
Richard Guo writes:
> On Mon, Nov 22, 2021 at 12:52 PM Bharath Rupireddy <
> bharath.rupireddyforpostg...@gmail.com> wrote:
>> Thanks. The patch looks good to me. Let's add it to the commitfest to
>> not lose track of it.
> Done. Here it is:
> https://commitfest.postgresql.org/36/3424/
Pushed,
On Tue, Jan 4, 2022 at 3:56 PM Tom Lane wrote:
>
> "Bossart, Nathan" writes:
> > On 11/12/21, 12:34 PM, "Joshua Brindle"
> > wrote:
> >> All of these and also adminpack.sgml updated. I think that is all of
> >> them but docs broken across lines and irregular wording makes it
> >> difficult.
>
Peter Eisentraut writes:
> On 06.12.21 12:15, Michael Paquier wrote:
>> FWIW, I am not on board with changing build semantics or any
>> assumptions the header installation relies on either, but I could see
>> a point in switching back to INSTALL_DATA instead of cp to be
>> consistent with the
"Bossart, Nathan" writes:
> On 11/12/21, 12:34 PM, "Joshua Brindle"
> wrote:
>> All of these and also adminpack.sgml updated. I think that is all of
>> them but docs broken across lines and irregular wording makes it
>> difficult.
> LGTM. I've marked this as ready-for-committer.
This needs
On Tue, Jan 4, 2022 at 3:39 PM Mark Dilger wrote:
>
>
>
> > On Jan 4, 2022, at 9:07 AM, Mark Dilger
> > wrote:
> >
> > No, that looks like a bug.
>
> I was able to reproduce that using REASSIGN OWNED BY to cause a user to own
> itself. Is that how you did it, or is there yet another way to
Justin Pryzby writes:
> I suggest to move the function in a separate 0001 commit, which makes no code
> changes other than moving from one file to another.
> A committer would probably push them as a single patch, but this makes it
> easier to read and review the changes in 0002.
Yeah, I agree
> On Jan 4, 2022, at 9:07 AM, Mark Dilger wrote:
>
> No, that looks like a bug.
I was able to reproduce that using REASSIGN OWNED BY to cause a user to own
itself. Is that how you did it, or is there yet another way to get into that
state?
—
Mark Dilger
EnterpriseDB:
On Wed, Jan 5, 2022 at 2:49 AM Dag Lem wrote:
> However I guess this won't make any difference wrt. actually running the
> tests, as long as there seems to be an encoding problem in the cfbot
Fixed -- I told it to pull down patches as binary, not text. Now it
makes commits that look healthier,
On Tue, 4 Jan 2022 at 16:15, Tom Lane wrote:
>
> Alvaro Herrera writes:
> > Pushed, thanks Simon for reporting this problem.
And causing another; my bad, apologies.
> Umm ...
>
>Assert(TM_WouldBlock || !(tuple->t_data->t_infomask &
> HEAP_XMAX_INVALID));
>
> AFAICS, this assertion
Greetings,
* Maxim Orlov (orlo...@gmail.com) wrote:
> Long time wraparound was a really big pain for highly loaded systems. One
> source of performance degradation is the need to vacuum before every
> wraparound.
> And there were several proposals to make XIDs 64-bit like [1], [2], [3] and
> [4]
Alexander Lakhin writes:
> While testing the index-only scan fix, I've discovered that replacing
> the index-only scan with the index scan changes contrib/btree_gist
> output because index-only scan for btree_gist returns a string without
> padding.
Ugh, yeah. This seems to be because
04.01.2022 18:33, Tom Lane wrote:
> Alexander Lakhin writes:
>> It's hardly that important, but we (Postgres Pro) run this test
>> regularly to check for primary-standby compatibility. It's useful when
>> checking binary packages from different minor versions. For example, we
>> setup
On master, doc/src/sgml/biblio.sgml has a biblioentry for a pdf from ISO:
"Information technology — Database languages — SQL Technical Reports —
Part SQL Notation support 6: (JSON) for JavaScript Object"
That pdf was a 2017 edition but the url now points to .zip that no
longer exists.
The
> On Jan 4, 2022, at 6:35 AM, Joshua Brindle
> wrote:
>
> I just ran across this and I don't know if it is intended behavior or
> not
> postgres=> \password
> Enter new password for user "brindle":
> Enter it again:
> ERROR: role "brindle" with OID 16384 owns itself
No, that looks like
On Tue, Jan 04, 2022 at 11:15:30AM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Pushed, thanks Simon for reporting this problem.
>
> Umm ...
>
>Assert(TM_WouldBlock || !(tuple->t_data->t_infomask &
> HEAP_XMAX_INVALID));
>
> AFAICS, this assertion condition is constant-true,
On Thu, Nov 25, 2021 at 5:54 PM Bharath Rupireddy
wrote:
>
> On Thu, Nov 25, 2021 at 3:49 PM Bharath Rupireddy
> wrote:
> > >
> > > Thanks all. Here's the v1 patch set for the new extension pg_walinspect.
> > > Note that I didn't include the documentation part now, I will be doing it
> > > a
Alvaro Herrera writes:
> Pushed, thanks Simon for reporting this problem.
Umm ...
Assert(TM_WouldBlock || !(tuple->t_data->t_infomask &
HEAP_XMAX_INVALID));
AFAICS, this assertion condition is constant-true,
because TM_WouldBlock is a nonzero constant. Perhaps you meant
On 2022-Jan-04, Alvaro Herrera wrote:
> On 2022-Jan-03, Alvaro Herrera wrote:
>
> > What I don't understand is why hasn't this been reported already: this
> > bug is pretty old. My only explanation is that nobody runs sufficiently-
> > concurrent load with SKIP LOCKED in assert-enabled builds.
On 2022-Jan-03, Alvaro Herrera wrote:
> What I don't understand is why hasn't this been reported already: this
> bug is pretty old. My only explanation is that nobody runs sufficiently-
> concurrent load with SKIP LOCKED in assert-enabled builds.
Pushed, thanks Simon for reporting this problem.
On 04.01.22 03:21, Julien Rouhaud wrote:
@@ -2774,6 +2776,7 @@ dumpDatabase(Archive *fout)
appendPQExpBuffer(dbQry, "SELECT tableoid, oid, datname, "
"(%s datdba) AS dba, "
Alexander Lakhin writes:
> 04.01.2022 00:50, Tom Lane wrote:
>> The attached proposed patch removes some ancient infrastructure for
>> manually testing hot standby. I doubt anyone has used this in years,
>> because AFAICS there is nothing here that's not done better by the
>> src/test/recovery
On Mon, Jan 3, 2022 at 12:12 PM tushar wrote:
> On 11/22/21 11:05 PM, Jeevan Ladhe wrote:
> > Please find the lz4 compression patch here that basically has:
> Please refer to this scenario , where --server-compression is only
> compressing
> base backup into lz4 format but not pg_wal directory
>
On Mon, Jan 3, 2022 at 5:08 PM Andrew Dunstan wrote:
>
>
> On 12/23/21 16:06, Joshua Brindle wrote:
> > On Tue, Dec 21, 2021 at 8:26 PM Mark Dilger
> > wrote:
> >>
> >>
> >>> On Dec 21, 2021, at 5:11 PM, Shinya Kato
> >>> wrote:
> >>>
> >>> I fixed the patches because they cannot be applied to
I have some separate questions on the executor changes. Basically, this
seems the right direction, but I wonder if some things could be clarified.
I wonder why in ExecWorkTableScan() and ExecReScanWorkTableScan() you
call tuplestore_copy_read_pointer() instead of just
On 21.09.21 13:35, Denis Hirn wrote:
Also, currently a query like this works [...] but this doesn't:
WITH RECURSIVE t(n) AS (
SELECT n+1 FROM t WHERE n < 100
UNION ALL
VALUES (1)
)
SELECT sum(n) FROM t;
With your patch, the second should also work, so let's show some tests for that
Hello hackers,
While testing the index-only scan fix, I've discovered that replacing
the index-only scan with the index scan changes contrib/btree_gist
output because index-only scan for btree_gist returns a string without
padding.
A simple demonstration (based on btree_gist/sql/char.sql):
CREATE
On 1/4/22 04:18, Himanshu Upadhyaya wrote:
> On Thu, Dec 16, 2021 at 3:06 AM Andrew Dunstan wrote:
>>
>>
>> SELECT JSON_OBJECTAGG(k: v ABSENT ON NULL) AS apt
>> FROM (VALUES ('no', 5), ('area', 50), ('rooms', 2), ('foo', NULL),
>> (5,5)) kv(k, v);
>> ERROR: 22P02: invalid input syntax for type
Andres Freund writes:
> Hi,
>
> On 2022-01-02 21:41:53 -0500, Tom Lane wrote:
>> ... so, that test case is guaranteed to fail in non-UTF8 encodings,
>> I suppose? I wonder what the LANG environment is in that cfbot
>> instance.
>
> LANG="en_US.UTF-8"
>
> But it looks to me like the problem is
On Tue, Jan 4, 2022 at 9:22 AM Michael Paquier wrote:
>
> On Wed, Dec 29, 2021 at 08:50:23AM -0300, Fabrízio de Royes Mello wrote:
> > Try this:
> > https://github.com/michaelpq/pg_plugins/tree/main/decoder_raw
>
> You may want to be careful with this, and I don't know if anybody is
> using that
On 1/4/22 07:20, Michael Paquier wrote:
> On Wed, Dec 29, 2021 at 09:48:14AM -0500, Andrew Dunstan wrote:
>> Seems reasonable. I don't see any reason not to do it for pgbison.bat
>> and pgflex.bat, just for the sake of consistency.
> Yeah, that would close the loop. Andrew, are you planning to
On Tue, Dec 28, 2021 at 01:10:53PM +, Godfrin, Philippe E wrote:
> While experimenting with toast tables I noticed that the toast index
> lands in the same tablespace as the toast table itself. Is there a
> way to make the toast indexes create in a different tablespace?
No. See
On Wed, Dec 29, 2021 at 08:50:23AM -0300, Fabrízio de Royes Mello wrote:
> Try this:
> https://github.com/michaelpq/pg_plugins/tree/main/decoder_raw
You may want to be careful with this, and I don't know if anybody is
using that for serious cases so some spots may have been missed.
--
Michael
On Wed, Dec 29, 2021 at 09:48:14AM -0500, Andrew Dunstan wrote:
> Seems reasonable. I don't see any reason not to do it for pgbison.bat
> and pgflex.bat, just for the sake of consistency.
Yeah, that would close the loop. Andrew, are you planning to check
and apply this patch?
--
Michael
On Wed, Dec 29, 2021 at 10:40:59AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
>> I think the right choice to solve the *general* problem is the
>> mentioned pg_stat_progress_checkpoints.
>
> +1
Agreed. I don't see why this would not work as there are
PgBackendStatus entries for each
On Mon, Jan 03, 2022 at 03:44:24PM -0600, Justin Pryzby wrote:
> @cfbot: rebased
Hmm. This could be useful to provide more control in some logical
reload scenarios, so I'd agree to provide this switch. I'll look at
the patch later..
--
Michael
signature.asc
Description: PGP signature
On Friday, December 31, 2021 10:12 AM Tang, Haiying/唐 海英
wrote:
> On Wednesday, December 22, 2021 6:14 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > Attached the new patch v19.
> >
>
> Thanks for your patch. I think it's better if you could add this patch to the
> commitfest.
> Here are some
On Thu, 16 Dec 2021 at 06:05, Greg Stark wrote:
> So a lot of users are probably looking at something like "BEGIN;
> SELECT create_customer_order(); COMMIT" and wondering why the
> server can't handle automatically retrying the query if they get an
> isolation failure.
I agree with you that
On Monday, January 3, 2022 2:46 PM Hou, Zhijie/侯 志杰
wrote:
> On Wednesday, December 22, 2021 6:14 PM Osumi, Takamichi
> wrote:
> > Attached the new patch v19.
> Hi,
>
> Thanks for updating the patch.
>
> --- a/src/include/pgstat.h
> +++ b/src/include/pgstat.h
> @@ -15,6 +15,7 @@
> #include
Am 03.01.22 um 22:23 schrieb Alvaro Herrera:
Overall I think this is a good feature to have; assessing the need for
compression is important for tuning, so +1 for the goal of the patch.
Much appreciated!
I didn't look into the patch carefully, but here are some minor
comments:
On
Am 03.01.22 um 22:03 schrieb Justin Pryzby:
+pgstat_report_toast_activity(Oid relid, int attr,
+ bool externalized,
+ bool compressed,
+
On 1/3/22 8:59 PM, Tom Lane wrote:
"Andrey V. Lepikhov" writes:
planner hook is frequently used in monitoring and advising extensions.
Yeah.
The call to this hook is implemented in the way, that the
standard_planner routine must be called at least once in the hook's call
chain.
But, as I
út 4. 1. 2022 v 10:19 odesílatel Himanshu Upadhyaya <
upadhyaya.himan...@gmail.com> napsal:
> On Thu, Dec 16, 2021 at 3:06 AM Andrew Dunstan
> wrote:
> >
> >
> > On 12/9/21 09:04, Himanshu Upadhyaya wrote:
> > >
> > >
> > >
> > > 4)
> > > Are we intentionally allowing numeric keys in JSON_OBJECT
On Thu, Dec 16, 2021 at 3:06 AM Andrew Dunstan wrote:
>
>
> On 12/9/21 09:04, Himanshu Upadhyaya wrote:
> >
> >
> >
> > 4)
> > Are we intentionally allowing numeric keys in JSON_OBJECT but somehow
> > these are not allowed in ORACLE?
> > ‘postgres[151876]=#’select JSON_OBJECT( 3+1:2, 2+2:1);
> >
> In a standalone backend, I think there are only 3 ways to get to
> normal shutdown:
>* SIGTERM
>* SIGQUIT
> * EOF on stdin
I debugged a bit more and I see that getc() returns with -1 in
interactive_getc() which is interpreted as EOF:
c = getc(stdin);
I see that errno ==
Hello Tom,
04.01.2022 00:50, Tom Lane wrote:
> The attached proposed patch removes some ancient infrastructure for
> manually testing hot standby. I doubt anyone has used this in years,
> because AFAICS there is nothing here that's not done better by the
> src/test/recovery TAP tests. (Or if
87 matches
Mail list logo
