> 10 янв. 2021 г., в 03:15, Noah Misch написал(а):
>
> No; it deletes the most recent ~1B and leaves the older segments. An
> exception is multixact, as described in the commit message and the patch's
> change to a comment in TruncateMultiXact().
Thanks for clarification.
One more thing:
On Sun, Jan 10, 2021 at 3:45 PM Bruce Momjian wrote:
> Does anyone know why the cfbot applied the patch listed second first
> here?
>
> http://cfbot.cputube.org/patch_31_2925.log
>
> Specifically, it applied hex..key.diff.gz before hex.diff.gz. I assumed
> it would apply attachments in
On Sat, Jan 9, 2021 at 08:08:16PM -0500, Bruce Momjian wrote:
> On Sat, Jan 9, 2021 at 01:17:36PM -0500, Bruce Momjian wrote:
> > I know we are still working on the hex patch (dest-len) and the crypto
> > tests, but I wanted to post this so people can see where we are, and we
> > can get some
On 1/8/21 8:22 PM, Alvaro Herrera wrote:
> On 2020-Dec-31, Alvaro Herrera wrote:
>
>> Here's a rebase of Simon/Pavan's MERGE patch to current sources. I
>> cleaned up some minor things in it, but aside from rebasing, it's pretty
>> much their work (even the commit message is Simon's).
>
>
On Sat, Jan 09, 2021 at 08:25:39PM +0500, Andrey Borodin wrote:
> > 9 янв. 2021 г., в 15:17, Noah Misch написал(а):
> >> I'm a little bit afraid that this kind of patch can hide bugs (while
> >> potentially saving some users data). Besides this patch seems like a
> >> useful precaution. Maybe
On Sat Jan 9, 2021 at 3:34 PM EST, Pavel Stehule wrote:
> so 9. 1. 2021 v 21:06 odesílatel Dian M Fay
> napsal:
>
> > On Thu Jan 7, 2021 at 3:24 AM EST, Pavel Stehule wrote:
> > > čt 7. 1. 2021 v 9:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > > napsal:
> > >
> > > > > On Wed, Jan 06,
so 9. 1. 2021 v 21:06 odesílatel Dian M Fay napsal:
> On Thu Jan 7, 2021 at 3:24 AM EST, Pavel Stehule wrote:
> > čt 7. 1. 2021 v 9:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> >
> > > > On Wed, Jan 06, 2021 at 09:22:53PM +0100, Pavel Stehule wrote:
> > > >
> > > > this case
On Thu, Dec 17, 2020 at 05:54:28PM +0300, Konstantin Knizhnik wrote:
> I am maintaining this code in
> g...@github.com:postgrespro/libpq_compression.git repository.
> I will be pleased if anybody, who wants to suggest any bug
> fixes/improvements of libpq compression, create pull requests: it will
Hi,
Since pg_test_fsync is supposed to simulate some aspects of
PostgreSQL's wal_sync_method settings, I think it should be updated to
use the same system calls (which changed in v12). That's mostly on
principle, though in practice, on one system I've managed to see a
small measurable
On Thu Jan 7, 2021 at 3:24 AM EST, Pavel Stehule wrote:
> čt 7. 1. 2021 v 9:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> > > On Wed, Jan 06, 2021 at 09:22:53PM +0100, Pavel Stehule wrote:
> > >
> > > this case should to raise exception - the value should be changed or
> >
Hi,
in expanded output, psql does not print the title if there are zero
results. In regular output, it prints the title ("foo") no matter how
many rows:
postgres=# \pset title foo
Title is "foo".
postgres=# SELECT 1 WHERE 1=1;
foo
?column?
--
1
(1 row)
postgres=# SELECT 1
Hi,
For WinGetFuncArgInFrame():
+ if (winobj->null_treatment == NULL_TREATMENT_IGNORE)
{
...
+ if (target > 0)
+ step = 1;
+ else if (target < 0)
+ step = -1;
+ else if (seektype == WINDOW_SEEK_HEAD)
+ step = 1;
+ else if (seektype ==
> 9 янв. 2021 г., в 15:17, Noah Misch написал(а):
>
>> This
>> int diff_max = ((QUEUE_MAX_PAGE + 1) / 2) - 1,
>> seems to be functional equivalent of
>> int diff_max = ((QUEUE_MAX_PAGE - 1) / 2),
>
> Do you think one conveys the concept better than the other?
I see now that next comments
Hi, patch applies and compiles, all included and external tests and
building of the docs pass.
After the last run of the cfbot, there are no any building warnings.
I am using last version in our testing environment with real data and I
didn't find any bugs,
so I'm marking this patch as ready for
On Sat, Jan 9, 2021 at 8:08 PM Bharath Rupireddy
wrote:
> I think this feature can be useful, in case a user has a lot of tables
> to publish inside a schema. Having said that, I wonder if this feature
> mandates users to create the same schema with same
> permissions/authorizations manually on
On Sat, Jan 9, 2021 at 5:21 PM vignesh C wrote:
> > What do we do if the user Drops the schema? Do we automatically remove
> > it from the publication?
> >
> I have not yet handled this scenario yet, I will handle this and
> adding of tests in the next patch.
>
> > I see some use of such a
>+ " create tables with using
>specified table access method,\n"
In my opinion, this sentence should be "create tables with specified table
access method" or "create tables using specified table access method".
"create tables with specified table
On 2021-01-09 02:46, Michael Paquier wrote:
+/* LCOV_EXCL_START */
Does it really make sense to add those markers here? It seems to me
that we would ignore any new coverage if regression tests based on
older versions are added (we may really want to have such tests for
more in-core extensions
On Sat, Jan 9, 2021 at 12:57 PM Amit Kapila wrote:
>
> On Tue, Jan 5, 2021 at 4:26 PM Amit Kapila wrote:
> >
> > On Tue, Jan 5, 2021 at 2:11 PM Ajin Cherian wrote:
> > >
> > >
> > > I've addressed the above comments and the patch is attached. I've
> > > called it v36-0007.
> > >
> >
> > Thanks,
On Fri, Jan 8, 2021 at 4:32 PM Amit Kapila wrote:
>
> On Thu, Jan 7, 2021 at 10:03 PM vignesh C wrote:
> >
> > This feature adds schema option while creating publication. Users will
> > be able to specify one or more schemas while creating publication,
> > when the user specifies schema option,
Hi, the building warning below is fixed now, no other changes. Also, I can
confirm that the corner case with offset=0 in lead and lag works correctly.
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute
On Fri, Jan 8, 2021 at 9:19 PM Ryan Lambert wrote:
>> Updated v11 with additional docs and some rewording of messages/tests
>> to use "system versioning" correctly.
>>
>> No changes on the points previously raised.
>>
> Thank you! The v11 applies and installs. I tried a simple test,
>
pg_dump can generate invalid SQL syntax if an aclitem in pg_init_privs
contains a GRANT OPTION (an asterisk in the aclitemout() representation).
Also, pg_dump uses REVOKE GRANT OPTION FOR where it needs plain REVOKE. For
more details, see the log message in the attached patch. I recommend
On Wed, Jan 06, 2021 at 11:28:36AM +0500, Andrey Borodin wrote:
> First patch fixes a bug with possible SLRU truncation around wrapping point
> too early.
> Basic idea of the patch is "If we want to delete a range we must be eligible
> to delete it's beginning and ending".
> So to test if page
24 matches
Mail list logo
