Hi,
The documentation for PostgreSQL 17 says the following :
"query in a repeatable read transaction sees a snapshot as of the
start of the first non-transaction-control statement in the
transaction, not as of the start of the current statement within the
transaction"
But I noticed this behavior (
On Thu, 19 Dec 2024 at 04:58, Peter Smith wrote:
>
> Hi Vignesh,
>
> Here are some review comments for the patch v20241211-0003.
>
> ~~~
>
> 4.
> +/*
> + * Common code to fetch the up-to-date sync state info into the static lists.
> + *
> + * Returns true if subscription has 1 or more tables, else
>
>
> Comments are not quite accurate, but I'll look at cleaning them up and
> adding them.
>
Much appreciated. Also, I don't think we need all of the comments, but I
figured it was easier for me to comment at every possible good place, and
let you pick your favorites.
On Mon, 23 Dec 2024 at 18:53, Tom Lane wrote:
>
> David Rowley writes:
> > Another reason I deleted that is that
> > since the file contains helper functions, I didn't want to write a new
> > comment based on what functions are there now as it may put someone
> > else off from adding new ones if
On Sun, Dec 22, 2024 at 11:15:31PM -0500, Tom Lane wrote:
> WFM
Okay, done this way then, thanks.
--
Michael
signature.asc
Description: PGP signature
"=?utf-8?B?56ug5pmo5pumQOaYk+aZr+enkeaKgA==?="
writes:
> And after a while, a system error occurred and unfortunately, just
> caused clog file corrupted.
> So we need to restore the database from backup just because of the tiny clog
> file corrupted.
I'm not seeing a large difference between
Hi Tomas
This is a great feature.
+ /*
+ * Define (or redefine) custom GUC variables.
+ */
+ DefineCustomIntVariable("stats_history.size",
+ "Sets the amount of memory available for past events.",
+ NULL,
+ &statsHistorySizeMB,
+ 1,
+ 1,
+ 128,
+ PGC_POSTMASTER,
+ GUC_UNIT_MB,
+ NULL,
+ NULL,
But think about such a scenario, after INSERT some tuples, and COMMIT also
succeed.
And after a while, a system error occurred and unfortunately, just caused
clog file corrupted.
So we need to restore the database from backup just because of the tiny clog
file corrupted.
Is there any chance t
Dear Hou,
Thanks for updating the patch. Few comments:
01. worker.c
```
+/*
+ * The minimum (100ms) and maximum (3 minutes) intervals for advancing
+ * non-removable transaction IDs.
+ */
+#define MIN_XID_ADVANCEMENT_INTERVAL 100
+#define MAX_XID_ADVANCEMENT_INTERVAL 18L
```
Since the max_i
David Rowley writes:
> On Mon, 23 Dec 2024 at 16:37, Tom Lane wrote:
>> Also, rather than simply remove
>> define.c's entire header comment, maybe we should write something
>> relevant about what it does? Good catches otherwise.
> I didn't have any inspiration on what to write other than what's
Yes, i think you're right. The tuple will be set to HEAP_XMIN_COMMITTED
when doing the visibility checking, but don't you think it's a little weird? Or
may cause some confusion?
Thanks,
Jet
Junwang Zhao
On Mon, 23 Dec 2024 at 16:37, Tom Lane wrote:
>
> David Rowley writes:
> > + * The "DefineAggregate" routine take the parse tree and pick out the
> > + * appropriate arguments/flags, passing the results to
> > + * "AggregateCreate" routine (src src/backend/catalog) that do the
> > ac
> The saved hooks are not here to readjust the stack based on a reload,
> just to make sure that the existing paths loaded are all taken. I
> would just remove the "in case of unload" part for the last three, and
> "unload" for the first one. Thoughts?
LGTM.
--
Regards,
ChangAo Chen
On Mon, Dec 23, 2024 at 09:22:06AM +0530, mahendrakar s wrote:
> Is there any psql utility function that returns the last removed wal
> segment file?
> I see there is a method: XLogGetLastRemovedSegno in xlog.c.
> Would be happy to add a new psql function around it (similar to:
> pg_walfile_name, p
On Thu, Dec 12, 2024 at 03:40:32PM +0800, jian he wrote:
> remove pg_type typndims column patch attached.
FWIW, I have been paying more attention to applications that may use
this attribute and bumped into quite a few cases that use quals based
on (t.typndims > 0 AND t.typbasetype > 0) to check th
Michael Paquier writes:
> While on it, I think that we should adjust all these ones too:
> contrib/sepgsql/hooks.c: * Module load/unload callback
> contrib/auto_explain/auto_explain.c:/* Saved hook values in case of
> unload */
> contrib/passwordcheck/passwordcheck.c:/* Saved hook value in case of
Hi there,
I notice a little strange things of clog behaviours.
When I create a test table, say, a_test, the table only contains a INT type
column.
postgres=# CREATE TABLE a_test (n INT);
CREATE TABLE
and then insert one tuple:
postgres=# INSERT INTO a_test VALUES (1);
INSERT 0 1
An
On Sun, Dec 22, 2024 at 10:50:47PM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> Right. This comment is misleading.
>
> I think it was once correct, decades ago. Obviously we missed
> fixing it when we ripped out the unload functionality.
This was recent enough, and easy to miss.
>> -
On Fri, Dec 20, 2024 at 11:23:30AM -0800, Masahiko Sawada wrote:
> Thanks. Please proceed with this fix as you've already fixed the HEAD part.
Thanks. It took me a bit of time to check that across all five stable
branches, including sysbench and the SQL case, and I think that's OK,
so done (added
On Wed, Dec 18, 2024 at 12:22 PM Tom Lane wrote:
> Michel Pelletier writes:
> > My bad, sorry for the long confusing email, I figured out that I was
> > calling the wrong macro when getting my matrix datum and inadvertently
> > expanding RO pointers as well, I've fixed that issue, and everything
Hi Hackers,
Is there any psql utility function that returns the last removed wal
segment file?
I see there is a method: XLogGetLastRemovedSegno in xlog.c.
Would be happy to add a new psql function around it (similar to:
pg_walfile_name, pg_last_wal_replay_lsn, etc other utility functions
we have).
Michael Paquier writes:
> On Mon, Dec 23, 2024 at 10:58:49AM +0800, cca5507 wrote:
> * This function loads a shlib file without looking up any particular
> * function in it. If the same shlib has previously been loaded,
> - * unload and reload it.
> + * we don't load it again.
> Right. This
On Mon, Dec 23, 2024 at 10:58:49AM +0800, cca5507 wrote:
> /* If the same shlib has previously been loaded, unload and reload it. */
>
> But we currently don't support to unload a shlib.
* This function loads a shlib file without looking up any particular
* function in it. If the same shlib
David Rowley writes:
> + * The "DefineAggregate" routine take the parse tree and pick out the
> + * appropriate arguments/flags, passing the results to
> + * "AggregateCreate" routine (src src/backend/catalog) that do the actual
> + * catalog-munging. These routines also verify pe
Hi,
The comment in load_file():
/* If the same shlib has previously been loaded, unload and reload it. */
But we currently don't support to unload a shlib.
Here is a small patch to fix it.
--
Regards,
ChangAo Chen
0001-Fix-a-wrong-comment-in-load_file.patch
Description: Binary data
On Sat, 21 Dec 2024 at 17:06, jian he wrote:
> * Note the definitions of the relevant flags in src/include/utility/tcop.h.
> */
> static int
> ClassifyUtilityCommandAsReadOnly(Node *parsetree)
>
> Is the comment wrong?
>
> it should be
> " * Note the definitions of the relevant flags in src/incl
On Sun, Dec 22, 2024 at 08:00:00AM +0200, Alexander Lakhin wrote:
> and batta:
> sid | gcc recent | aarch64 | michael [ a t ] paquier.xyz
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=batta&dt=2024-12-16%2008%3A05%3A04
I suspect that this one has been caused by me, as I have logged int
On 12/19/24 9:57 PM, Peter Eisentraut wrote:
Here is an updated patch set on top of what has been committed so far,
with all the issues you pointed out addressed.
Other than the discussion of how old versions of flex we should support
I think this set of patches is ready to be committed. I loo
> On Dec 20, 2024, at 4:07 PM, Tom Lane wrote:
>
> Hmph. After thinking about it a bit I have a different idea
> (and I see David has yet a third one). So maybe this is more
> contentious than it seems. But at any rate, I have two
> fundamental thoughts:
>
> * "Listen to all but X" seems lik
On Sun, Dec 22, 2024 at 9:45 AM Marcos Pegoraro wrote:
> 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 expla
[ this thread seems to have stalled out, but we need to resolve it ]
Robert Haas writes:
>>> What I'm unhappy about is not being able to tell the difference
>>> between a name that was invented by or at least meaningful to the user
>>> and one that isn't.
>> You can already tell that, by looking
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
On Sun, Dec 22, 2024 at 7:27 AM jian he wrote:
> On Wed, Dec 11, 2024 at 7:00 AM David G. Johnston
> wrote:
> >
> > v5 Attached, v5-0001 is just v4-0001 rebased; v5-0002 is the rework over
> v4-0001. There is no formatting-only patch this round.
> >
> > Wiki tracker:
> https://wiki.postgresql.o
33 matches
Mail list logo
