On 27.12.21 14:15, Ashutosh Bapat wrote:
That looks like a good change. I wonder what motivates that now? Why
wasn't it added when the usages grew? Are there more Boolean usages
planned?
Mainly, I was looking at Integer/makeInteger() and noticed that most
uses of those weren't actually integer
Hi Tushar,
You need to apply Robert's v10 version patches 0002, 0003 and 0004, before
applying the lz4 patch(v8 version).
Please let me know if you still face any issues.
Regards,
Jeevan Ladhe
On Mon, Dec 27, 2021 at 7:01 PM tushar
wrote:
> On 11/22/21 11:05 PM, Jeevan Ladhe wrote:
> > Please
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 servers to debug and analyze inactive replication slot
> > issues.
> >
> > Though
On 2021/12/24 19:40, Tomas Vondra wrote:
Maybe, but what would such workload look like? Based on the tests I did, such
workload probably can't generate any WAL. The amount of WAL added by the change
is tiny, the regression is caused by having to flush WAL.
The only plausible workload I can
On 2021/12/28 9:32, Masahiko Sawada wrote:
Doesn't this query return 64? So the expression "substring(str for
(SELECT max_identifier_length FROM pg_control_init()))" returns the
first 64 characters of the given string while the application_name is
truncated to be 63 (NAMEDATALEN - 1) characters
Hi,
For buildDefItem():
+ if (strcmp(val, "true") == 0)
+ return makeDefElem(pstrdup(name),
+ (Node *) makeBoolean(true),
+ -1);
+ if (strcmp(val, "false") == 0)
Should 'TRUE' / 'FALSE' be considered above ?
-
On Fri, Dec 24, 2021 at 5:54 PM Bharath Rupireddy
wrote:
>
> On Fri, Dec 24, 2021 at 5:42 PM Michael Paquier wrote:
> >
> > On Fri, Dec 24, 2021 at 02:51:34PM +0900, Kyotaro Horiguchi wrote:
> > > I thougt about something like the following, but your proposal may be
> > > clearer.
> >
> > +"L
On Thursday, December 16, 2021 8:51 PM osumi.takami...@fujitsu.com
wrote:
> Attached the updated patch v14.
A comment to the timing of printing a log:
After the log[1] was printed, I altered subscription's option
(DISABLE_ON_ERROR) from true to false before invoking DisableSubscriptionOnError
to
Hi,
Can the postgres server ever have/generate out of sequence WAL files?
For instance, 0001020C00A2, 0001020C00A3,
0001020C00A5 and so on, missing 0001020C00A4.
Manual/Accidental deletion of the WAL files can happes, but are there
any other extreme
On 12/27/21 21:24, Peter Eisentraut wrote:
On 24.12.21 09:04, Kyotaro Horiguchi wrote:
Still, as Fujii-san concerns, I'm afraid that some people may suffer
the degradation the patch causes. I wonder it is acceptable to get
back the previous behavior by exposing SEQ_LOG_VALS itself or a
boolean
On Sat, Dec 25, 2021 at 9:25 PM Dilip Kumar wrote:
> On Sun, Dec 26, 2021 at 10:36 AM SATYANARAYANA NARLAPURAM <
> satyanarlapu...@gmail.com> wrote:
>
>>
>>> Actually all the WAL insertions are done under a critical section
>>> (except few exceptions), that means if you see all the references of
On Tue, Dec 28, 2021 at 8:57 AM kuroda.hay...@fujitsu.com
wrote:
>
> Dear Sawada-san,
>
> > If so, we need to do substring(... for
> > 63) instead.
Just to be clear, I meant substring(... for NAMEDATALEN - 1).
>
> Yeah, the parameter will be truncated as one less than NAMEDATALEN:
>
> ```
> max_
I do agree that tracking progress by # of blocks scanned is not deterministic
for all index types.
Based on this feedback, I went back to the drawing board on this.
Something like below may make more sense.
In pg_stat_progress_vacuum, introduce 2 new columns:
1. total_index_vacuum - total #
Dear Sawada-san,
> Good idea. But the application_name is actually truncated to 63
> characters (NAMEDATALEN - 1)? If so, we need to do substring(... for
> 63) instead.
Yeah, the parameter will be truncated as one less than NAMEDATALEN:
```
max_identifier_length (integer)
Reports the maximum ide
I wrote:
> Concretely, I think we should do the attached, which removes much of
> 75d22069e and does the check at the point of placeholder creation.
I pushed that, and along the way moved the test case to be beside
the existing tests concerning custom GUC names, rather than appended
at the end of
On 24.12.21 09:04, Kyotaro Horiguchi wrote:
Still, as Fujii-san concerns, I'm afraid that some people may suffer
the degradation the patch causes. I wonder it is acceptable to get
back the previous behavior by exposing SEQ_LOG_VALS itself or a
boolean to do that, as a 'not-recommended-to-use' va
On 2021-Dec-27, Tom Lane wrote:
> Alvaro Herrera writes:
> > Determining that an array has a NULL element seems convoluted. I ended
> > up with this query, where comparing the result of array_positions() with
> > an empty array does that. If anybody knows of a simpler way, or any
> > situations
Isaac Morland writes:
> On Mon, 27 Dec 2021 at 03:22, Joel Jacobson wrote:
>> However, I see one problem with leaving out the key columns:
>> First, there is only one FK in permission pointing to role, and we write a
>> query leaving out the key columns.
>> Then, another different FK in permissio
Please send your patches as *.diff or *.patch, so they're processed by the
patch tester. Preferably with commit messages; git format-patch is the usual
tool for this.
http://cfbot.cputube.org/sami-imseih.html
(Occasionally, it's also useful to send a *.txt to avoid the cfbot processing
the wrong
Alvaro Herrera writes:
> Determining that an array has a NULL element seems convoluted. I ended
> up with this query, where comparing the result of array_positions() with
> an empty array does that. If anybody knows of a simpler way, or any
> situations in which this fails, I'm all ears.
Maybe
Peter Smith writes:
> The most recent cfbot run for a patch I am interested in has failed a
> newly added regression test.
> Please see http://cfbot.cputube.org/ for 36/2906
> The failure logs [2] are very curious because the error message is
> what was expected but it has a different position of
Justin Pryzby writes:
> I think the current behavior of the regression test SQL scripts is exactly the
> opposite of what's desirable for almost all other scripts. The attached makes
> ON_ERROR_STOP the default, and runs the regression tests with ON_ERROR_STOP=0.
> Is it viable to consider chang
>
>
> First, there is only one FK in permission pointing to role, and we write a
> query leaving out the key columns.
> Then, another different FK in permission pointing to role is later added,
> and our old query is suddenly in trouble.
>
>
We already have that problem with cases where two tables
Determining that an array has a NULL element seems convoluted. I ended
up with this query, where comparing the result of array_positions() with
an empty array does that. If anybody knows of a simpler way, or any
situations in which this fails, I'm all ears.
with published_cols as (
selec
On Mon, Dec 27, 2021, at 17:03, Isaac Morland wrote:
> On Mon, 27 Dec 2021 at 10:20, Joel Jacobson wrote:
>
> Foreign key constraint names have been given the same names as the referenced
> tables.
>
> While I agree this could be a simple approach in many real cases for having
> easy to underst
po 27. 12. 2021 v 17:10 odesílatel Justin Pryzby
napsal:
> On Mon, Dec 06, 2021 at 09:08:56AM -0600, Justin Pryzby wrote:
> > I raised this issue a few years ago.
> >
> https://www.postgresql.org/message-id/20181217175841.GS13019%40telsasoft.com
> >
> > |[pryzbyj@database ~]$ psql -v VERBOSITY=te
On Mon, Dec 06, 2021 at 09:08:56AM -0600, Justin Pryzby wrote:
> I raised this issue a few years ago.
> https://www.postgresql.org/message-id/20181217175841.GS13019%40telsasoft.com
>
> |[pryzbyj@database ~]$ psql -v VERBOSITY=terse ts -xtc 'ONE' -c "SELECT
> 'TWO'"; echo "exit status $?"
> |ERROR
On Mon, 27 Dec 2021 at 10:20, Joel Jacobson wrote:
> Foreign key constraint names have been given the same names as the
> referenced tables.
>
While I agree this could be a simple approach in many real cases for having
easy to understand FK constraint names, I wonder if for illustration and
exp
wenjing zeng writes:
> I found that in the index_update_stats function, i.e. the CREATE
> INDEX/REINDEX/Truncate INDEX process,
> relchche is invalidated whether the index information is updated. I want to
> know why you're did this
Did you read the function's header comment? It says
* NOTE:
Joel Jacobson schrieb am Mo., 27. Dez. 2021, 16:21:
> >On Mon, Dec 27, 2021, at 15:48, Isaac Morland wrote:
> >I thought the proposal was to give the FK constraint name.
> >However, if the idea now is to allow leaving that out also if there
> >is only one FK, then that's also OK as long as people
>On Mon, Dec 27, 2021, at 15:48, Isaac Morland wrote:
>I thought the proposal was to give the FK constraint name.
>However, if the idea now is to allow leaving that out also if there
>is only one FK, then that's also OK as long as people understand it can break
>in the same way NATURAL JOIN can b
On 2021-Dec-27, Peter Eisentraut wrote:
> This patch adds a new node type Boolean, to go alongside the "value" nodes
> Integer, Float, String, etc. This seems appropriate given that Boolean
> values are a fundamental part of the system and are used a lot.
I like the idea. I'm surprised that the
Ashutosh Bapat writes:
> That looks like a good change. I wonder what motivates that now? Why
> wasn't it added when the usages grew?
You'd have to find some of the original Berkeley people to get an
answer for that. Possibly it's got something to do with the fact
that C didn't have a separate b
On Mon, 27 Dec 2021 at 03:22, Joel Jacobson wrote:
> However, I see one problem with leaving out the key columns:
> First, there is only one FK in permission pointing to role, and we write a
> query leaving out the key columns.
> Then, another different FK in permission pointing to role is later
On Thu, Dec 9, 2021 at 12:08 PM Bharath Rupireddy
wrote:
>
> On Wed, Dec 8, 2021 at 7:43 AM Bharath Rupireddy
> wrote:
> >
> > On Wed, Dec 8, 2021 at 7:34 AM Tomas Vondra
> > wrote:
> > > >> I agree it might be useful to provide information about the nature of
> > > >> the checkpoint, and perhap
On 11/22/21 11:05 PM, Jeevan Ladhe wrote:
Please find the lz4 compression patch here that basically has:
Thanks, Could you please rebase your patch, it is failing at my end -
[edb@centos7tushar pg15_lz]$ git apply /tmp/v8-0001-LZ4-compression.patch
error: patch failed: doc/src/sgml/ref/pg_baseb
On Mon, Dec 27, 2021 9:16 PM houzj.f...@fujitsu.com
wrote:
> On Thur, Dec 23, 2021 4:28 PM Peter Smith wrote:
> > Here is the v54* patch set:
>
> Attach the v55 patch set which add the following testcases in 0003 patch.
Sorry for the typo here, I mean the tests are added 0002 patch.
Best regar
That looks like a good change. I wonder what motivates that now? Why
wasn't it added when the usages grew? Are there more Boolean usages
planned?
I ask because this code change will affect ability to automatically
cherry-pick some of the patches.
defGetBoolean() - please update the comment in the
On 23.12.21 12:40, Fabien COELHO wrote:
In [0], it was reported that certain replication commands result in
infinite loops because of faulty error handling. This still happens.
I wrote a test for it, attached here. (I threw in a few more basic
tests, just to have some more coverage that was
po 27. 12. 2021 v 13:05 odesílatel Sascha Kuhl
napsal:
>
>
> Pavel Stehule schrieb am Mo., 27. Dez. 2021,
> 12:28:
>
>>
>>
>> po 27. 12. 2021 v 12:23 odesílatel Sascha Kuhl
>> napsal:
>>
>>>
>>>
>>> Sascha Kuhl schrieb am Mo., 27. Dez. 2021,
>>> 12:13:
>>>
Pavel Stehule schrieb
Pavel Stehule schrieb am Mo., 27. Dez. 2021,
12:28:
>
>
> po 27. 12. 2021 v 12:23 odesílatel Sascha Kuhl
> napsal:
>
>>
>>
>> Sascha Kuhl schrieb am Mo., 27. Dez. 2021, 12:13:
>>
>>>
>>>
>>> Pavel Stehule schrieb am Mo., 27. Dez. 2021,
>>> 11:49:
>>>
Hi
po 27. 12. 2021 v 11:24 o
po 27. 12. 2021 v 12:23 odesílatel Sascha Kuhl
napsal:
>
>
> Sascha Kuhl schrieb am Mo., 27. Dez. 2021, 12:13:
>
>>
>>
>> Pavel Stehule schrieb am Mo., 27. Dez. 2021,
>> 11:49:
>>
>>> Hi
>>>
>>> po 27. 12. 2021 v 11:24 odesílatel Sascha Kuhl
>>> napsal:
>>>
You think, all values are valid
Sascha Kuhl schrieb am Mo., 27. Dez. 2021, 12:13:
>
>
> Pavel Stehule schrieb am Mo., 27. Dez. 2021,
> 11:49:
>
>> Hi
>>
>> po 27. 12. 2021 v 11:24 odesílatel Sascha Kuhl
>> napsal:
>>
>>> You think, all values are valid. Is a higher german order valid for
>>> Turkey, that only know baskets, as
On Mon, Dec 27, 2021 at 1:40 PM Fujii Masao wrote:
>
>
>
> On 2021/12/27 10:40, kuroda.hay...@fujitsu.com wrote:
> > Dear Fujii-san, Horiguchi-san,
> >
> > I confirmed that the feature was committed but reverted the test.
> > Now I'm checking buildfarm.
>
> Attached is the patch that adds the regr
Pavel Stehule schrieb am Mo., 27. Dez. 2021,
11:49:
> Hi
>
> po 27. 12. 2021 v 11:24 odesílatel Sascha Kuhl
> napsal:
>
>> You think, all values are valid. Is a higher german order valid for
>> Turkey, that only know baskets, as a Form of order. For me not all forms of
>> all are valid for all.
Hi
po 27. 12. 2021 v 11:24 odesílatel Sascha Kuhl
napsal:
> You think, all values are valid. Is a higher german order valid for
> Turkey, that only know baskets, as a Form of order. For me not all forms of
> all are valid for all. You cannot Export or Import food that You dislike,
> because it w
You think, all values are valid. Is a higher german order valid for Turkey,
that only know baskets, as a Form of order. For me not all forms of all are
valid for all. You cannot Export or Import food that You dislike, because
it would hurt you. Do you have dishes that you dislike? Is all valid for
On Mon, Dec 27, 2021 at 5:09 PM Pavel Stehule wrote:
>
> po 27. 12. 2021 v 10:02 odesílatel Peter Eisentraut
> napsal:
>>
>> This patch adds a new node type Boolean, to go alongside the "value"
>> nodes Integer, Float, String, etc. This seems appropriate given that
>> Boolean values are a funda
po 27. 12. 2021 v 11:08 odesílatel Sascha Kuhl
napsal:
> Can that boolean node be cultural dependent validation for the value? By
> the developer? By all?
>
why?
The boolean node is not a boolean type.
This is an internal feature. There should not be any cultural dependency
Regards
Pavel
>
Can that boolean node be cultural dependent validation for the value? By
the developer? By all?
Pavel Stehule schrieb am Mo., 27. Dez. 2021,
10:09:
>
>
> po 27. 12. 2021 v 10:02 odesílatel Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> napsal:
>
>>
>> This patch adds a new node type Boo
Hi Tom
I would like to ask you about the details of index build.
I found that in the index_update_stats function, i.e. the CREATE
INDEX/REINDEX/Truncate INDEX process,
relchche is invalidated whether the index information is updated. I want to
know why you're did this
The code is:
po 27. 12. 2021 v 10:02 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
>
> This patch adds a new node type Boolean, to go alongside the "value"
> nodes Integer, Float, String, etc. This seems appropriate given that
> Boolean values are a fundamental part of the system an
This patch adds a new node type Boolean, to go alongside the "value"
nodes Integer, Float, String, etc. This seems appropriate given that
Boolean values are a fundamental part of the system and are used a lot.
Before, SQL-level Boolean constants were represented by a string with
a cast, and
On Sun, Dec 26, 2021, at 23:25, Corey Huinker wrote:
> My second guess would be:
> FROM permission p
> LEFT JOIN role AS r ON [FOREIGN] KEY [(p.col1 [, p.col2 ...])]
>
> where the key spec is only required when there are multiple foreign keys in
> permission pointing to role.
>
> But my first gues
54 matches
Mail list logo
