On Tue, Jul 13, 2021 at 5:18 PM Thomas Munro wrote:
> https://illumos.org/man/2/sigwait
> https://docs.oracle.com/cd/E36784_01/html/E36872/sigwait-2.html
Oh, hmm, that's something we already have to do elsewhere to get
standard conforming interfaces on that platform:
# Some platforms use these,
On Tue, Jul 13, 2021 at 4:15 PM Tom Lane wrote:
> Huh ... gaur did this:
>
> /usr/ccs/bin/ld: Unsatisfied symbols:
>sigwait (code)
>
> which is not what I was expecting, because there is a definition for
> sigwait in /usr/include (though not in a header file we use). It must
> be in some add-
Thomas Munro writes:
> On Tue, Jul 13, 2021 at 1:09 PM Tom Lane wrote:
>> That won't help as-is, because it *does* have sigwait, just not with
>> the POSIX API. thread_test.c does this:
>>
>> /* Test for POSIX.1c 2-arg sigwait() and fail on single-arg version */
>> #include
>> int
Remove useless range checks on INT8 sequences
There's no point in checking if an INT8 sequence has a seqmin and seqmax
value is outside the range of the minimum and maximum values for an int64
type. These both use the same underlying types so an INT8 certainly
cannot be outside the minimum and ma
Robustify tuplesort's free_sort_tuple function
41469253e went to the trouble of removing a theoretical bug from
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's
make this a little more robust by also setting the tuple to NULL so that
should we be called again we won't end
Robustify tuplesort's free_sort_tuple function
41469253e went to the trouble of removing a theoretical bug from
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's
make this a little more robust by also setting the tuple to NULL so that
should we be called again we won't end
Robustify tuplesort's free_sort_tuple function
41469253e went to the trouble of removing a theoretical bug from
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's
make this a little more robust by also setting the tuple to NULL so that
should we be called again we won't end
Robustify tuplesort's free_sort_tuple function
41469253e went to the trouble of removing a theoretical bug from
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's
make this a little more robust by also setting the tuple to NULL so that
should we be called again we won't end
Robustify tuplesort's free_sort_tuple function
41469253e went to the trouble of removing a theoretical bug from
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's
make this a little more robust by also setting the tuple to NULL so that
should we be called again we won't end
Robustify tuplesort's free_sort_tuple function
41469253e went to the trouble of removing a theoretical bug from
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's
make this a little more robust by also setting the tuple to NULL so that
should we be called again we won't end
Robustify tuplesort's free_sort_tuple function
41469253e went to the trouble of removing a theoretical bug from
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's
make this a little more robust by also setting the tuple to NULL so that
should we be called again we won't end
On Tue, Jul 13, 2021 at 1:09 PM Tom Lane wrote:
> Thomas Munro writes:
> > Oh, thanks for the advance warning. Wouldn't HAVE_SIGWAIT be better?
> > Like so.
>
> That won't help as-is, because it *does* have sigwait, just not with
> the POSIX API. thread_test.c does this:
>
> /* Test for POSI
Thomas Munro writes:
> On Tue, Jul 13, 2021 at 12:30 PM Tom Lane wrote:
>> I think this is going to fall over on gaur, which doesn't have POSIX-style
>> sigwait.
> Oh, thanks for the advance warning. Wouldn't HAVE_SIGWAIT be better? Like
> so.
That won't help as-is, because it *does* have s
On Tue, Jul 13, 2021 at 12:30 PM Tom Lane wrote:
>
> Thomas Munro writes:
> > To make \watch react quickly when the user quits the pager or presses
> > ^C, and also to increase the accuracy of its timing and decrease the
> > rate of useless context switches, change the main loop of the \watch
> >
On Tue, 13 Jul 2021 at 12:42, Tom Lane wrote:
>
> ... btw, wouldn't it be advisable to set stup->tuple to NULL
> after dropping the referenced storage?
I think that's probably a good idea.
I'll adjust that now...
David
Fix theoretical bug in tuplesort
This fixes a theoretical bug in tuplesort.c which, if a bounded sort was
used in combination with a byval Datum sort (tuplesort_begin_datum), when
switching the sort to a bounded heap in make_bounded_heap(), we'd call
free_sort_tuple(). The problem was that when s
Fix theoretical bug in tuplesort
This fixes a theoretical bug in tuplesort.c which, if a bounded sort was
used in combination with a byval Datum sort (tuplesort_begin_datum), when
switching the sort to a bounded heap in make_bounded_heap(), we'd call
free_sort_tuple(). The problem was that when s
Fix theoretical bug in tuplesort
This fixes a theoretical bug in tuplesort.c which, if a bounded sort was
used in combination with a byval Datum sort (tuplesort_begin_datum), when
switching the sort to a bounded heap in make_bounded_heap(), we'd call
free_sort_tuple(). The problem was that when s
Fix theoretical bug in tuplesort
This fixes a theoretical bug in tuplesort.c which, if a bounded sort was
used in combination with a byval Datum sort (tuplesort_begin_datum), when
switching the sort to a bounded heap in make_bounded_heap(), we'd call
free_sort_tuple(). The problem was that when s
Fix theoretical bug in tuplesort
This fixes a theoretical bug in tuplesort.c which, if a bounded sort was
used in combination with a byval Datum sort (tuplesort_begin_datum), when
switching the sort to a bounded heap in make_bounded_heap(), we'd call
free_sort_tuple(). The problem was that when s
... btw, wouldn't it be advisable to set stup->tuple to NULL
after dropping the referenced storage?
regards, tom lane
Fix theoretical bug in tuplesort
This fixes a theoretical bug in tuplesort.c which, if a bounded sort was
used in combination with a byval Datum sort (tuplesort_begin_datum), when
switching the sort to a bounded heap in make_bounded_heap(), we'd call
free_sort_tuple(). The problem was that when s
Fix theoretical bug in tuplesort
This fixes a theoretical bug in tuplesort.c which, if a bounded sort was
used in combination with a byval Datum sort (tuplesort_begin_datum), when
switching the sort to a bounded heap in make_bounded_heap(), we'd call
free_sort_tuple(). The problem was that when s
Thomas Munro writes:
> To make \watch react quickly when the user quits the pager or presses
> ^C, and also to increase the accuracy of its timing and decrease the
> rate of useless context switches, change the main loop of the \watch
> command to use sigwait() rather than a sleeping/polling loop,
Add PSQL_WATCH_PAGER for psql's \watch command.
Allow a pager to be used by the \watch command. This works but isn't
very useful with traditional pagers like "less", so use a different
environment variable. The popular open source tool "pspg" (also by
Pavel) knows how to display the output if yo
Probe for preadv/pwritev in a more macOS-friendly way.
Apple's mechanism for dealing with functions that are available
in only some OS versions confuses AC_CHECK_FUNCS, and therefore
AC_REPLACE_FUNCS. We can use AC_CHECK_DECLS instead, so long as
we enable -Werror=unguarded-availability-new. Thi
Probe for preadv/pwritev in a more macOS-friendly way.
Apple's mechanism for dealing with functions that are available
in only some OS versions confuses AC_CHECK_FUNCS, and therefore
AC_REPLACE_FUNCS. We can use AC_CHECK_DECLS instead, so long as
we enable -Werror=unguarded-availability-new. Thi
Replace RelationOpenSmgr() with RelationGetSmgr().
The idea behind this patch is to design out bugs like the one fixed
by commit 9d523119f. Previously, once one did RelationOpenSmgr(rel),
it was considered okay to access rel->rd_smgr directly for some
not-very-clear interval. But since that poin
doc: Fix typo in function prototype
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/b6178520d2d914a274763659b361247c7dc45ef7
Modified Files
--
doc/src/sgml/indexam.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
doc: Fix typo in function prototype
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/75e9356a7df557473c8aeacd3e8e6a157f0ff4a8
Modified Files
--
doc/src/sgml/indexam.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
doc: Fix typo in function prototype
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/fa84ff75a3417a4852e85b15395094e69d4ca7ab
Modified Files
--
doc/src/sgml/indexam.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
doc: Fix typo in function prototype
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/9b450b1f1e5bbeac414bbb8e6a2f08fa40f470ff
Modified Files
--
doc/src/sgml/indexam.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
doc: Fix typo in function prototype
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/9c3113e5737ec75ee65d48527845148826efc3ef
Modified Files
--
doc/src/sgml/indexam.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
doc: Fix typo in function prototype
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/5b60cf35f566697030a2895dfe27dde2e34dd370
Modified Files
--
doc/src/sgml/indexam.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
doc: Fix typo in function prototype
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/0455f35fd4ecff99df49ee7137a53ba2b6b3c24b
Modified Files
--
doc/src/sgml/indexam.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Remove dead assignment to local variable.
This should have been removed in commit 7e30c186da, which split the loop
into two. Only the first loop uses the 'from' variable; updating it in
the second loop is bogus. It was never read after the first loop, so this
was harmless and surely optimized away
Remove dead assignment to local variable.
This should have been removed in commit 7e30c186da, which split the loop
into two. Only the first loop uses the 'from' variable; updating it in
the second loop is bogus. It was never read after the first loop, so this
was harmless and surely optimized away
Remove dead assignment to local variable.
This should have been removed in commit 7e30c186da, which split the loop
into two. Only the first loop uses the 'from' variable; updating it in
the second loop is bogus. It was never read after the first loop, so this
was harmless and surely optimized away
Remove dead assignment to local variable.
This should have been removed in commit 7e30c186da, which split the loop
into two. Only the first loop uses the 'from' variable; updating it in
the second loop is bogus. It was never read after the first loop, so this
was harmless and surely optimized away
Remove dead assignment to local variable.
This should have been removed in commit 7e30c186da, which split the loop
into two. Only the first loop uses the 'from' variable; updating it in
the second loop is bogus. It was never read after the first loop, so this
was harmless and surely optimized away
Remove dead assignment to local variable.
This should have been removed in commit 7e30c186da, which split the loop
into two. Only the first loop uses the 'from' variable; updating it in
the second loop is bogus. It was never read after the first loop, so this
was harmless and surely optimized away
Remove dead assignment to local variable.
This should have been removed in commit 7e30c186da, which split the loop
into two. Only the first loop uses the 'from' variable; updating it in
the second loop is bogus. It was never read after the first loop, so this
was harmless and surely optimized away
42 matches
Mail list logo
