Andres Freund writes:
> This can't quite be right - isn't this only applying the limit if we found a
> visible tuple?
What it's restricting is the number of heap page fetches, which
might be good enough. We don't have a lot of visibility here
into how many index pages were scanned before
On Mon, Nov 21, 2022 at 12:30 PM Andres Freund wrote:
> This can't quite be right - isn't this only applying the limit if we found a
> visible tuple?
It doesn't look that way to me, but perhaps I'm just too dense to see
the problem?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Nov 21, 2022 at 9:12 AM Alvaro Herrera
wrote:
> On 2022-Nov-21, sirisha chamarthi wrote:
>
> > On Mon, Nov 21, 2022 at 8:05 AM Alvaro Herrera
> > wrote:
>
> > > Thank you. I had pushed mine for CirrusCI to test, and it failed the
> > > assert I added in slot.c:
> > >
I wrote:
> Andres Freund writes:
>> Looks like a chunk of the buildfarm doesn't like this - presumably because
>> they use force_parallel_mode = regress. Seems ok to just force that to off in
>> this test?
> Ugh ... didn't occur to me to try that. I'll take a look.
Hmm, so the problem is:
This patch version runs "continue" unconditionally (rather than
conditionally, like the previous version).
if (!index_fetch_heap(index_scan, tableslot))
continue; /* no visible tuple,
try next index entry */
Hi,
On 2022-11-21 17:06:16 +0100, Jakub Wartak wrote:
> @@ -6213,14 +6216,26 @@ get_actual_variable_endpoint(Relation heapRel,
> /* Fetch first/next tuple in specified direction */
> while ((tid = index_getnext_tid(index_scan, indexscandir)) != NULL)
> {
> +
On 2022-Nov-21, sirisha chamarthi wrote:
> On Mon, Nov 21, 2022 at 8:05 AM Alvaro Herrera
> wrote:
> > Thank you. I had pushed mine for CirrusCI to test, and it failed the
> > assert I added in slot.c:
> > https://cirrus-ci.com/build/4786354503548928
> > Not yet sure why, looking into it.
>
>
Robert Haas writes:
> The reason that I pushed back -- not as successfully as I would have
> liked -- on the changes to pg_stop_backup / pg_start_backup is that I
> know there are people using the old method successfully, and it's not
> just a 1:1 substitution. Here I don't, and it is. I'm
On Sun, Nov 20, 2022 at 9:20 PM Kyotaro Horiguchi
wrote:
> I prefer Robert's approach as it is more robust for future changes and
> simple. I prefer to avoid this kind of piggy-backing and it doesn't
> seem to be needed in this case. XLogShutdownWalRcv() looks like a
> similar case to me and
I wrote:
> Andres Freund writes:
>> I suspect that having a GUC would be a good idea. I needed something similar
>> recently, debugging an occasional hang in the AIO patchset. I first tried
>> something like your #define approach and it did cause a problematic flood of
>> core files.
> Yeah, the
On Mon, Nov 21, 2022 at 8:05 AM Alvaro Herrera
wrote:
> On 2022-Nov-21, sirisha chamarthi wrote:
>
> > > > I am a fan of stricter, all-assumption-covering conditions. In case
> we
> > > > don't want to check restart_lsn, an Assert might be useful to
> validate
> > > > our assumption.
> > >
> > >
On Mon, Nov 21, 2022 at 3:40 AM Laurenz Albe wrote:
> We have had a deprecation period? I looked at the documentation, but found
> no mention of a deprecation. How hard can it be to leave the GUC and only
> poll for the existence of the file if it is set?
>
> I personally don't need the GUC,
Hi,
Draft version of the patch attached (it is based on Simon's)
I would be happier if we could make that #define into GUC (just in
case), although I do understand the effort to reduce the number of
various knobs (as their high count causes their own complexity).
-Jakub Wartak.
On Mon, Nov 21,
On 2022-Nov-21, sirisha chamarthi wrote:
> > > I am a fan of stricter, all-assumption-covering conditions. In case we
> > > don't want to check restart_lsn, an Assert might be useful to validate
> > > our assumption.
> >
> > Agreed. I'll throw in an assert.
>
> Changed this in the patch to
On Sat, Nov 19, 2022 at 1:00 AM Michael Paquier wrote:
> On Fri, Nov 18, 2022 at 04:19:15PM -0500, Robert Haas wrote:
> > Fixed that, and the other mistake Álvaro spotted, and also bumped
> > catversion because I forgot that earlier.
>
> I was looking at this code yesterday, to see today that
On Mon, Nov 21, 2022 at 10:32 AM Tom Lane wrote:
> Robert Haas writes:
> > Is there any reason to tie this into page costs? I'd be more inclined
> > to just make it a hard limit on the number of pages. I think that
> > would be more predictable and less prone to surprising (bad) behavior.
>
>
On Sun, Nov 20, 2022 at 6:10 PM Andres Freund wrote:
> I was wondering about that too - but decided against it because it would only
> show a single wait event. And wouldn't really describe spinlocks as a whole,
> just the "extreme" delays. If we wanted to report the spin waits more
> granular,
Robert Haas writes:
> Is there any reason to tie this into page costs? I'd be more inclined
> to just make it a hard limit on the number of pages. I think that
> would be more predictable and less prone to surprising (bad) behavior.
Agreed, a simple limit of N pages fetched seems appropriate.
>
On 11/20/22 2:56 PM, Andres Freund wrote:
Hi,
On 2022-11-09 17:03:13 -0800, Andres Freund wrote:
On 2022-11-09 09:38:08 -0800, Andres Freund wrote:
I'm on a hike, without any connectivity, Thu afternoon - Sun. I think it's OK
to push it to HEAD if I get it done in the next few hours. Bigger
On Mon, 21 Nov 2022 at 15:23, Robert Haas wrote:
>
> On Mon, Nov 21, 2022 at 10:14 AM Simon Riggs
> wrote:
> > > > What we need is a solution that avoids reading an unbounded number of
> > > > tuples under any circumstances. I previously suggested using
> > > > SnapshotAny here, but Tom didn't
On Mon, Nov 21, 2022 at 10:14 AM Simon Riggs
wrote:
> > > What we need is a solution that avoids reading an unbounded number of
> > > tuples under any circumstances. I previously suggested using
> > > SnapshotAny here, but Tom didn't like that. I'm not sure if there are
> > > safety issues there
Hi everyone,
I have made a patch that introduces support for libpq binary protocol
in postgres_fdw. The idea is simple, when a user knows that the foreign
server is binary compatible with the local and his workload could
somehow benefit from using binary protocol, it can be switched on for a
Thanks Alvaro, Ashutosh for your comments.
On Mon, Nov 21, 2022 at 6:20 AM Alvaro Herrera
wrote:
> On 2022-Nov-21, Ashutosh Bapat wrote:
>
> > Maybe. In that case pg_get_replication_slots() should be changed. We
> > should use the same criteria to decide whether a slot is invalidated
> > or
On Mon, 21 Nov 2022 at 15:01, Tom Lane wrote:
>
> > What we need is a solution that avoids reading an unbounded number of
> > tuples under any circumstances. I previously suggested using
> > SnapshotAny here, but Tom didn't like that. I'm not sure if there are
> > safety issues there or if Tom
On Fri, 18 Nov 2022 at 11:54, Simon Riggs wrote:
>
> On Thu, 17 Nov 2022 at 20:00, Justin Pryzby wrote:
> >
> > On Wed, Nov 16, 2022 at 05:14:07PM -0500, Greg Stark wrote:
> > > I think this requesting autovacuum worker should be a distinct
> > > command. Or at least an explicit option to
Robert Haas writes:
> I don't think this is safe at all. Wait events can only bracket
> individual operations, like the reads of the individual index blocks,
> not report on which phase of a larger operation is in progress. If we
> try to make them do the latter, we will have a hot mess on our
On Mon, Nov 21, 2022 at 7:22 AM Alvaro Herrera wrote:
> On 2022-Nov-21, Jakub Wartak wrote:
> > b) I was wondering about creating a new wait class "Planner" with the
> > event "ReadingMinMaxIndex" (or similar). The obvious drawback is the
> > naming/categorization as wait events are ... well.. as
Justin Pryzby писал 2022-11-21 06:00:
I finally found time to digest and integrate your changes into my local
branch. This fixes the three issues you reported: FORCE_RELEASE, issue
with INVALID partitions issue (for which I adapted your patch into an
earlier patch in my series), and progress
On 2022-Nov-21, Ashutosh Bapat wrote:
> Maybe. In that case pg_get_replication_slots() should be changed. We
> should use the same criteria to decide whether a slot is invalidated
> or not at all the places.
Right.
> I am a fan of stricter, all-assumption-covering conditions. In case we
> don't
> On 10 Aug 2022, at 10:28, Daniel Gustafsson wrote:
>
>> On 10 Aug 2022, at 08:12, Kyotaro Horiguchi wrote:
>>
>> (I suppose this is a pg15 issue)
>>
>> createuser --help shows the following help text.
>>
>>> --bypassrls role can bypass row-level security (RLS) policy
>>>
Thanks for references, Justin!
Couple comments about these references.
1) "Make unlogged table resets detectable".
https://www.postgresql.org/message-id/flat/62750df5b126e1d8ee039a79ef3cc64ac3d47cd5.camel%40j-davis.com
This conversation is about specific problem (unlogged table repairing).
Andres Freund writes:
> But either way, it seems nicer to output the # inside a helper function?
Note that the helper function should inject '# ' at the start of every
line in the message, not just the first line. It might also be worth
having two separate functions: one that prints to stdout,
On Fri, 18 Nov 2022 at 18:26, Tom Lane wrote:
>
> Robert Haas writes:
> > On Fri, Nov 18, 2022 at 7:04 AM Simon Riggs
> > wrote:
> >> So if consistency is also a strong requirement, then maybe we should
> >> make that new command the default, i.e. make VACUUM always just a
> >> request to
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I've looked at this patch and don't see any problems with it. It is
Hi,
On 11/21/22 12:19 AM, Andres Freund wrote:
Hi,
On 2022-11-18 12:18:38 +0100, Drouvot, Bertrand wrote:
On 11/16/22 9:12 PM, Andres Freund wrote:
This still leaves a fair bit of boilerplate. ISTM that the function body
really should just be a single line.
Might even be worth defining the
> Pushed.
>
> --
> With Regards,
> Amit Kapila.
>
>
Hi!
While working on 64–bit XID's patch set, I stumble into problems with
contrib/test_decoding/catalog_change_snapshot test [0].
AFAICS, the problem is not related to the 64–bit XID's patch set and the
problem is in InitialRunningXacts array,
Hi!
PREAMBLE
For a last couple of months, I stumbled into a problem while running tests
on ARM (Debain, aarch64) and some more wired platforms
for my 64–bit XIDs patch set. Test contrib/test_decoding
(catalog_change_snapshot) rarely failed with the next message:
TRAP:
On Mon, Nov 21, 2022 at 9:03 PM Amit Langote wrote:
> On Thu, Nov 10, 2022 at 8:58 PM Alvaro Herrera
> wrote:
> > Why do callers of add_rte_to_flat_rtable() have to modify the rte's
> > perminfoindex themselves, instead of having the function do it for them?
> > That looks strange. But also
On Monday, November 21, 2022 2:26 PM Peter Smith wrote:
> On Fri, Nov 18, 2022 at 6:03 PM Peter Smith
> wrote:
> >
> > Here are some review comments for v47-0001
> >
> > (This review is a WIP - I will post more comments for this patch next
> > week)
> >
>
> Here are the rest of my comments for
On Friday, November 18, 2022 8:36 AM Masahiko Sawada
wrote:
>
> Here are review comments on v47-0001 and v47-0002 patches:
Thanks for the comments!
> When the parallel apply worker exited, I got the following server log.
> I think this log is not appropriate since the worker was not
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
i've tested and verified the documentation.
On Thu, 17 Nov 2022 at 22:01, Cary Huang wrote:
>
> Patch: Global Unique Index
Let me start by expressing severe doubt on the usefulness of such a
feature, but also salute your efforts to contribute.
> In other words, a global unique index and a regular partitioned index are
> essentially the
On Mon, Nov 21, 2022 at 5:39 PM Alvaro Herrera wrote:
>
> On 2022-Nov-21, Ashutosh Bapat wrote:
>
> > I think the condition should be
> >
> > if (!XLogRecPtrIsInvalid(invalidated_at_lsn)) LSN and XID are
> > different data types.
>
> Yeah, this bit is wrong. I agree with your suggestion to just
On 2022-Nov-21, Jakub Wartak wrote:
> b) I was wondering about creating a new wait class "Planner" with the
> event "ReadingMinMaxIndex" (or similar). The obvious drawback is the
> naming/categorization as wait events are ... well.. as the name "WAIT"
> implies, while those btree lookups could
On 2022-Nov-21, Ashutosh Bapat wrote:
> I think the condition should be
>
> if (!XLogRecPtrIsInvalid(invalidated_at_lsn)) LSN and XID are
> different data types.
Yeah, this bit is wrong. I agree with your suggestion to just keep a
boolean flag, as we don't need more than that.
> and to be
Hi hackers,
the case of planner's
src/backend/utils/adt/selfuncs.c:get_actual_variable_endpoint()
spending literally seconds seems to be well known fact across hackers
(in the extreme wild case it can be over 1+ hour on VLDBs). For those
unfamiliar it is planner estimation that tries to read real
On Mon, 21 Nov 2022 at 08:40, Laurenz Albe wrote:
>
> On Mon, 2022-11-21 at 07:36 +, Simon Riggs wrote:
> > On Mon, 21 Nov 2022 at 05:07, Laurenz Albe wrote:
> > >
> > > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > > I'll wait 24 hours before committing, to
> > > > provide a
On Sat, Nov 19, 2022 at 6:47 PM Stavros Koureas
wrote:
>
> Hi all,
>
> Working with PostgreSQL Logical Replication is just great! It helps a lot
> doing real time replication for analytical purposes without using any other
> 3d party service. Although all these years working as product
On Mon, 21 Nov 2022 at 12:12, Matthias van de Meent
wrote:
>
> Hi,
>
> I noticed that the comment on/beneath rs_numblocks in HeapScanDescData
> is duplicated above rs_strategy. I don't know if there should have
> been a different comment above rs_strategy, but the current one is
> definitely out
Hi Sirisha,
Thanks for identifying the bug and the solution. Some review comments inlined.
On Mon, Nov 21, 2022 at 2:49 PM Alvaro Herrera wrote:
>
> On 2022-Nov-20, sirisha chamarthi wrote:
>
> > Hi Hackers,
> >
> > forking this thread from the discussion [1] as suggested by Amit.
> >
> >
Hi hackers,
> > I have a very serious concern about the current patch set. as someone who
> > has faced transaction id wraparound in the past.
>
> [...]
>
> I had a similar stance when I started working on this patch. Of
> course, it seemed horrible just to postpone the consequences of
>
Hi,
I noticed that the comment on/beneath rs_numblocks in HeapScanDescData
is duplicated above rs_strategy. I don't know if there should have
been a different comment above rs_strategy, but the current one is
definitely out of place, so I propose to remove it as per attached.
The comment was
See also prior discussions:
https://www.postgresql.org/message-id/flat/62750df5b126e1d8ee039a79ef3cc64ac3d47cd5.camel%40j-davis.com
https://www.postgresql.org/message-id/flat/20180228214311.jclah37cwh572t2c%40alap3.anarazel.de
--
Justin
Agreed on not using "unaborted", per previous discussion.
On 2022-Nov-21, Laurenz Albe wrote:
> Perhaps we should also avoid the term "transaction block". Even without
> speaking
> of a "block", way too many people confuse PL/pgSQL's BEGIN ... END blocks
> with transactions. On the other
On Fri, 2022-11-18 at 14:28 -0500, Bruce Momjian wrote:
> New patch attached.
Thanks.
> --- a/doc/src/sgml/ref/release_savepoint.sgml
> +++ b/doc/src/sgml/ref/release_savepoint.sgml
> + RELEASE SAVEPOINT releases the named savepoint and
> + all active savepoints that were created after the
> I have a very serious concern about the current patch set. as someone who has
> faced transaction id wraparound in the past.
>
> I can start by saying I think it would be helpful (if the other issues are
> approached reasonably) to have 64-bit xids, but there is an important piece
> of
On Sun, Nov 20, 2022 at 03:15:34PM -0800, Ted Yu wrote:
> + * timestamp. These require a specific handling with their typmod is given
> + * by the function caller through their SQL keyword.
>
> typo: typmod is given -> typmod given
>
> Other than the above, code looks good to me.
Thanks for
On Mon, Nov 21, 2022 at 3:43 PM Masahiko Sawada
wrote:
>
> On Mon, Nov 21, 2022 at 4:20 PM John Naylor
> wrote:
> > Assuming the smallest node is fixed size (i.e. fanout/capacity member
not part of the common set, so only part of variable-sized nodes), 3 has a
nice property: no wasted padding
On 21.11.22 00:57, Heikki Linnakangas wrote:
On 19/11/2022 13:00, Peter Eisentraut wrote:
On 18.10.21 14:15, Heikki Linnakangas wrote:
On 05/10/2021 20:24, John Naylor wrote:
I've had a chance to review and test out the v5 patches.
Thanks! I fixed the stray reference to PostgreSQL 14 that
On 2022-Nov-20, sirisha chamarthi wrote:
> Hi Hackers,
>
> forking this thread from the discussion [1] as suggested by Amit.
>
> Catalog_xmin is not advanced when a logical slot is invalidated (lost)
> until the invalidated slot is dropped. This patch ignores invalidated slots
> while computing
On Mon, Nov 21, 2022 at 4:20 PM John Naylor
wrote:
>
>
> On Fri, Nov 18, 2022 at 2:48 PM I wrote:
> > One issue with this patch: The "fanout" member is a uint8, so it can't hold
> > 256 for the largest node kind. That's not an issue in practice, since we
> > never need to grow it, and we only
Hi, hackers!
It is important for customer support to know what system operations
(pg_resetwal, pg_rewind, pg_upgrade, ...) have been executed on the
database. A variant of implementation of the log for system operations
(operation log) is attached to this email.
Introduction.
-
On Mon, 2022-11-21 at 07:36 +, Simon Riggs wrote:
> On Mon, 21 Nov 2022 at 05:07, Laurenz Albe wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chance for anyone who wants to complain about dropping
> >
On Mon, 2022-11-21 at 11:42 +0530, Bharath Rupireddy wrote:
> On Mon, Nov 21, 2022 at 10:37 AM Laurenz Albe
> wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chance for anyone who wants to complain about
Hi Hackers,
At present, calling pg_stat_reset* functions requires super user access
unless explicitly grant execute permission on those. In this thread, I am
proposing to grant execute on them to users with pg_monitor role
permissions. This comes handy to the monitoring users (part of pg_monitor
101 - 165 of 165 matches
Mail list logo
