On Thu, 17 Jun 2021 at 23:49, Noah Misch wrote:
>
> On Wed, Jun 16, 2021 at 12:00:57PM -0400, Tom Lane wrote:
> > I agree that's a great use-case. I don't like this implementation though.
> > I think if you want to set things up like that, you should draw a line
> > between the tables it's okay
On Wed, Jun 23, 2021 at 9:10 AM Ajin Cherian wrote:
>
> On Tue, Jun 22, 2021 at 3:36 PM Greg Nancarrow wrote:
>
> > Some minor comments:
> >
> > (1)
> > v88-0002
> >
> > doc/src/sgml/logicaldecoding.sgml
> >
> > "examples shows" is not correct.
> > I think there is only ONE example being
I came across this thread [1] to disallow canceling a transaction not
yet confirmed by a synchronous replica. I think my proposed patch
might help that case as well, hence adding all involved in that thread
to BCC, for one-time notification.
As mentioned in that thread, when sending a
On Wed, Jun 23, 2021 at 12:07:11AM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > This causes the server to crash during FETCH.
>
> > ts=# begin; declare b cursor for VALUES(1); fetch 100 in b;
> > BEGIN
> > DECLARE CURSOR
> > server closed the connection unexpectedly
> > This
Hi,
When directly INSERT INTO partition, postgres will invoke ExecPartitionCheck
which will execute its parent's and grandparent's partition constraint check.
>From the code, the whole constraint check is saved in relcache::rd_partcheck.
For a multi-level partition, for example: table 'A' is
On Tue, Jun 22, 2021 at 2:31 PM Simon Riggs
wrote:
>
> I attach both clean and compare versions.
>
Do we want to hold this work for PG15 or commit in PG14 and backpatch
it till v10 where we have made hash indexes crash-safe? I would vote
for committing in PG14 and backpatch it till v10, however,
Justin Pryzby writes:
> This causes the server to crash during FETCH.
> ts=# begin; declare b cursor for VALUES(1); fetch 100 in b;
> BEGIN
> DECLARE CURSOR
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while
On Tue, Jun 22, 2021 at 01:13:08PM -0400, Tom Lane wrote:
> I wrote:
> > The attached seems to be enough to resolve Jim's example. I'd like
> > to invent a test case that involves a detoast of the simple
> > expression's result, too, to show that transiently pushing a
> > snapshot for the
On Tue, Jun 22, 2021 at 12:06:45PM +0200, Fabien COELHO wrote:
> Attached an updated v8 patch which adds (reinstate) an improved TAP test
> which would have caught the various regressions on logs.
> Given that such tests were removed once before, I'm unsure whether they will
> be acceptable,
On Tue, Jun 22, 2021 at 08:18:42AM -0400, Andrew Dunstan wrote:
> On 6/22/21 2:42 AM, Noah Misch wrote:
> > I was wondering about suggesting some kind of
> >> official warning, but I guess the manual already covers it with this
> >> 10 year old notice. I don't know much about Windows or Cygwin so
On Mon, Jun 21, 2021 at 4:17 PM Amit Kapila wrote:
>
> On Mon, Jun 21, 2021 at 11:19 AM Amit Kapila wrote:
> >
>
> I think we should store the input from the user (like disable_on_error
> flag or xid to skip) in the system catalog pg_subscription and send
> the error information (subscrtion_id,
On Tue, Jun 22, 2021 at 6:54 PM Tom Lane wrote:
>
> Thomas Munro writes:
> > On Tue, Jun 22, 2021 at 10:01 PM Amit Kapila
> > wrote:
> >> I see this report is from 16th June 2021 and the commit is on 18th
> >> June 2021. So, I am hoping this should have been fixed but if we see
> >> it again
On Wed, Jun 23, 2021 at 1:06 AM Maxim Orlov wrote:
>
> The analysis in the beginning of the discussion seems to be right, but
> the fix v2 looks too invasive for me.
>
> Personally, I'd like not to remove snapshot even if transaction is
> read-only. I propose to consider "xid < TransactionXmin"
On Tuesday, June 22, 2021 8:25 PM Amit Kapila wrote:
> On Wed, Jun 16, 2021 at 8:57 AM houzj.f...@fujitsu.com
> wrote:
> >
> > I think the check of partition could be even more complicated if we
> > need to check the parallel safety of partition key expression. If user
> > directly insert into
On 2021-Jun-22, Alvaro Herrera wrote:
> > So I think it would be useful to clarify the server behavior and
> > specify it in the documentation.
>
> I'll see about improving the docs on these points.
So I started to modify the second paragraph to indicate that the client
would send data on
On Fri, Jun 18, 2021 at 08:01:17PM -0400, Greg Sabino Mullane wrote:
> I don't know that we need to bother: the default is already to sync and one
> has to go out of one's way using the -N argument to NOT sync, so I think
> it's a pretty safe assumption to everyone (except those who read my first
Hello Greg,
On Tue, 22 Jun 2021 19:22:38 +
Greg Sabino Mullane wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: tested, failed
> Spec compliant: not tested
> Documentation:
Hello Fabien,
On Tue, 22 Jun 2021 20:03:58 +0200 (CEST)
Fabien COELHO wrote:
>
> Hello Yugo-san,
>
> Thanks a lot for continuing this work started by Marina!
>
> I'm planning to review it for the July CF. I've just added an entry there:
>
> https://commitfest.postgresql.org/33/3194/
On Tue, Jun 22, 2021 at 6:51 PM David Rowley wrote:
> I guess we could also ask ourselves how many join algorithms we need.
David and I discussed this a bit off-list, and I just wanted to share
how I understand the idea so far in case it helps someone else. There
are essentially three
On Tue, Jun 22, 2021 at 5:01 PM Alvaro Herrera wrote:
> I have 2.30. It works better. To be clear: some lines still appear as
> originating in some pgindent commit, when they are created by such a
> commit. But as far as I've seen, they're mostly uninteresting ones
> (whitespace, only braces,
On 2021-Mar-18, Peter Geoghegan wrote:
> On Thu, Mar 18, 2021 at 3:12 PM Bruce Momjian wrote:
> > It would be kind of nice if the file can be generated automatically. I
> > have you checked if 'pgindent' being on the first line of the commit is
> > sufficient?
>
> I generated the file by
On Tue, Jun 22, 2021 at 04:12:51PM -0300, Euler Taveira wrote:
> Was it? I seem to have missed this suggestion.
>
> I'm attaching a patch to fix it.
Looks adapted to me.
--
Michael
signature.asc
Description: PGP signature
On Fri, 2021-06-18 at 13:07 +0900, Michael Paquier wrote:
> On Tue, Jun 08, 2021 at 04:37:46PM +, Jacob Champion wrote:
> > 1. Prep
> >
> > 0001 decouples the SASL code from the SCRAM implementation.
> > 0002 makes it possible to use common/jsonapi from the frontend.
> > 0003 lets the
On Fri, 2021-06-18 at 11:31 +0300, Heikki Linnakangas wrote:
> On 08/06/2021 19:37, Jacob Champion wrote:
> > We've been working on ways to expand the list of third-party auth
> > methods that Postgres provides. Some example use cases might be "I want
> > to let anyone with a Google account read
(This is split off from my work on OAUTHBEARER [1].)
The jsonapi in src/common can't currently be compiled into libpq. The
first patch here removes the dependency on pg_log_fatal(), which is not
available to the sharedlib. The second patch makes sure that all of the
return values from
On 2021-Jun-21, Boris Kolpackov wrote:
> Alvaro Herrera writes:
>
> > I think I should rephrase this to say that PQpipelineSync() is needed
> > where the user needs the server to start executing commands; and
> > separately indicate that it is possible (but not promised) that the
> > server
(This is split off from my work on OAUTHBEARER [1].)
Currently, the SASL logic is tightly coupled to the SCRAM
implementation. This patch untangles the two, by introducing callback
structs for both the frontend and backend.
In the original thread, Michael Paquier commented:
> + /*
On Tue, Jun 22, 2021 at 2:53 AM Tomas Vondra
wrote:
> Yeah, I like the insurance analogy - it gets to the crux of the problem,
> because insurance is pretty much exactly about managing risk.
The user's exposure to harm is what truly matters. I admit that that's
very hard to quantify, but we
When running a VACUUM or CLUSTER command, the namespace name is not part of
the emitted message.
Using `vacuumdb` CLI tool recently with multiple jobs, I found that
reading the output messages harder to match the relations with their
namespaces.
Example:
INFO: vacuuming "sendgrid.open"
INFO:
Andrew Dunstan writes:
> On 6/20/21 6:10 PM, Tom Lane wrote:
>> (3) Since this only works in v14 and up, older branches would
>> have to fall back to -DCLOBBER_CACHE_ALWAYS. Perhaps we could
>> improve the buildfarm client script so that buildfarm owners
>> just configure "clobber_cache_testing
On Tue, Jun 22, 2021 at 8:06 PM Tom Lane wrote:
> > I suggest the initial version to come with 2 new access methods in the
> > new type: hashing and ordering. We can use those in the functions
> > that are currently searching for the hash and btree operator classes.
>
> Again, exactly what does
Those code comments look good.
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
Looks fine to me, as a way of catching this edge case.
On Fri, Jun 11, 2021, at 9:43 PM, Justin Pryzby wrote:
> On Sat, Oct 31, 2020 at 09:01:15PM -0300, Euler Taveira wrote:
> > > > The current behavior is only useful for debugging purposes.
>
> On Wed, 28 Oct 2020 at 15:42, Tomas Vondra
> wrote:
> > > One thing I'm not sure about is whether we
Hello Yugo-san,
Thanks a lot for continuing this work started by Marina!
I'm planning to review it for the July CF. I've just added an entry there:
https://commitfest.postgresql.org/33/3194/
--
Fabien.
> I can see some value perhaps in letting other opclasses refer to
> btree and hash opclasses rather than duplicating their entries.
> But that doesn't seem to be what you're proposing here.
That's what I am proposing. My idea is to change the current btree
and hash opclasses to be under the new
I wrote:
> The attached seems to be enough to resolve Jim's example. I'd like
> to invent a test case that involves a detoast of the simple
> expression's result, too, to show that transiently pushing a
> snapshot for the duration of the expression is not the right fix.
Here we go. This test
Emre Hasegeli writes:
> I think we can benefit from higher level operator classes which can
> support multiple index implementations. This is achievable by
> introducing another type of access method.
I do not really understand what the point of that is?
To the extent that operator classes
I think we can benefit from higher level operator classes which can
support multiple index implementations. This is achievable by
introducing another type of access method. Here is my idea in SQL:
CREATE ACCESS METHOD ordering
TYPE INTERFACE HANDLER ordering_ifam_handler;
CREATE ACCESS METHOD
On Tue, Jun 22, 2021 at 9:43 AM Tom Lane wrote:
> > Pushed. Thanks.
>
> Um. You probably should have waited for beta2 to be tagged.
> No harm done likely, but it's not per release process.
Sorry about that. I was aware of the policy, but somehow overlooked
that we were in the window between
Peter Geoghegan writes:
> On Tue, Jun 22, 2021 at 8:18 AM Tom Lane wrote:
>> OK, no objections then.
> Pushed. Thanks.
Um. You probably should have waited for beta2 to be tagged.
No harm done likely, but it's not per release process.
regards, tom lane
On Tue, Jun 22, 2021 at 8:18 AM Tom Lane wrote:
> OK, no objections then.
Pushed. Thanks.
--
Peter Geoghegan
I wrote:
> Hmm. I think the real issue here is that commit 84f5c2908 did
> not cover the "simple expression" code path in plpgsql. We
> need to re-establish an outer snapshot when the next thing
> that happens after COMMIT is a simple expression, too.
The attached seems to be enough to resolve
On 6/22/21 10:41 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> It's worth pointing out that Cygwin psql is built with readline, which
>> makes it rather nicer to use than the Native builds. We still have this
>> in configure.ac:
>>
>> # readline on MinGW has problems with backslashes in psql
Peter Geoghegan writes:
> On Tue, Jun 22, 2021 at 8:04 AM Tom Lane wrote:
>> Hmm, is the "git config blame.ignoreRevsFile" setting actually
>> repo-relative? I'm a bit confused as to whether an absolute
>> file path would be needed to ensure correct behavior.
> That seems to be standard
On Tue, Jun 22, 2021 at 8:04 AM Tom Lane wrote:
> Hmm, is the "git config blame.ignoreRevsFile" setting actually
> repo-relative? I'm a bit confused as to whether an absolute
> file path would be needed to ensure correct behavior.
That seems to be standard practice, and certainly works for me.
The analysis in the beginning of the discussion seems to be right, but
the fix v2 looks too invasive for me.
Personally, I'd like not to remove snapshot even if transaction is
read-only. I propose to consider "xid < TransactionXmin" as a legit case
and just promote xid to TransactionXmin.
Peter Geoghegan writes:
> Attached is a patch file that puts it all together. I would like to
> commit this in the next couple of days.
Hmm, is the "git config blame.ignoreRevsFile" setting actually
repo-relative? I'm a bit confused as to whether an absolute
file path would be needed to ensure
Michael Paquier writes:
> On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote:
>> The following generates an assertion failure.
> A bisect run points me to the following commit:
> commit 73b06cf893c9d3bb38c11878a12cc29407e78b6c
> Author: Tom Lane
> Date: Fri Nov 22 15:02:18 2019 -0500
>
Hi hackers,
On Mon, 24 May 2021 11:29:10 +0900
Yugo NAGATA wrote:
> Hi hackers,
>
> On Tue, 10 Mar 2020 09:48:23 +1300
> Thomas Munro wrote:
>
> > On Tue, Mar 10, 2020 at 8:43 AM Fabien COELHO wrote:
> > > >> Thank you very much! I'm going to send a new patch set until the end of
> > > >>
Andrew Dunstan writes:
> It's worth pointing out that Cygwin psql is built with readline, which
> makes it rather nicer to use than the Native builds. We still have this
> in configure.ac:
>
> # readline on MinGW has problems with backslashes in psql and other bugs.
> # This is particularly a
On 2021-Jun-22, Thomas Munro wrote:
> Hi,
>
> Here's a curious one-off failure in test_integerset:
>
> +ERROR: iterate returned wrong value; got 519985430528, expected 485625692160
Cosmic rays indeed. The base-2 representation of the expected value is
11100010001000110001100
Seino Yuki писал 2021-06-22 16:03:
On 2021-06-16 01:29, Alexander Pyhalov wrote:
Hi.
Ashutosh Bapat писал 2021-06-15 16:24:
Looks quite useful to me. Can you please add this to the next
commitfest?
Addded to commitfest. Here is an updated patch version.
Thanks for posting the patch.
I
On 2021-06-16 01:29, Alexander Pyhalov wrote:
Hi.
Ashutosh Bapat писал 2021-06-15 16:24:
Looks quite useful to me. Can you please add this to the next
commitfest?
Addded to commitfest. Here is an updated patch version.
Thanks for posting the patch.
I agree with this content.
+ Foreign
On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote:
> The following generates an assertion failure. Quick testing with start and
> stop as well as the core dump shows it’s failing on the execution of
> `schema_name := schema_name(i)` immediately after COMMIT, because there’s
no
> active
On Wed, Jun 16, 2021 at 8:57 AM houzj.f...@fujitsu.com
wrote:
>
> I think the check of partition could be even more complicated if we need to
> check the parallel safety of partition key expression. If user directly
> insert into
> a partition, then we need invoke ExecPartitionCheck which will
On 6/22/21 2:42 AM, Noah Misch wrote:
> I was wondering about suggesting some kind of
>> official warning, but I guess the manual already covers it with this
>> 10 year old notice. I don't know much about Windows or Cygwin so I'm
>> not sure if it needs updating or not, but I would guess that
On Mon, Jun 21, 2021 at 4:52 PM Tom Lane wrote:
> I'm willing to take some flak if there's not an easy proof that the outer
> scan is single-row, but I don't think we should just up and change it
> for cases where there is.
I think that's a reasonable request. I'm not sure that I believe it's
> But making everything slower will be a hard sell, because vast majority of
> workloads already running on Postgres don't have this issue at all, so
> for them it's not worth the expense. Following the insurance analogy,
> selling tornado insurance in Europe is mostly pointless.
>
Agree. I've
On Monday, June 21, 2021 11:23 PM Robert Haas wrote:
> On Mon, Jun 21, 2021 at 12:56 AM Amit Kapila wrote:
> > Yeah, the session in which we are doing Alter Function won't be able
> > to lock it but it will wait for the AccessExclusiveLock on the rel to
> > be released because it will also try
On Tue, Jun 22, 2021 at 10:01 PM Amit Kapila wrote:
> On Tue, Jun 22, 2021 at 10:33 AM Thomas Munro wrote:
> > While scanning for assertion failures on the build farm that don't
> > appear to have been discussed, I found this[1] in
> > 010_truncate_publisher.log on the 13 branch:
> >
> > TRAP:
Bonjour Michaël,
If this were core server code threatening data integrity I would be
inclined to be more strict, but after all pg_bench is a utility program,
and I think we can allow a little more latitude.
+1. Let's be flexible here. It looks better to not rush a fix, and
we still have
On Tue, Jun 22, 2021 at 10:33 AM Thomas Munro wrote:
>
> While scanning for assertion failures on the build farm that don't
> appear to have been discussed, I found this[1] in
> 010_truncate_publisher.log on the 13 branch:
>
> TRAP: FailedAssertion("tupdesc->tdrefcount <= 0", File:
>
On 6/22/21 2:25 AM, Peter Geoghegan wrote:
> On Mon, Jun 21, 2021 at 4:51 PM Bruce Momjian wrote:
>> There were a lot of interesting ideas in this thread and I want to
>> analyze some of them. First, there is the common assumption (not
>> stated) that over-estimating by 5% and underestimating
On Tue, Jun 22, 2021 at 7:15 AM Amit Kapila wrote:
>
> On Mon, Jun 21, 2021 at 6:38 PM Simon Riggs
> wrote:
> >
> > New chapter for Hash Indexes, designed to help users understand how
> > they work and when to use them.
> >
> > Mostly newly written, but a few paras lifted from README when they
Hi,
Here's a curious one-off failure in test_integerset:
+ERROR: iterate returned wrong value; got 519985430528, expected 485625692160
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rhinoceros=2021-04-01%2018:19:47
At Tue, 22 Jun 2021 11:20:46 +0300, Heikki Linnakangas wrote
in
> On 22/06/2021 10:20, Peter Eisentraut wrote:
> > v1-0004-Simplify-code-generation-code.patch
> > This simplifies the code a bit, which helps with the next patch.
>
> If we do that, let's add the trailing commas to the other
On 22/06/2021 10:20, Peter Eisentraut wrote:
I have accumulated a few patches to improve the output of the scripts in
src/backend/utils/mb/Unicode/ to be less non-standard-looking and fix a
few other minor things in that area.
v1-0001-Make-Unicode-makefile-more-parallel-safe.patch
The makefile
At Tue, 22 Jun 2021 09:20:16 +0200, Peter Eisentraut
wrote in
> I have accumulated a few patches to improve the output of the scripts
> in src/backend/utils/mb/Unicode/ to be less non-standard-looking and
> fix a few other minor things in that area.
>
>
On Tue, Jun 22, 2021 at 11:05:22AM +0530, Dilip Kumar wrote:
> IMHO there is certainly a use case, basically, if we compress the data
> so that we can avoid storing it externally. Now suppose for some
> data, with default LZ4 compression, the compression ratio is so high
> that you are able to
I have accumulated a few patches to improve the output of the scripts in
src/backend/utils/mb/Unicode/ to be less non-standard-looking and fix a
few other minor things in that area.
v1-0001-Make-Unicode-makefile-more-parallel-safe.patch
The makefile rule that calls UCS_to_most.pl was written
On Tue, Jun 22, 2021 at 05:52:03PM +1200, Thomas Munro wrote:
> On Tue, Jun 22, 2021 at 5:21 PM Noah Misch wrote:
> > On Thu, Aug 03, 2017 at 10:45:50AM -0400, Robert Haas wrote:
> > > On Wed, Aug 2, 2017 at 11:47 PM, Noah Misch wrote:
> > > > postmaster algorithms rely on the PG_SETMASK() calls
On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote:
> The following generates an assertion failure. Quick testing with start and
> stop as well as the core dump shows it’s failing on the execution of
> `schema_name := schema_name(i)` immediately after COMMIT, because there’s no
> active
On Mon, Jun 21, 2021 at 6:38 PM Simon Riggs
wrote:
>
> New chapter for Hash Indexes, designed to help users understand how
> they work and when to use them.
>
> Mostly newly written, but a few paras lifted from README when they were
> helpful.
>
Few comments
==
1.
+ Hash indexes
74 matches
Mail list logo
