Hello,
the abbrev_converter is applied whenever it is defined. The values are
sorted using the abbreviated comparator first using the shortened version,
and if there is a tie the system asks the real full comparator to resolve
it.
This article seems to be rather comprehensive:
https://brandur.org
Hi all,
I am trying to implement a sort support function for geometry data types in
PostGIS with the new feature `SortSupport`. However, I have a question
about this.
I think it is hardly to apply a sort support function to a complex data
type without the `abbrev_converter` to simply the data str
Hi
rebase
Regards
Pavel
schema-variables-20210612.patch.gz
Description: application/gzip
On Fri, Jun 11, 2021 at 09:37:50PM -0700, Noah Misch wrote:
> On Fri, Jun 11, 2021 at 08:54:08PM -0500, Justin Pryzby wrote:
> > On Sat, Jun 05, 2021 at 12:08:01PM -0700, Noah Misch wrote:
> > > > > My preference is to remove pg_wait_for_backend_termination(). The
> > > > > use case
> > > > > tha
Ok! Thanks
--
--原始邮件--
发件人："Andres Freund "
Hi,
On 2021-05-07 04:36:25 +0800, 盏一 wrote:
> > Sounds like a plan! Do you want to write a patch?
> Add the patch.
Thanks for the patch. I finally pushed an edited version of it. There
were other loops over ->pgprocnos, so I put assertions in those - that
gains us a a good bit more checking than
On Fri, Jun 11, 2021 at 08:54:08PM -0500, Justin Pryzby wrote:
> On Sat, Jun 05, 2021 at 12:08:01PM -0700, Noah Misch wrote:
> > > > My preference is to remove pg_wait_for_backend_termination(). The use
> > > > case
> > > > that prompted this thread used pg_terminate_backend(pid, 18); it
> >
On Fri, Apr 30, 2021 at 2:23 PM Thomas Munro wrote:
> Here's something I wanted to park here to look into for the next
> cycle: it turns out that kqueue's EV_EOF flag also has the right
> semantics for this. That leads to the idea of exposing the event via
> the WaitEventSet API, and would the b
Justin Pryzby writes:
> Per sqlsmith.
> postgres=# SELECT pg_filenode_relation(0,0);
> ERROR: unexpected duplicate for tablespace 0, relfilenode 0
Ugh.
> The usual expectation is that sql callable functions should return null rather
> than hitting elog().
Agreed, but you should put the short-c
| Add Set Server Name Indication (SNI) for SSL connection packets (Peter
Eisentraut)
Remove "Set"
| Reduce the default value of vacuum_cost_page_miss from 10 milliseconds to 2
(Peter Geoghegan)
Peter mentioned that this should not say "milliseconds" (but maybe the page I'm
looking at is old).
Andres Freund writes:
> On 2021-06-11 19:08:57 -0400, Tom Lane wrote:
>> Anyway, I agree that disabling that was a bit of a stopgap hack. This
>> 'nonstring' attribute seems like it would help for ECPG's usage, at
>> least.
> nonstring is supported since gcc 8, which also brought the warnings th
Hi,
On 2021-06-11 19:08:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > It might be worth doing something about this, for other reasons. We have
> > disabled -Wstringop-truncation in 716585235b1. But I've enabled it in my
> > debug build, because I find it useful.
>
> ITYM e71658523 ? I c
On Fri, Jun 28, 2019 at 12:55 PM Ashwin Agrawal wrote:
> On Thu, Jun 27, 2019 at 4:33 PM Thomas Munro wrote:
>>
>> Here's a patch I'd like to commit to fix the comment. We could look
>> at improving the actual code after
>> https://commitfest.postgresql.org/23/2169/ is done.
>
> Change looks goo
Per sqlsmith.
postgres=# SELECT pg_filenode_relation(0,0);
ERROR: unexpected duplicate for tablespace 0, relfilenode 0
postgres=# \errverbose
ERROR: XX000: unexpected duplicate for tablespace 0, relfilenode 0
LOCATION: RelidByRelfilenode, relfilenodemap.c:220
The usual expectation is that sq
Hi,
Removing legitimate warnings can it be worth it?
-1 CAST can be wrong, when there is an invalid value defined
(InvalidBucket, InvalidBlockNumber).
I think depending on the compiler -1 CAST may be different from
InvalidBucket or InvalidBlockNumber.
pg_rewind is one special case.
All cases of
On Sat, Jun 05, 2021 at 12:08:01PM -0700, Noah Misch wrote:
> > > My preference is to remove pg_wait_for_backend_termination(). The use
> > > case
> > > that prompted this thread used pg_terminate_backend(pid, 18); it
> > > doesn't
> > > need pg_wait_for_backend_termination().
Is this an Op
Hi,
I just tried to add a, seemingly innocuous, assertion to
ProcArrayAdd()/Remove() that proc->pgprocno is < arrayP->maxProcs. That
quickly fails.
The reason for that is that PGPROC are created in the following order
1) MaxBackends normal (*[1]) backends
2) NUM_AUXILIARY_PROCS auxiliary processe
On Fri, Jun 11, 2021 at 08:19:48PM -0500, Justin Pryzby wrote:
> On Fri, Jun 11, 2021 at 09:12:55PM -0400, Bruce Momjian wrote:
> > OK, I used some of your ideas and tried for something more general;
> > patch attached.
>
> This is good.
>
> But I wonder if "dropped before upgrading" is too spec
On Fri, Jun 11, 2021 at 09:17:46PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I used some of your ideas and tried for something more general;
> > patch attached.
>
> I think it's a good idea to mention custom aggregates and operators
> specifically, as otherwise people will look at t
On Fri, Jun 11, 2021 at 09:12:55PM -0400, Bruce Momjian wrote:
> OK, I used some of your ideas and tried for something more general;
> patch attached.
This is good.
But I wonder if "dropped before upgrading" is too specific to pg_upgrade?
Dropping the aggregate before starting a backup to be re
Bruce Momjian writes:
> OK, I used some of your ideas and tried for something more general;
> patch attached.
I think it's a good idea to mention custom aggregates and operators
specifically, as otherwise people will look at this and have little
idea what you're on about. I just want wording li
On Fri, Jun 11, 2021 at 08:56:19PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I came up with the attached patch. This is one of the few cases
> > where the incompatibility is not clearly related to the feature, so I
> > left the existing item alone and just created a new one with the
Bruce Momjian writes:
> OK, I came up with the attached patch. This is one of the few cases
> where the incompatibility is not clearly related to the feature, so I
> left the existing item alone and just created a new one with the same
> commit message in the incompatibilities section.
I think p
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 should have the GUC as
> > proposed, or have a negative "keep_temp_file
On Tue, Jun 8, 2021 at 07:10:00PM -0500, Justin Pryzby wrote:
> 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
OK, I came up with the attached patch. This is
On Fri, Jun 11, 2021 at 10:08:20AM -0400, Alvaro Herrera wrote:
> I think if they're to be kept in sync, then the exceptions should be
> noted. I mean, where PGCLIENTENCODING would otherwise be, I'd add
> /* PGCLIENTENCODING set above */
> /* See below for PGHOSTADDR */
> and so on (PGHOST and PGP
On Sat, 2021-06-05 at 09:47 -0700, Zhihong Yu wrote:
> On Fri, Jun 4, 2021 at 4:14 PM Jacob Champion wrote:
> > Agreed. I'm going to double-check with Deep that the new calls
> > to table_tuple_fetch_row_version() should be projecting the full row,
> > then post an updated patch some time next wee
()On Sat, Jun 12, 2021 at 2:30 AM Justin Pryzby wrote:
> On Fri, Jun 11, 2021 at 11:37:58PM +0300, Alexander Korotkov wrote:
> > On Fri, Jun 11, 2021 at 1:04 AM Justin Pryzby wrote:
> > >
> > > +{ oid => '1293', descr => 'expand mutlirange to set of ranges',
> > >
> > > typo: mutlirange
> >
> > F
On Fri, Jun 11, 2021 at 11:37:58PM +0300, Alexander Korotkov wrote:
> On Fri, Jun 11, 2021 at 1:04 AM Justin Pryzby wrote:
> >
> > +{ oid => '1293', descr => 'expand mutlirange to set of ranges',
> >
> > typo: mutlirange
>
> Fixed, thanks.
>
> The patch with the implementation of both unnest() a
Andres Freund writes:
> It might be worth doing something about this, for other reasons. We have
> disabled -Wstringop-truncation in 716585235b1. But I've enabled it in my
> debug build, because I find it useful.
ITYM e71658523 ? I can't find that hash in my repo. Anyway, I agree
that disabling
Hi,
On 2020-04-23 14:36:15 +0900, Kyotaro Horiguchi wrote:
> At Thu, 23 Apr 2020 01:21:21 -0300, Ranier Vilela wrote
> in
> > Em qua., 22 de abr. de 2020 às 23:27, Kyotaro Horiguchi <
> > horikyota@gmail.com> escreveu:
> > >
> > > - strncpy(sqlca->sqlerrm.sqlerrmc, message,
> > > size
Tomas Vondra writes:
> There's one caveat, though - for regular builds the slowdown is pretty
> much eliminated. But with valgrind it's still considerably slower. For
> postgres_fdw the "make check" used to take ~5 minutes for me, now it
> takes >1h. And yes, this is entirely due to the new test c
On 6/9/21 4:05 PM, Tomas Vondra wrote:
> On 6/9/21 3:28 PM, Tom Lane wrote:
>> Tomas Vondra writes:
>>> Note that the problem here is [1] - we're creating a lot of slots
>>> referencing the same tuple descriptor, which inflates the duration.
>>> There's a fix in the other thread, which eliminat
I wrote:
> Michael Paquier writes:
>> This is the same problem as c757a3da and 6d41dd0, where we write a
>> query to a pipe but the kill, causing a failure, makes the test fail
>> with a SIGPIPE in IPC::Run as a query is sent down to a pipe.
> The precedent of the previous fixes would seem to sug
On Sun, May 30, 2021 at 6:30 PM Masahiko Sawada wrote:
> > Another concern with this approach is what it
> > means for the VACUUM command itself. I haven't added an 'auto'
> > spelling that is accepted by the VACUUM command in this POC version.
> > But do I need to at all? Can that just be implied
On Fri, 2021-06-11 at 16:57 -0400, Robert Haas wrote:
> My impression was that CopyBoth can be initiated either way,
The docs say: "In either physical replication or logical replication
walsender mode, only the simple query protocol can be used." Is there
some way to initiate CopyBoth outside of
On Thu, Jun 3, 2021 at 11:15 PM Michael Paquier wrote:
> I have read through the patch, and I am surprised to see that this
> only makes possible to control the optimization at relation level.
> The origin of the complaints is that this index cleanup optimization
> has been introduced as a new rul
On 2021-Jun-04, Greg Nancarrow wrote:
> On Thu, Jun 3, 2021 at 1:49 AM Matthias van de Meent
> wrote:
> >
> > On Wed, 2 Jun 2021 at 17:42, Tomas Vondra
> > wrote:
> > >
> > > Nice. I gave it a try on the database I'm experimenting with, and it
> > > seems to be working fine. Please add it to th
On 6/9/21 1:08 PM, Tomas Vondra wrote:
>
>
> On 6/9/21 12:50 PM, Bharath Rupireddy wrote:
>> On Wed, Jun 9, 2021 at 4:00 PM Tomas Vondra
>> wrote:
>>>
>>> Hi,
>>>
>>> Here's a v2 fixing a silly bug with reusing the same variable in two
>>> nested loops (worked for simple postgres_fdw cases, but
On Thu, Jun 10, 2021 at 9:26 PM Jeff Davis wrote:
> The docs currently say (introduced in commit 91fa853):
>
> "In the event of a backend-detected error during copy-both mode, the
> backend will issue an ErrorResponse message, discard frontend messages
> until a Sync message is received, and then
On 2021-06-11 12:07:24 -0700, Jeff Davis wrote:
> On Fri, 2021-06-11 at 11:56 -0700, Andres Freund wrote:
> > That doesn't work as easily in older versions because there was no
> > SQL
> > support in replication connections until PG 10...
>
> 9.6 will be EOL this year. I don't really see why such
Hi,
On 2021-06-11 16:05:10 -0400, Robert Haas wrote:
> You seem to see this as some kind of major problem and I guess I don't
> agree. I think it's pretty clear what the motivation was for the
> current behavior, because I believe it's well-explained by the comment
> and the three people who have
On 2021-06-11 15:52:21 -0400, Álvaro Herrera wrote:
> On 2021-Apr-07, Andres Freund wrote:
>
> > After this I don't see a reason to have SAB_Inquire - as far as I can
> > tell it's practically impossible to use without race conditions? Except
> > for raising an error - which is "builtin"...
>
> P
On Fri, Jun 11, 2021 at 1:04 AM Justin Pryzby wrote:
>
> +{ oid => '1293', descr => 'expand mutlirange to set of ranges',
>
> typo: mutlirange
Fixed, thanks.
The patch with the implementation of both unnest() and cast to array
is attached. It contains both tests and docs.
--
Regards,
Alexa
On 11.06.21 22:05, Finnerty, Jim wrote:
You can have these queries return both rows if you use an
accent-ignoring collation, like this example in the documentation:
CREATE COLLATION ignore_accents (provider = icu, locale =
'und-u-ks-level1-kc-true', deterministic = false);
On Tue, May 25, 2021 at 9:38 AM Alvaro Herrera wrote:
> This should be okay, right? Well, almost. The problem here is if you
> want to have a variable where you set more than one option, you have to
> use bit-and of the enum values ... and the resulting value is no longer
> part of the enum. A c
On Fri, Jun 11, 2021 at 12:13 AM Amit Kapila wrote:
> Do we invalidate relcache entry if someone changes say trigger or some
> index AM function property via Alter Function (in our case from safe
> to unsafe or vice-versa)? Tsunakawa-San has mentioned this as the
> reason in his email [1] why we c
On 2021-Jun-09, Tom Lane wrote:
> BTW, to be clear: I think Alvaro's change is also necessary.
> If libpq is going to silently do something different in pipeline
> mode than it does in normal mode, it should strive to minimize
> the semantic difference. exec_simple_query includes a PortalDrop,
>
Alexander Korotkov writes:
> What about "Range/Multirange Functions and Operators"?
Better than a comma, I guess. Personally I didn't have a
problem with the form with two "ands".
regards, tom lane
On Fri, Jun 11, 2021 at 3:39 AM Tom Lane wrote:
> Justin Pryzby writes:
> > If it's confusing to say "and" twice, then perhaps you'd say:
> > Functions and Operators for Range and Multirange Types
>
> Uh, that's still two "and"s. In any case, I think it's better
> to keep this section heading al
>>
You can have these queries return both rows if you use an
accent-ignoring collation, like this example in the documentation:
CREATE COLLATION ignore_accents (provider = icu, locale =
'und-u-ks-level1-kc-true', deterministic = false);
<<
Indeed. Is the dependency between the ch
On Fri, Jun 11, 2021 at 2:49 PM Jeff Davis wrote:
> It doesn't add any overhead.
>
> All the client would have to do is "SELECT confirmed_flush_lsn FROM
> pg_replication_slots WHERE slot_name='myslot'", and compare it to the
> stored value. If the stored value is earlier than the
> confirmed_flush
On 2021-Apr-07, Andres Freund wrote:
> After this I don't see a reason to have SAB_Inquire - as far as I can
> tell it's practically impossible to use without race conditions? Except
> for raising an error - which is "builtin"...
Pushed 0002.
Thanks!
--
Álvaro Herrera
On Fri, 2021-06-11 at 15:43 +0530, Amit Kapila wrote:
> The new patches look mostly good apart from the below cosmetic
> issues.
> I think the question is whether we want to do these for PG-14 or
> postpone them till PG-15. I think these don't appear to be risky
> changes so we can get them in PG-1
Hi,
On 2021-06-08 19:45:58 +0200, Peter Eisentraut wrote:
> 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 o
HHi,
On 2021-06-05 00:53:44 +0200, Jehan-Guillaume de Rorthais wrote:
> From 88c2779679c5c9625ca5348eec0543daab5ccab4 Mon Sep 17 00:00:00 2001
> From: Jehan-Guillaume de Rorthais
> Date: Tue, 1 Jun 2021 13:25:57 +0200
> Subject: [PATCH 1/2] Add pg_stat_waitaccum view.
>
> pg_stat_waitaccum shows
Hi,
On 2021-06-03 17:52:24 -0700, Jeff Davis wrote:
> I agree that would be very conventient for non-heap AMs. There's a very
> old commit[3] that says:
>
> + /*
> +* Note that unlike IndexScan, SeqScan never use keys
> +* in heap_beginscan (and this is very bad) - so, here
>
On Fri, 2021-06-11 at 11:56 -0700, Andres Freund wrote:
> That doesn't work as easily in older versions because there was no
> SQL
> support in replication connections until PG 10...
9.6 will be EOL this year. I don't really see why such old versions are
relevant to this discussion.
Regards,
On 2021-06-11 11:49:19 -0700, Jeff Davis wrote:
> All the client would have to do is "SELECT confirmed_flush_lsn FROM
> pg_replication_slots WHERE slot_name='myslot'", and compare it to the
> stored value.
That doesn't work as easily in older versions because there was no SQL
support in replicatio
On Fri, 2021-06-11 at 10:40 -0700, Andres Freund wrote:
> Especially because it very well might break existing working
> setups...
Please address my concerns[1].
Regards,
Jeff Davis
[1]
https://www.postgresql.org/message-id/e22a4606333ce1032e29fe2fb1aa9036e6f0ca98.camel%40j-davis.com
On Fri, 2021-06-11 at 13:15 -0400, Robert Haas wrote:
> on it, but it seems to me that the comment does explain this, and
> that
> it's basically the same explanation as what Amit said.
It only addresses the "pro" side of the behavior, not the "con". It's a
bit like saying "Given that we are in th
Hi,
On 2021-06-11 13:15:11 -0400, Robert Haas wrote:
> On Fri, Jun 11, 2021 at 2:23 AM Jeff Davis wrote:
> > * The comment acknowledges that a user might expect an error in that
> > case; but doesn't really address why the user would expect an error,
> > and why it's OK to violate that expectatio
On Thu, Jun 10, 2021 at 8:38 PM Amit Langote
wrote:
> Hi Nitin,
>
> On Thu, Jun 3, 2021 at 11:45 PM Nitin Jadhav
> wrote:
> > > I'll wait for you to post a new patch addressing at least the comments
> > > in my earlier email. Also, please make sure to run `make check`
> > > successfully before
On Fri, Jun 11, 2021 at 2:23 AM Jeff Davis wrote:
> * The comment acknowledges that a user might expect an error in that
> case; but doesn't really address why the user would expect an error,
> and why it's OK to violate that expectation.
This code was written by Andres, so he'd be the best perso
On Thu, Jun 10, 2021 at 05:39:00PM -0400, Andrew Dunstan wrote:
> I suspect "an historic" is bordering on archaic even in the UK these days.
Don't trigger me on the difference between "historic" and "historical"! ;-)
(Hey, not every day I get to trim quoted text to one line --- see recent
pgsql-
On 2021-Jun-10, Álvaro Herrera wrote:
> Here's a version that I feel is committable (0001). There was an issue
> when returning from the inner loop, if in a previous iteration we had
> released the lock. In that case we need to return with the lock not
> held, so that the caller can acquire it a
On 2021/05/11 13:37, Masahiko Sawada wrote:
I've attached the updated patches that incorporated comments from
Zhihong and Ikeda-san.
Thanks for updating the patches!
I'm still reading these patches, but I'd like to share some review comments
that I found so far.
(1)
+/* Remove the foreign
On 11/06/2021 18:31, Tom Lane wrote:
Jason Kim writes:
In the middle of GIN index testing, there are some selects that are on
a different table array_op_test that doesn't even have an index. They
probably were supposed to be selects to table array_index_op_test like
the other ones around the a
Jason Kim writes:
> In the middle of GIN index testing, there are some selects that are on
> a different table array_op_test that doesn't even have an index. They
> probably were supposed to be selects to table array_index_op_test like
> the other ones around the area.
I think it's probably inte
Amit Kapila writes:
> On Fri, Jun 11, 2021 at 12:20 AM Tom Lane wrote:
>> Another thing
>> I'm wondering is how many of these messages really need to be
>> translated. We could use errmsg_internal and avoid burdening the
>> translators, perhaps.
> Not sure but I see all existing similar ereport
Kyotaro Horiguchi writes:
>> ==~_~===-=-===~_~==
>> pgsql.build/src/bin/pg_verifybackup/tmp_check/log/003_corruption_primary.log
>> ==~_~===-=-===~_~==
>> ...
>> 2021-06-08 16:17:41.706 CEST [51792:9] 003_corruption.pl LOG: received
>> replication command: START_REPLICATION SLOT "pg_basebackup
Hello Hayato-san,
I played pgbench with wrong parameters,
That's good:-)
and I found bug-candidate.
1. Do initdb and start.
2. Initialize schema and data with "scale factor" = 1.
3. execute following command many times:
$ pgbench -c 101 -j 10 postgres
Then, sometimes the negative " ini
Dilip Kumar writes:
> On Fri, Jun 11, 2021 at 11:45 AM Kyotaro Horiguchi
> wrote:
>>> ==~_~===-=-===~_~==
>>> pgsql.build/src/test/recovery/tmp_check/log/025_stuck_on_old_timeline_primary.log
>>> ==~_~===-=-===~_~==
>>> ...
>>> The system cannot find the path specified.
>>> 2021-06-10 22:56:17.
Michael Paquier writes:
> On Fri, Jun 11, 2021 at 05:38:34PM +0530, Amit Kapila wrote:
>> It seems the error happens in both the tests when after issuing a
>> KILL, we are trying to reconnect. Can we do anything for this?
> This is the same problem as c757a3da and 6d41dd0, where we write a
> quer
Bonjour Michaël,
+ /* flush remaining stats */
+ if (!logged && latency == 0.0)
+ logAgg(logfile, agg);
You are right, this is missing the final stats. Why the choice of
latency here for the check?
For me zero latency really says that there
On 2021-Jun-11, Michael Paquier wrote:
> Following up with the recent thread that dealt with the same $subject
> for the TAP tests, I have gone through pg_regress.c:
> https://www.postgresql.org/message-id/ylbjjrpuciez7...@paquier.xyz
Good idea.
> The list of environment variables that had bette
On Fri, Jun 11, 2021 at 11:37 AM Dilip Kumar wrote:
>
> On Thu, Jun 10, 2021 at 7:15 PM Amit Kapila wrote:
> >
>
> >
> > Please find the patch for HEAD attached. Can you please prepare the
> > patch for back-branches by doing all the changes I have done in the
> > patch for HEAD?
>
> Done
>
Than
Yura Sokolov writes:
> This makes me think, Close message were intended to be used
> but simply forgotten when libpq patch were made.
> Tom, could I be right?
You could argue all day about what the intentions were nearly twenty
years ago. But the facts on the ground are that we don't issue Close
On Fri, Jun 11, 2021, 6:22 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Sat, Jun 5, 2021 at 7:02 PM vignesh C wrote:
> > Thanks for identifying and reporting this issue. I have \dn with the
> > equivalent query to display only the publication name. The updated
> > pa
On Sat, Jun 5, 2021 at 7:02 PM vignesh C wrote:
> Thanks for identifying and reporting this issue. I have \dn with the
> equivalent query to display only the publication name. The updated
> patch has the fix for the same.
Currently, FOR ALL TABLES is there to add all the tables(existing and
futur
On Thu, Jun 10, 2021 at 9:58 PM tsunakawa.ta...@fujitsu.com
wrote:
> I understand that. As I cited yesterday and possibly before, that's why
> xa_commit() returns various return codes. So, I have never suggested that
> FDWs should not report an error and always report success for the commit
>
On Fri, Jun 11, 2021 at 11:00:40AM +0300, Aleksander Alekseev wrote:
> The last argument should be `false` then.
Hm, nope. I think that we had better pass true as argument here.
First, this is more consistent with the identity lookup (OK, it does
not matter as we would have discarded the object
On Fri, Jun 11, 2021 at 05:38:34PM +0530, Amit Kapila wrote:
> It seems the error happens in both the tests when after issuing a
> KILL, we are trying to reconnect. Can we do anything for this?
This is the same problem as c757a3da and 6d41dd0, where we write a
query to a pipe but the kill, causing
I noticed that we are getting random failures [1][2][3] in the
recovery test on hoverfly. The failures are in 022_crash_temp_files
and 013_crash_restart. Both the tests failed due to same reason:
ack Broken pipe: write( 13, 'SELECT 1' ) at
/home/nm/src/build/IPC-Run-0.94/lib/IPC/Run/IO.pm line 558
Hi all,
Following up with the recent thread that dealt with the same $subject
for the TAP tests, I have gone through pg_regress.c:
https://www.postgresql.org/message-id/ylbjjrpuciez7...@paquier.xyz
The list of environment variables that had better be reset when using
a temporary instance is very
On 6/11/21 6:55 AM, Noah Misch wrote:
On Sun, Jun 06, 2021 at 09:13:17PM +0200, Tomas Vondra wrote:
On 6/6/21 7:37 AM, Noah Misch wrote:
On Sat, Mar 27, 2021 at 01:17:14AM +0100, Tomas Vondra wrote:
OK, pushed after a bit more polishing and testing.
This added a "transformed" field to Cr
On Fri, Jun 11, 2021 at 8:14 PM Amit Kapila wrote:
>
> On Thu, Jun 10, 2021 at 2:04 PM Ajin Cherian wrote:
> >
>
> The new patches look mostly good apart from the below cosmetic issues.
> I think the question is whether we want to do these for PG-14 or
> postpone them till PG-15. I think these do
On Thu, Jun 10, 2021 at 2:04 PM Ajin Cherian wrote:
>
The new patches look mostly good apart from the below cosmetic issues.
I think the question is whether we want to do these for PG-14 or
postpone them till PG-15. I think these don't appear to be risky
changes so we can get them in PG-14 as tha
On Fri, Jun 11, 2021 at 11:45 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 10 Jun 2021 21:53:18 -0400, Tom Lane wrote in
> tgl> Please note that conchuela and jacana are still failing ...
>
> I forgot jacana's case..
>
> It is failing for the issue the first patch should have fixed.
>
> > ==~_~===-=-=
In the middle of GIN index testing, there are some selects that are on
a different table array_op_test that doesn't even have an index. They
probably were supposed to be selects to table array_index_op_test like
the other ones around the area.
Fix that. The expected output should stay the same b
Hi Hackers,
I played pgbench with wrong parameters, and I found bug-candidate.
The latest commit in my source is 3a09d75.
1. Do initdb and start.
2. Initialize schema and data with "scale factor" = 1.
3. execute following command many times:
$ pgbench -c 101 -j 10 postgres
Then, sometimes the n
Hi Michael,
> /* The type can never be NULL */
> type = getObjectTypeDescription(&addr, true);
The last argument should be `false` then.
--
Best regards,
Aleksander Alekseev
v4-0001-pg_event_trigger_ddl_commands.patch
Description: Binary data
On Fri, Jun 11, 2021 at 03:32:28PM +0900, Kyotaro Horiguchi wrote:
> At Fri, 11 Jun 2021 10:48:32 +0800, Julien Rouhaud wrote
> in
> >
> > "far from perfect" is a strong understatement for "appears to work but will
> > randomly and silently breaks everything without a simple way to detect it".
On Fri, Jun 11, 2021 at 03:32:28PM +0900, Kyotaro Horiguchi wrote:
> At Fri, 11 Jun 2021 10:48:32 +0800, Julien Rouhaud wrote
> in
>> "far from perfect" is a strong understatement for "appears to work but will
>> randomly and silently breaks everything without a simple way to detect it".
Yeah.
At Fri, 11 Jun 2021 15:56:55 +0900 (JST), Kyotaro Horiguchi
wrote in
> Doesn't threadRun already doing that?
(s/Does/Is)
That's once per thread, sorry for the noise.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
95 matches
Mail list logo
