Em sex., 4 de abr. de 2025 às 13:13, Maciek Sakrejda
escreveu:
> maciek=# select pg_typeof(1e1)
Correct, this explains that
regards
Marcos
I was deleting thousands of records each time with \gexec, then ...
This one works
select format('delete from table where ID = any(%L::integer[]);',
array_agg(ID)), (ord-1)/1 from (
select * from generate_series(15e2,65e5) with ordinality) x(ID, ord) group
by 2 order by 2;
But it's easier to
Em ter., 1 de abr. de 2025 às 02:00, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
Wouldn't it be good to add the use of parentheses using posix ? It's useful
and rarely documented
substring('Thomas', '...$')
+substring('Email: johnj...@mymail.com, Name: John' from
'@(.
Em qua., 26 de mar. de 2025 às 08:58, Marcos Pegoraro
escreveu:
> func.sgml doesn't mention lgamma function, so users will think just gamma
> exists, is that correct ?
>
Sorry, it's my fault. I didn't read the entire file.
regards
Marcos
Em qua., 26 de mar. de 2025 às 06:50, Dean Rasheed
escreveu:
> OK, thanks. I've updated that comment and committed it.
func.sgml doesn't mention lgamma function, so users will think just gamma
exists, is that correct ?
regards
Marcos
Em qua., 19 de mar. de 2025 às 18:14, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> Having been in filelist.sgml a bit recently I've noticed that the original
> alphabetical ordering of the entities therein hasn't been adhered to.
> Partly, I suspect, because there is no guidance abo
Em seg., 17 de mar. de 2025 às 15:33, Pavel Stehule
escreveu:
> I was asked for sending a reduced patchset
>
Would be good to explain what this reduced patchset is.
Complete patch contains this and that
Reduced patch contains only this.
Regards
Marcos
Em qui., 13 de mar. de 2025 às 09:17, Álvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> I tried this example all the way back to pg 9.5, and they all end up
> with a single constraint and a single index -- namely, the test_pk
> constraint and corresponding index. There's no second index and n
CREATE TABLE table_test (
foo text NOT NULL,
CONSTRAINT test_pk PRIMARY KEY (foo),
CONSTRAINT test_uq UNIQUE (foo)
);
building index "pg_toast_29364884_index" on table "pg_toast_29364884"
serially
building index "test_pk" on table "table_test" serially
pg_class has 3 records, table, it
Em ter., 11 de mar. de 2025 às 17:43, Tom Lane escreveu:
> I think that idea (changing all the docs) is a complete nonstarter
> because people would not understand why the results they get don't
> look like what it says in the docs. Of course, we could fix that
> by changing the factory default
Em ter., 11 de mar. de 2025 às 16:47, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> Since COPY uses \N I figured it was a decent choice. or came
>> to mind too, but there were long compared to 1, 2, and 4 that appear along
>> side it.
>>
> Well, I would use , it doesn't need any ex
Em ter., 11 de mar. de 2025 às 12:52, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> The markup surrounding the examples is correct now and I decided \N was
> the most useful representation of NULL given that the query data is single
> digit numbers. I really hate the non-readability
You mentioned fillfactor only on cluster notes, would be good to mention it
on refsynopsisdiv, I think.
+
+ REPACK reclaims storage occupied by dead
+ tuples. Unlike VACUUM, it does so by rewriting the
+ entire contents of the table specified
+ by table_name into a new
disk
- file wit
Em qui., 6 de fev. de 2025 às 12:32, Greg Sabino Mullane
escreveu:
> That seems a somewhat arbitrary goal for us to optimize for.
>
well, my goal was to standardize these values. As examples of
non standardization you have ...
"The default is typically 100 connections".
Tipically ? Is it 100 or
.postgresql.org/docs/current/runtime-config-query.html#GUC-RANDOM-PAGE-COST
regards
Marcos
Em qua., 5 de fev. de 2025 às 20:59, Peter Smith
escreveu:
> On Thu, Feb 6, 2025 at 8:08 AM Marcos Pegoraro wrote:
> >
> > Reading DOCs sometimes is boring because you want to know only
Em ter., 21 de jan. de 2025 às 14:50, Álvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> I have to ask, why do you think this is important?
>
I'm just reading sources, navigating on files history and learning, so
don't be furious with me.
Why is this important ? Well, if that file has a 2014-2
Em ter., 21 de jan. de 2025 às 12:36, Tom Lane escreveu:
> so we prefer to use the same copyright dates as related older files even
> in less
> clear-cut cases.
>
Thank you Tom for your time.
But these numbers seem inaccurate, because there are 1644 copyright strings
but 1521 are 1996-2025. So,
Today Amit Langote committed execScan.h and put on its header years from
1996 to 2025. Those years are what exactly ?
This file has 1996, but sometimes is the first commit year of that file,
sometimes is completely unrelated. What is right for it ? Need that to be
adjusted ?
/*
Em sex., 17 de jan. de 2025 às 13:01, Bruce Momjian
escreveu:
> Okay, good summary. Now, can people give feedback that they would want
> this committed to PostgreSQL?
I would love to have this functionality as soon as possible.
I already mentioned to Pavel that he did something very big, and
c
>
> > pá 17. 1. 2025 v 16:35 odesílatel Bruce Momjian
> napsal:
>
> Okay, good summary. Now, can people give feedback that they would want
> this committed to PostgreSQL?
>
I would love to have this functionality as soon as possible.
I already mentioned to Pavel that he did something very big, a
>
> On 14.01.2025 22:51, Melanie Plageman wrote:
>
There is a typo on committed vacuumlazy.c file
* If the TID store fills up in phase I, vacuum suspends phase I, proceeds
to
* phases II and II, cleaning up the dead tuples referenced in the current
TID
* store. This empties the TID store resume
Em sex., 10 de jan. de 2025 às 06:31, Antonin Houska
escreveu:
> Thus I understand Alvaro's objections against VACUUM (FULL, CONCURRENTLY).
>
> Therefore I can imagine adding a new command that acts like VACUUM (FULL,
> CONCURRENTLY), but does not try to be CLUSTER (CONCURRENTL).
>
If VACUUM F
Em qua., 8 de jan. de 2025 às 16:23, Vik Fearing
escreveu:
> This is lying to the planner, and you get to enjoy whatever breaks
> because of it. A function that accesses external data is not immutable;
> it is stable at best.
>
I understand that, but it's not documented, so users can think that
Em qua., 8 de jan. de 2025 às 13:14, Peter Eisentraut
escreveu:
> Here is a new patch version where I have gathered various pieces of
> feedback and improvement suggestions that are scattered over this
> thread. I hope I got them all. I will respond to the respective
> messages directly to give
The word below is commonly used on DOCs, but I didn't find it as a link.
Wouldn't it be better to write what you are linking to, instead of the word
below ?
(See Null-Valued Operands for
more explanation.)
instead of
(See below for more explanation.)
Multi-Element
Comparisons.
instead of
noted be
Em dom., 22 de dez. de 2024 às 15:07, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
On section Null-Valued Settings is not easy to understand that "show
example.string" will result in an "ERROR: unrecognized...", that BEGIN or
ROLLBACK does not return anything. So, what do you think ab
Em dom., 22 de dez. de 2024 às 12:02, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
You have detailed IS NULL and IS NOT NULL predicates but not mention their
counterparts ISNULL and NOTNULL, wouldn't it be good to explain that too ?
Maybe pointing to its page "functions-comparison"
r
>
> Em ter., 10 de dez. de 2024 às 20:00, David G. Johnston <
> david.g.johns...@gmail.com> escreveu:
>
Section nullvalues-filtering you are showing filtering with equal and not
equal. Wouldn't it be better if you show just one of them and the other
using DISTINCT FROM, which would get different r
Em ter., 10 de dez. de 2024 às 20:00, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> I got rid of the row counts on the examples.
>
Cool, I would love to get rid all of them, like I proposed on [1].
> When I finalize the examples I'm probably going to \pset null .
>
Yes, much better
Em seg., 9 de dez. de 2024 às 13:31, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> I'm OK with adding more cross-references (links or just brief comparative
> verbiage like the above) to non-SQL null value treatment but this document,
> for this patch, is going to focus solely on SQL
Em sex., 29 de nov. de 2024 às 15:49, Masahiko Sawada
escreveu:
> uuidv7 () uuid
>
Wouldn't it be better to change this to
uuidv7 ([interval]) uuid
Em ter., 19 de nov. de 2024 às 13:27, Peter Eisentraut
escreveu:
> 3. Some documentation updates to explain some of the differences between
> NO ACTION and RESTRICT better.
>
There is a typo on your commit "doc: Improve description of referential
actions"
There is also a noticeable difference b
There are lots of strange things related to this (... rows)
First, (0 rows) are completely useless. If no one record is shown, why do
we need that list ?
We could change (0 rows), like this one on dblink.sgml
SELECT * FROM dblink_get_notify();
notify_name | be_pid | extra
-++-
Em dom., 24 de nov. de 2024 às 18:54, David Rowley
escreveu:
> > SELECT format('|%10s|', 'foo');
This example you said returns one value, so I think it is ok.
I'm talking about lists with multiple fields or multiple lines. In [1] we
have both modes.
I don't think that "(2 rows)" is useful
sele
Em dom., 24 de nov. de 2024 às 13:57, Tom Lane escreveu:
> Yeah. You can set it to INFO if you like, but the behavior is not
> different from setting it to NOTICE.
No, I don't think they have the same behavior.
If you set client_min_messages to Error then notice will not be sent, info
will wil
If I try to set client_min_messages with a wrong value it raises an error
and its hint is
"Available values: debug5, debug4, debug3, debug2, debug1, log, notice,
warning, error."
Why is not INFO option on this hint ?
regards
Marcos
Em qui., 21 de nov. de 2024 às 12:04, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
Typo in NuLl, mixed upper and lower case.
SELECT
NULL AS "Literal Null Value",
pg_typeof(null) AS "Type of Null",
pg_typeof(NuLl::text) AS "Type of Cast null",
cast(null as text) AS "Ca
There is no rule of when the number of records at the end of the lists
should be shown or not
Sometimes we show that line "(4 rows)", but sometimes not.
Should we have a standard for it ? Should we add them all or remove them
all ?
I think they are useless. Or maybe shown when no rows are returned.
Em qui., 21 de nov. de 2024 às 12:02, Marcos Pegoraro
escreveu:
Well, all comparisons with JSONs runs differently with null values, so
maybe an example would help
select f1 = f2 "JS Object Equal - Right",
f1->'a' = f2->'a' "JS Value Equal - Right
Em qui., 21 de nov. de 2024 às 11:42, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
>
> I'm not following your train of thought here. Since null == null in
> json-land there isn't a need for or concept of "is distinct from". We tend
> to not expend space on pointing out things that d
About JSONB_PATH, you said that "JSON null value is considered equal to
other JSON null values", but didn't say anything about IS DISTINCT FROM at
jsonb_path level. Wouldn't be good to mention something about it ?
select '{1,2}'::integer[] is distinct from null::integer[]
select jsonb_path_exists(
Em ter., 19 de nov. de 2024 às 16:15, Pavel Stehule
escreveu:
> I wrote POC of VARIABLE(varname) syntax support
>
Not related with POC of VARIABLE but seeing your patches ...
Wouldn't it be better to use just one syntax and message for what to do ON
COMMIT ?
When creating a new variable you us
Em qua., 20 de nov. de 2024 às 10:52, Pavel Stehule
escreveu:
> COMMIT can be a little bit messy. TRANSACTION END is more intuitive, I
> think.
>
>>
Exactly to be not messy I would just ON COMMIT for all, and DOCs can
explain that this option is ignored for temp objects and do the same at the
end
But it would be good to have this patch applied to all supported versions,
as soon as nothing was changed on that pg_dump option, no ?
regards
Marcos
Em seg., 18 de nov. de 2024 às 18:30, Bruce Momjian
escreveu:
> On Tue, Nov 5, 2024 at 10:12:20AM +0100, Álvaro Herrera wrote:
> > On 2024-Nov-0
Em ter., 29 de out. de 2024 às 09:01, Aleksander Alekseev <
aleksan...@timescale.com> escreveu:
> The proposed patch renames trim_array() to array_trim().
>
That Array Functions list on func.sgml is an ordered list, so the right
place for it should be before array_upper, right ?
regards
Marcos
Em seg., 28 de out. de 2024 às 14:06, Aleksander Alekseev <
aleksan...@timescale.com> escreveu:
> =# select '[1,2,3]' :: jsonb :: int[];
>
I think would be useful, cast int[] to json is not hard
select to_json('{1,5,9,12}'::int[]);
but json array to int[] is not that easy.
select js,
js
Em qui., 17 de out. de 2024 às 13:31, Bruce Momjian
escreveu:
> Oh, okay, but I think we need to say JSON null so we are clear --- patch
>
But true, false and null are all JSON, since you cannot do
select jsonb_path_query('{}'::jsonb,'$.track.segments[*].HR > 130') = true;
So, it would be bette
Em qua., 9 de out. de 2024 às 18:23, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
>
> Replaceable means the user is expected to substitute an expression in that
> location. One cannot specify a function name using an expression.
>
Sorry, I thought function parameters but said names.
Em qua., 9 de out. de 2024 às 16:16, Marcos Pegoraro
escreveu:
> Exponentiation, Square root and Cube root operators are not formatted with
> tag like others.
>
Paying more attention, there is no standard on any of those Comparison,
String, Math, Date/Time and so on functions and
Exponentiation, Square root and Cube root operators are not formatted with
tag like others.
https://www.postgresql.org/docs/current/functions-math.html
regards
Marcos
patch.diff
Description: Binary data
Em dom., 22 de set. de 2024 às 12:49, Roberto Mello
escreveu:
> If you're volunteering to add a MySQL, SQL Server, Mongo, etc porting to
> the docs, I'm sure it could be a
> nice addition.
>
And if we create a page like https://www.postgresql.org/about/featurematrix/
But instead of Postgres vers
Em sáb., 21 de set. de 2024 às 18:42, Bruce Momjian
escreveu:
> I suggest you explain what changes would make the docs better (meaing
> more useful).
>
Well, I think I already did this in this discussion.
Tom said that some functions were copied from Oracle, so it is ok to
mention them. I don't
Em sex., 20 de set. de 2024 às 18:34, Jonah H. Harris <
jonah.har...@gmail.com> escreveu:
> Seems to me this has already been answered well multiple times by multiple
> people; I’m not sure why this is such an issue, or one that warrants
> continued discussion.
>
No, I do not want to continue a d
Em sex., 20 de set. de 2024 às 15:11, Tomas Vondra
escreveu:
> IMHO it's quite reasonable to say "we do X, but this other product
> (which is what we try to mimic) does Y".
>
Ok, for Data Type Formatting Functions is fine, if they were really copied
from, but the others ...
Bug Reporting Guideli
Em sex., 20 de set. de 2024 às 13:18, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> It would be a boon to the community if someone were to put together a
> web/wiki page or mini-app that details this kind of information and, if
> considered accurate and relevant enough by the communi
Em sex., 20 de set. de 2024 às 11:56, Tomas Vondra
escreveu:
> It's not quite clear to me whether your suggestion is to not mention any
> other databases ever, or to always mention every existing one. ;-)
>
My suggestion is: Postgres DOCs are written and have to be read by Postgres
users, just t
Em sex., 20 de set. de 2024 às 12:53, Tom Lane escreveu:
> As far as the mentions in "Data Type Formatting Functions" go, those
> are there because those functions are not in the SQL standard; we
> stole the API definitions for them from Oracle, lock stock and barrel.
> (Except for the discrepanc
Why PostgreSQL DOCs needs to show or compare the Oracle way of doing things
?
I understand that on page Porting from Oracle PL/SQL is ok to mention
Oracle, but there are other places where it's not needed. Or, if it's ok to
mention, why not mention SQL Server or MySQL or any other ?
Bug Reporting
Em qua., 18 de set. de 2024 às 06:02, Peter Eisentraut
escreveu:
> Maybe this shouldn't be done between RC1 and GA. This is clearly a more
> complex topic that should go through a proper review and testing cycle.
>
I think this is just a question of decision, not reviewing or testing.
And I'm s
Em ter., 17 de set. de 2024 às 05:12, Alvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> Add backend support for injection points (Michael Paquier) [commit 1] [2]
> [3] [4]
>
I think this way would be fine.
And it would be good to have a
target="_blank"
on commit links so a new window or tab w
Em seg., 16 de set. de 2024 às 15:15, Bruce Momjian
escreveu:
> > > I changed the patch to use the section symbol "§" instead of showing
> > > the hashes. The hashes seemed too detailed. Does anyone see a better
> > > symbol to use from here
Well, I think section symbol is not a good choice f
Em sex., 13 de set. de 2024 às 13:39, Bruce Momjian
escreveu:
> I changed the patch to use the section symbol "§" instead of showing
> the hashes. The hashes seemed too detailed. Does anyone see a better
> symbol to use from here?
>
Robert and others liked commit hashes because you can do "git
Em sáb., 7 de set. de 2024 às 17:18, Tom Lane escreveu
Functions that are primarily meant to implement operators are normally not
documented separately: we feel it would bloat the
docs without adding a lot
Those two functions, elem_contained_by_range and pg_relation_is_updatable
were only example
Some days ago Tom Lane said ...
SELECT events & 4 != 0 AS can_upd, events & 8 != 0 AS can_ins, events & 16
!= 0 AS can_del FROM
pg_catalog.pg_relation_is_updatable('_pessoa'::regclass, false) t(events);
Well, I didn't find that function on DOCs and then I thought, are there
other functions which
Em sex., 6 de set. de 2024 às 23:13, jian he
escreveu:
> I didn't manually click each git commit url to test it though.
Checked, all commit links are working and matching with their
regards
Marcos
Em qui., 22 de ago. de 2024 às 14:27, Tom Lane escreveu:
>
> I'd prefer to see this implemented in the website based on our
> existing markup practices. That way it would work for quite a
> few years' worth of existing release notes, not only future ones.
>
> I understand your point, and agree w
Em seg., 19 de ago. de 2024 às 19:10, Bruce Momjian
escreveu:
> Should I work on this?
>
> Well, a process which does this automatically would be cool, but a
modified version of release notes for version 17 was done manually and
seems fine.
So, why not commit this version and later for version 18
Em seg., 12 de ago. de 2024 às 06:21, jian he
escreveu:
>
> as your wish.
>
Looks good.
regards
Marcos
Em qui., 8 de ago. de 2024 às 21:57, jian he
escreveu:
>
> please check attached.
>
I still think this way would be better
+ Sawada, John Naylor). [
+ ee1b30f12,
+ 30e144287,
+ 667e65aac,
+ 6dbb49026]
instead of this
+ Sawada, John Naylor).
+[ee1b30f12]
Em qui., 8 de ago. de 2024 às 00:11, jian he
escreveu:
>
> adding the following line to postgres.sgml saved me.
> +https://postgr.es/c/";>
>
Comma at end of line of these should be removed
[165d581f1] ,
[6dbb49026] ,
Maybe those items which have lots of commits would be strange
A space before
Em ter., 6 de ago. de 2024 às 04:30, jian he
escreveu:
>
> you can also preview the attached screenshot to see the rendered effect.
>
Loved, except that the commit id does not help too much, so I don't think
we need it.
I think a numbered link would be better.
- Change functions to use a saf
Em seg., 5 de ago. de 2024 às 07:54, jian he
escreveu:
>
> [commitId_link1, commitId_link2]: Change functions to use a safe
> search_path during maintenance operations (Jeff Davis)
>
I don't like that prefix dirtying each item.
I think having just a link after every item would be better.
Firstly
Em sex., 26 de jul. de 2024 às 13:01, Masahiko Sawada
escreveu:
>
> +1. I've been asked a lot of times how to find the associated commit
> IDs from release note items. These links would help users know the
> details of the changes, and I believe many users would like to do
> that.
Yes, this way
Em sex., 26 de jul. de 2024 às 10:11, Daniel Gustafsson
escreveu:
>
> That's likely the wrong level of detail for the overwhelming majority of
> release notes readers. I have a feeling this was discussed not too long
> ago
> but (if so) I fail to find that discussion now.
Wrong level ? Where i
Em sex., 26 de jul. de 2024 às 09:45, Daniel Gustafsson
escreveu:
>
> There is a way, but it's not exactly visible from reading the release
> notes.
>
Cool, didn't know that.
But why is that just a hidden comment and not a visible link for us ?
regards
Marcos
I'm now using version 14 and planning to update to 17 as soon as it comes
available. Then looking carefully to release notes to see exactly what I'll
get when updated I see lots of unexplained features. Just because release
notes does not explain exactly what that change does. And I don't have a
wa
Using version 16, seems strange when toast needs to be created. Tested with
domain being numeric or varchar(10) with the same results.
And If that domain is integer then no toast is created.
I think none of these tables should have a toast, right ?
postgres=# create domain mynum as numeric(15,2)
create event trigger ... on login is now available but it is not shown on
DOCs or is it in another page ?
https://www.postgresql.org/docs/devel/event-trigger-matrix.html
doesn't have it, should be there ?
regards
Marcos
Em dom., 16 de jun. de 2024 às 12:11, Pavel Stehule
escreveu:
> I don't follow this idea - when it does not make sense, then why do you
> use it? It can be a signal of some issue in your code.
>
>>
I don't use it, but sometimes it occurs, and there are lots of languages
which ignore it, so it wo
Em dom., 16 de jun. de 2024 às 11:37, Pavel Stehule
escreveu:
>
> What is the expected benefit? Generally PL/pgSQL has very strict syntax -
> and using double semicolons makes no sense.
>
> exactly, makes no sense. That is because it should be ignored, right ?
But ok, if this is a different issue
Can you remove or just ignore double ; too ?
postgres=# do $$
declare var_x integer;
begin
var_x = 99;;
delete from x where x = var_x;
end; $$;
ERROR: syntax error at or near ";"
LINE 1: do $$ declare var_x integer; begin var_x = 99;; delete from ...
Atenciosamente,
Em dom., 16 de jun. d
-
Rename SLRU columns in system view pg_stat_slru (Alvaro Herrera)
The column names accepted by pg_stat_slru_rest() are also changed.
Is pg_stat_slru_rest() correct ?
While seeing changes and new features of
https://www.postgresql.org/docs/devel/release-17.html
I see that there are too little links to other DOC pages, which would be
useful.
There are links to
"logical-replication", "sql-merge", "plpgsql", "libpq" and
"pgstatstatements"
But no one link is avail
This page has 3 items that are between parentheses, there is an explanation
why they are used this way ?
https://www.postgresql.org/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-TABLE
Each syntax element is described below in more detail.
*context_item*, *path_expression* [ AS *json_path_name
This is my first patch, so sorry if I miss something.
If I have a function which returns lots of columns and any of these columns
returns a wrong type it's not easy to see which one is that column because
it points me only to its position, not its name. So, this patch only adds
that column name, j
ua., 24 de jan. de 2024 às 14:51, Andrey Borodin
escreveu:
>
>
> > On 24 Jan 2024, at 22:00, Marcos Pegoraro wrote:
> >
> > Is enough from 1970 ?
> Per standard unix_ts_ms field is a number of milliseconds from UNIX start
> date 1970-01-01.
>
> > How about i
Is enough from 1970 ?
How about if user wants to have an UUID of his birth date ?
regards
Marcos
Em qua., 24 de jan. de 2024 às 13:54, Andrey M. Borodin <
x4...@yandex-team.ru> escreveu:
>
>
> > On 24 Jan 2024, at 20:46, Aleksander Alekseev
> wrote:
> >
> > Only the
> > fact that timestamp fro
>
> The years are converted to months and the fractional month is rounded half
>> up:
>>
>> 1.05 year = 12.6 month
>> => 1 year 0.6 month
>> => 1 year 1 month(after rounding)
>>
>> Compare that to 12.5 months to see when the rounding occurs:
>>
>> 12.5 month
Em seg., 6 de fev. de 2023 às 10:59, Erik Wienhold
escreveu:
> > On 06/02/2023 12:20 CET Marcos Pegoraro wrote:
> >
> > I was just playing with some random timestamps for a week, for a month,
> > for a year ...
> >
> > select distinct current_date+((random():
Em dom., 29 de jan. de 2023 às 09:24, Dmitry Dolgov <9erthali...@gmail.com>
escreveu:
> > On Fri, Jan 27, 2023 at 08:15:29PM +0530, vignesh C wrote:
> > The patch does not apply on top of HEAD as in [1], please post a rebased
> patch:
>
> Thanks. I think this one should do the trick.
>
There is a
>
> I agree with your idea and try to implement it and will soon attach a
> patch with a solution.
>
Additionally, if those OR constants repeat you'll see ...
If all constants are the same value, fine
explain select * from x where ((ID = 1) OR (ID = 1) OR (ID = 1));
Index Only Scan using x_id on x
Having a sup_user and a normal_user, login with sup_user
select session_user, current_user
sup_user, sup_user
set role normal_user;
select session_user, current_user
sup_user, normal_user
But then, when sup_user was running with normal_user grants an exception
occurs
select * from Some_Schema.Som
>
> I started this time around from the newest of my patches in those
> threads, but the implementation has changed considerably from what's
> there.
>
I don´t know exactly what will be the scope of this process you're working
on, but there is a gap on foreign key constraint too.
It is possible to
>
> OK, we really need a repeatable test if possible. Perhaps a pgbench run
> with lots of concurrent runs of a some very long query would do the trick.
>
OK, I can do it but ... strangely that error usually occurs at random
times, sometimes at 08:00, sometimes at 19:00, and it's busier between
10
>
> What platform is this on? Is it possible that on some platform the chunk
> size we're using is not doing an atomic write?
>
Until last year we were Ubuntu 16.04 and Postgres 11 with the latest minor
update.
This January we changed to Ubuntu 20.04 and Postgres 14, now updated to
14.4.
But the
>
>
> How are you running postgres? If the logger process runs into trouble it
> might
> write to stderr.
>
> Is there a chance your huge statements would make you run out of space?
>
> Well, I don't think it is a out of space problem, because it
doesn´t stop logging, it just splits that message.
it´s csvlog only
Atenciosamente,
Em dom., 7 de ago. de 2022 às 11:12, Tom Lane escreveu:
> Marcos Pegoraro writes:
> > I have to fix log files because its content is not properly formatted,
>
> What mechanism are you using to store the log? If syslog is involved,
> it
I have to fix log files because its content is not properly formatted, I´m
using version 14.4 but that happened when I was using version 11 too. It
happens only when that statement is huge, or because it is a long sequence
of updates in a WITH or DO statements, or because i´m updating a bytea
field
"","Key (customer_id)=(530540) already
exists.""","logical replication worker",,6675519194010520265
2022-06-28 08:18:24.160 -03,,,2009,,62b35392.7d9,88469,,2022-06-22 14:38:26
-03,,0,LOG,0,"background worker ""logical replication work
I don´t know how to create a patch, maybe someday, but for now I´m just
sending this little problem if somebody can solve it.
In a multi schema environment where several tables has same structure is a
little bit hard to know which one already has that primary key.
On log I see now on replica serv
1 - 100 of 133 matches
Mail list logo
