Hi,
As an author of plpgsql_check, I permanently have to try to solve genetic
problems with the necessity of external information for successful static
validation.
create or replace function foo(tablename text)
returns void as $$
declare r record;
begin
execute format('select * from %I',
HI Thomas,
On Tue, Jul 20, 2021 at 10:40 PM Thomas Munro wrote:
> > Slightly tangential: we should add a comment to PGPROC.pgprocno, for more
> > immediate understandability:
> >
> > + int pgprocno; /* index of this PGPROC in ProcGlobal->allProcs */
>
> I wonder why we need this member anyway,
On Fri, Jul 23, 2021 at 6:18 PM Tom Lane wrote:
> For btree indexes, you need a compatible notion of ordering, not only
> equality. That's really what's breaking my hypothetical case of a uint
> type. But as long as you implement operators that behave in a consistent
> fashion, whether they
On Fri, Jul 23, 2021 at 05:47:18PM -0700, Peter Geoghegan wrote:
> > I could perhaps see corruption happening if pg_control's oldest xid
> > value was closer to the current xid value than it should be, but I can't
> > see how having it 2-billion away could cause harm, unless perhaps
> > pg_upgrade
On Fri, Jul 23, 2021 at 5:08 PM Bruce Momjian wrote:
> However, I am now stuck on the commit message text, and I think this is
> the point Peter Geoghegan was trying to make earlier --- while we know
> that preserving the oldest xid in pg_control is the right thing to do,
> and that setting it to
On Thu, Jul 8, 2021 at 09:51:47AM -0400, Bruce Momjian wrote:
> On Thu, Jul 8, 2021 at 08:11:14AM -0500, Justin Pryzby wrote:
> > Also, the pg_upgrade status message still seems to be misplaced:
> >
> > In 20210706190612.gm22...@telsasoft.com, Justin Pryzby wrote:
> > > I re-arranged the
Robert Haas writes:
> On Fri, Jul 23, 2021 at 5:47 PM Tom Lane wrote:
>> Hmm. Note that what this is checking for is same operator *class* not
>> same operator family (if it were doing the latter, Peter's case would
>> already work). I think it has to do that. Extending my previous
>> thought
Andres Freund writes:
> On 2021-07-23 17:18:37 -0400, Tom Lane wrote:
>> Should we back-patch this, or just do it in HEAD? Maybe HEAD+v14?
> I'm ok with all, with a preference for HEAD+v14, followed by HEAD, and
> all branches.
After a bit more thought, HEAD+v14 is also my preference. I'm not
On Fri, Jul 23, 2021 at 5:47 PM Tom Lane wrote:
> > You seemed to think my previous comments about comparing opfamilies
> > were hypothetical but I think we actually already have the
> > optimization Peter wants, and it just doesn't apply in this case for
> > lack of hacks.
>
> Hmm. Note that
Hi,
On 2021-07-23 17:18:37 -0400, Tom Lane wrote:
> I'm not prepared to go that far just yet; but certainly we can stop
> expending configure cycles on the case.
>
> Should we back-patch this, or just do it in HEAD? Maybe HEAD+v14?
I'm ok with all, with a preference for HEAD+v14, followed by
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi
I have applied and run your patch, which works fine in
Robert Haas writes:
> On Fri, Jul 23, 2021 at 2:07 PM Tom Lane wrote:
>> However, for the reasons I explained before, there are no general-purpose
>> cases where we can skip an index build on a type-changed column, so
>> there is no place to insert a similar hack for the timestamp[tz] case.
>
On 5/6/21, 1:01 PM, "Andres Freund" wrote:
> If we leave history files and gaps in the .ready sequence aside for a
> second, we really only need an LSN or segment number describing the
> current "archive position". Then we can iterate over the segments
> between the "archive position" and the
> On Jul 23, 2021, at 2:04 PM, Mark Dilger wrote:
>
> If the GUC merely converts the event trigger into an error, then you have the
> problem that the customer can create event triggers which the service
> provider will need to disable (because they cause the service providers
> legitimate
Andres Freund writes:
> On 2021-07-23 13:42:41 -0400, Tom Lane wrote:
>> TBH, I wonder why we don't just nuke thread_test.c altogether.
> +1. And before long it might be time to remove support for systems
> without threads...
I'm not prepared to go that far just yet; but certainly we can stop
Per the discussion at [1], users on Windows are seeing nasty performance
losses in v13/v14 (compared to prior releases) for hash aggregations that
required somewhat more than 2GB in the prior releases. That's because
they spill to disk where they did not before. The easy answer of "raise
> On Jul 23, 2021, at 1:57 PM, Mark Dilger wrote:
>
> What's the point in having these as separate roles if they can circumvent
> each other's authority?
That was probably too brief a reply, so let me try again. If the GUC
circumvents the event trigger, then my answer above stands. If
> On Jul 23, 2021, at 1:54 PM, Robert Haas wrote:
>
> Yeah, but you're inventing a system for allowing the restriction on a
> GUC to be something other than is-superuser in the very patch we're
> talking about. So it could be something like is-database-security.
> Therefore I don't grok the
On Fri, Jul 23, 2021 at 12:11 PM Mark Dilger
wrote:
> A superuser-only GUC for this is also a bit too heavy handed.
Yeah, but you're inventing a system for allowing the restriction on a
GUC to be something other than is-superuser in the very patch we're
talking about. So it could be something
On Fri, Jul 23, 2021 at 2:07 PM Tom Lane wrote:
> Yes, I'm very well aware of that optimization. While it's certainly
> a hack, it fits within a design that isn't a hack, ie that there are
> common, well-defined cases where we can skip the table rewrite.
> However, for the reasons I explained
On Fri, Jul 23, 2021 at 10:55:11AM -0700, Bryn Llewellyn wrote:
> SELECT
> '1.2345 months 1.2345 days 1.2345 seconds'::interval =
> '1 month 1 day 1 second'::interval*1.2345;
>
> In 13.3, the result is TRUE. (I know that this doesn’t guarantee that the
> internal representations of the two
On Thu, Jun 17, 2021 at 1:23 AM Amul Sul wrote:
> Attached is rebase for the latest master head. Also, I added one more
> refactoring code that deduplicates the code setting database state in the
> control file. The same code set the database state is also needed for this
> feature.
I started
Hi,
On 2021-07-23 13:42:41 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > ... that said, I wonder why would we do this in the thread_test program
> > rather than in configure itself. Wouldn't it make more sense for the
> > configure test to be skipped altogether (marking the result as
> >
Em sex., 23 de jul. de 2021 às 11:32, Tom Lane escreveu:
> Ranier Vilela writes:
> > This is a minor leak, oversight in
> >
> https://github.com/postgres/postgres/commit/4526951d564a7eed512b4a0ac3b5893e0a115690#diff-e399f5c029192320f310a79f18c20fb18c8e916fee993237f6f82f05dad851c5
>
> I don't
Peter Volk writes:
> thanks for the reply, I do understand that if a rewrite of the table
> needs to be avoided the binary image needs to be the same. Since PG 12
> there is an optimisation to avoid a rewrite of timestamp columns if
> they are converted to timestamp with tz and the target tz
Hi Tomas,
On 12.07.2021 16:04, Tomas Vondra wrote:
On 7/12/21 1:10 PM, Egor Rogov wrote:
Hi,
thanks for the review and corrections.
On 11.07.2021 21:54, Soumyadeep Chakraborty wrote:
Hello,
This should have been added with [1].
Excerpt from the documentation:
"pg_stats is also designed to
On Fri, Jul 23, 2021 at 01:42:41PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > ... that said, I wonder why would we do this in the thread_test program
> > rather than in configure itself. Wouldn't it make more sense for the
> > configure test to be skipped altogether (marking the result
> On 23-Jul-2021, at 08:05, Bruce Momjian wrote:
>
> On Thu, Jul 22, 2021 at 03:17:52PM -0700, Zhihong Yu wrote:
>> On Thu, Jul 22, 2021 at 2:59 PM Zhihong Yu wrote:
>>Hi,
>>
>>- tm->tm_mon += (fval * MONTHS_PER_YEAR);
>>+ tm->tm_mon += rint(fval
On 7/23/21, 4:33 AM, "Andrey Borodin" wrote:
> Thanks for you interest in the topic. I think in the thread [0] we almost
> agreed on general design.
> The only left question is that we want to threat pg_ctl stop and kill SIGTERM
> differently to pg_terminate_backend().
I didn't get the idea
On 7/23/21, 4:23 AM, "Laurenz Albe" wrote:
> But that would mean that changes ostensibly rolled back (because the
> cancel request succeeded) will later turn out to be committed after all,
> just like it is now (only later). Where is the advantage?
The advantage is that I can cancel waits for
On 7/23/21, 3:58 AM, "Amit Kapila" wrote:
> On Fri, Jul 23, 2021 at 2:48 AM Bossart, Nathan wrote:
>> Instead of blocking query cancellations and backend terminations, I
>> think we should allow them to proceed, but we should keep the
>> transactions marked in-progress so they do not yet become
> On Jul 23, 2021, at 9:20 AM, Stephen Frost wrote:
>
> These considerations were addressed with row_security by allowing the
> GUC to be set by anyone, but throwing an ERROR if RLS would have been
> required by the query instead of just allowing it. I don't see any
> obvious reason why that
Alvaro Herrera writes:
> ... that said, I wonder why would we do this in the thread_test program
> rather than in configure itself. Wouldn't it make more sense for the
> configure test to be skipped altogether (marking the result as
> thread-safe) when running under thread sanitizer, if there's
This is a reply to an old thread with the same name:
https://www.postgresql.org/message-id/1513971675.5870501.1439797066345.javamail.ya...@mail.yahoo.com
I was not able to do a proper reply since I cannot download the raw
message: https://postgrespro.com/list/thread-id/2483942
Anyway, the problem
Hi
When reading PG DOC, found some example code not correct as it said.
https://www.postgresql.org/docs/devel/regress-run.html
Here's a tiny fix in regress.sgml.
-make check PGOPTIONS="-c log_checkpoints=on -c work_mem=50MB"
+make check PGOPTIONS="-c geqo=off -c work_mem=50MB"
Hi Tom,
thanks for the reply, I do understand that if a rewrite of the table
needs to be avoided the binary image needs to be the same. Since PG 12
there is an optimisation to avoid a rewrite of timestamp columns if
they are converted to timestamp with tz and the target tz offset is 0
I am
On 2021-Jul-23, Alvaro Herrera wrote:
> On 2021-Jul-23, Mikhail Matrosov wrote:
>
> > I am not sure what is the proper fix for the issue, but I at least suggest
> > to disable this test when building with thread sanitizer:
> >
On 2021-Jul-23, Mikhail Matrosov wrote:
> I am not sure what is the proper fix for the issue, but I at least suggest
> to disable this test when building with thread sanitizer:
>
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jul 23, 2021, at 6:22 AM, Robert Haas wrote:
> > And I think that's a good illustration of why it's a bad idea to
> > categorize things according to whether or not they have a certain
> > consequence.
>
> Well, one very big
> On Jul 23, 2021, at 6:22 AM, Robert Haas wrote:
>
> And I think that's a good illustration of why it's a bad idea to
> categorize things according to whether or not they have a certain
> consequence.
Well, one very big reason for wanting to break superuser into separate roles is
to make
On 7/22/21, 6:31 PM, "Justin Pryzby" wrote:
> On Thu, Jul 22, 2021 at 10:32:18PM +, Bossart, Nathan wrote:
>> IMO the note about the option being helpful after using the --no-sync
>> option would fit better in the docs, but I'm struggling to think of a
>> use case for using --no-sync and then
On Fri, Jul 23, 2021 at 3:23 AM Peter Smith wrote:
>
> I think the patch maybe is not quite correct for all the flags.
>
> For example,
>
> @@ -7607,44 +7615,44 @@ are available since protocol version 3.
>
> Int8
>
> -Flags; currently unused (must be 0).
> +
Dean Rasheed writes:
> All your other suggestions make sense too. Attached is a new version.
OK, I've now studied this more closely, and have some additional
nitpicks:
* I felt the way you did the documentation was confusing. It seems
better to explain the normal case first, and then describe
Hi
čt 22. 7. 2021 v 0:12 odesílatel Jacob Champion
napsal:
> On Wed, 2021-07-21 at 00:08 +, Jacob Champion wrote:
> > I note that the doc comment for ucs_wcwidth()...
> >
> > > *- Spacing characters in the East Asian Wide (W) or East Asian
> > > * FullWidth (F) category as
Le samedi 27 mars 2021, 01:50:54 CEST Tomas Vondra a écrit :
> The current implementation is a bit ugly PoC, with a couple annoying
> issues that need to be solved:
>
Hello Thomas,
I haven't looked at the implementation at all but I think it's an interesting
idea.
> 1) The information is
On Thu, Jul 22, 2021 at 03:17:52PM -0700, Zhihong Yu wrote:
> On Thu, Jul 22, 2021 at 2:59 PM Zhihong Yu wrote:
> Hi,
>
> - tm->tm_mon += (fval * MONTHS_PER_YEAR);
> + tm->tm_mon += rint(fval * MONTHS_PER_YEAR);
>
> Should the handling for
Ranier Vilela writes:
> This is a minor leak, oversight in
> https://github.com/postgres/postgres/commit/4526951d564a7eed512b4a0ac3b5893e0a115690#diff-e399f5c029192320f310a79f18c20fb18c8e916fee993237f6f82f05dad851c5
I don't think you understand how Postgres memory management works.
There's no
Hi,
This is a minor leak, oversight in
https://github.com/postgres/postgres/commit/4526951d564a7eed512b4a0ac3b5893e0a115690#diff-e399f5c029192320f310a79f18c20fb18c8e916fee993237f6f82f05dad851c5
ExplainPropertyText does not save the *relations->data* pointer and
var relations goes out of scope.
On Wed, Jul 21, 2021 at 11:55 PM Amit Kapila wrote:
> I see here we have a mix of opinions from various people. Dilip seems
> to be favoring the approach where we provide some option to the user
> for partitioned tables and automatic behavior for non-partitioned
> tables but he also seems to have
On Thu, Jul 22, 2021 at 5:35 PM Mark Dilger
wrote:
> I agree with the need to document the theory behind all this. Event triggers
> are dangerous because they can trap a superuser into executing code they do
> not intend:
That's true. Regular triggers and views can also do that, and so can
On Thu, 22 Jul 2021 at 06:10, Amit Kapila wrote:
> It will surely work if we have an exclusive lock on both the buckets
> (old and new) in this case but I think it is better if we can avoid
> exclusive locking the old bucket (bucket_being_split) unless it is
> really required. We need an
On Fri, Jul 23, 2021 at 6:26 AM tanghy.f...@fujitsu.com
wrote:
>
> On Thursday, July 22, 2021 1:30 AM vignesh C wrote:
> >
> > Thanks for reporting this issue, this issue is fixed in the attached v13
> > patch.
> > I have changed relation name pg_publication_schema to
> > pg_publication_sch so
On Thu, Jul 22, 2021 at 9:38 AM Greg Nancarrow wrote:
>
> On Thu, Jul 22, 2021 at 1:42 PM houzj.f...@fujitsu.com
> wrote:
> >
> > Personally, the new name pg_publication_sch is not very easy to
understand.
> > (Maybe it's because I am not a native english speaker. If others feel
ok,
> > please
On Thu, Jul 22, 2021 at 4:49 PM Bauyrzhan Sakhariyev <
baurzhansahar...@gmail.com> wrote:
>
> > No, the boundary is intentionally the earlier one:
>
> I found that commit in GitHub, thanks for pointing it out.
> When I test locally origin_in_the_future case I get different results for
positive and
Le lundi 12 avril 2021, 14:01:36 CEST Luc Vlaming a écrit :
> Here's an improved and rebased patch. Hope the description helps some
> people. I will resubmit it to the next commitfest.
>
Hello Luc,
I've taken a look at this patch, and while I don't fully understand its
implications here are a
Hi Nathan!
Thanks for you interest in the topic. I think in the thread [0] we almost
agreed on general design.
The only left question is that we want to threat pg_ctl stop and kill SIGTERM
differently to pg_terminate_backend().
> 23 июля 2021 г., в 02:17, Bossart, Nathan написал(а):
>
> Hi
On Thu, 2021-07-22 at 21:17 +, Bossart, Nathan wrote:
> As previously discussed [0], canceling synchronous replication waits
> can have the unfortunate side effect of making transactions visible on
> a primary server before they are replicated. A failover at this time
> would cause such
Em sex., 23 de jul. de 2021 às 07:02, Aleksander Alekseev <
aleksan...@timescale.com> escreveu:
> Hi hackers,
>
> The following review has been posted through the commitfest application:
>> make installcheck-world: tested, passed
>> Implements feature: tested, passed
>> Spec compliant:
> 20 дек. 2019 г., в 06:39, Tomas Vondra
> написал(а):
>
> While trying to reproduce this I however ran into a related issue with
> pgoutput/pg_logical_slot_get_binary_changes. If you call the function
> repeatedly (~10x) you'll get an error like this:
>
> FATAL: out of
On Fri, Jul 23, 2021 at 2:48 AM Bossart, Nathan wrote:
>
> Hi hackers,
>
> As previously discussed [0], canceling synchronous replication waits
> can have the unfortunate side effect of making transactions visible on
> a primary server before they are replicated. A failover at this time
> would
> I still don't see the need for two functions LogStartupProgress and
> LogStartupProgressComplete. Most of the code is duplicate. I think we
> can just do it with a single function something like [1]:
Initially I had written a common function for these 2. You can see
that in the earlier version
On Fri, Jul 23, 2021 at 2:27 PM Rahila Syed wrote:
>
> On Fri, Jul 23, 2021 at 8:36 AM Amit Kapila wrote:
>>
>> On Fri, Jul 23, 2021 at 8:29 AM Amit Kapila wrote:
>> >
>> > On Thu, Jul 22, 2021 at 8:06 PM Dilip Kumar wrote:
>> > >
>> > > On Thu, Jul 22, 2021 at 5:15 PM Amit Kapila
>> > >
On Fri, Jul 23, 2021 at 7:38 PM Peter Smith wrote:
>
> I have reviewed the v10 patch.
>
> Apply / build / test was all OK.
>
> Just one review comment:
>
> //
>
> 1. Typo
>
> @@ -130,6 +132,17 @@ typedef struct RelationSyncEntry
> TupleConversionMap *map;
> } RelationSyncEntry;
>
> +/*
On Tue, Jul 20, 2021 at 9:24 AM Peter Smith wrote:
>
> Please find attached the latest patch set v98*
>
Review comments:
1.
/*
- * Handle STREAM COMMIT message.
+ * Common spoolfile processing.
+ * Returns how many changes were applied.
*/
-static void
Hi hackers,
The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:tested, passed
>
> The patch was tested on MacOS
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
The patch was tested on MacOS against master `80ba4bb3`.
I have reviewed the v10 patch.
Apply / build / test was all OK.
Just one review comment:
//
1. Typo
@@ -130,6 +132,17 @@ typedef struct RelationSyncEntry
TupleConversionMap *map;
} RelationSyncEntry;
+/*
+ * Maintain a per-transaction level variable to track whether the
+ *
Hi!
From time to time I observe $subj on clusters using logical replication.
I most of cases there are a lot of other errors. Probably $subj condition
should be kind of impossible without other problems.
I propose to enhance error logging of XLogReadRecord() in ReadPageInternal().
Thank you!
On Fri, Jul 23, 2021 at 8:36 AM Amit Kapila wrote:
> On Fri, Jul 23, 2021 at 8:29 AM Amit Kapila
> wrote:
> >
> > On Thu, Jul 22, 2021 at 8:06 PM Dilip Kumar
> wrote:
> > >
> > > On Thu, Jul 22, 2021 at 5:15 PM Amit Kapila
> wrote:
> > > >
> > > > On Tue, Jul 20, 2021 at 4:33 PM Dilip Kumar
pá 23. 7. 2021 v 10:30 odesílatel Aleksander Alekseev <
aleksan...@timescale.com> napsal:
> Hi Pavel,
>
> > I know it. Attached patch try to fix this issue
> >
> > I merged you patch (thank you)
>
> Thanks! I did some more minor changes, mostly in the comments. See the
> attached patch. Other
Alekseev
enhancing-plpgsql-dbgapi-20210723.patch
Description: Binary data
pá 23. 7. 2021 v 9:41 odesílatel Fabien COELHO napsal:
>
> >>> I tested manually for the pager feature, which mostly work, althoug
> >>> "pspg --stream" does not seem to expect two tables, or maybe there is
> >>> a way to switch between these that I have not found.
> >>
> >> pspg doesn't support
I tested manually for the pager feature, which mostly work, althoug
"pspg --stream" does not seem to expect two tables, or maybe there is
a way to switch between these that I have not found.
pspg doesn't support this feature.
Sure. Note that it is not a feature yet:-)
ISTM that having
On Thu, Jul 22, 2021 at 2:15 AM Robert Haas wrote:
>
> Thanks to Thomas Munro for drawing my attention to this thread. I
> wasn't intentionally ignoring it, but there's a lot of email in the
> world and only so much time.
>
> When I wrote this code originally, the idea that I had in mind was
>
74 matches
Mail list logo
