On Wed, May 01, 2019 at 09:18:02AM -0700, Andres Freund wrote:
> On 2019-03-23 00:02:36 -0700, Noah Misch wrote:
> > On Sat, Mar 23, 2019 at 10:20:16AM +0900, Michael Paquier wrote:
> > > On Fri, Mar 22, 2019 at 08:20:53PM -0400, Jeff Janes wrote:
> > > > PostgreSQL 12devel on aarch64-unknown-linux
On Tue, Apr 30, 2019 at 10:23:51AM +0900, Michael Paquier wrote:
> In short, as presented, the patch looks acceptable to me. Are there
> any objections to apply it on HEAD?
And committed.
--
Michael
signature.asc
Description: PGP signature
On Sat, May 04, 2019 at 12:15:19AM -0700, Noah Misch wrote:
> I pushed Jeff's patch.
Upon resolution, could you move the related open item on the wiki
page to the list of resolved issues [1]?
[1]:
https://wiki.postgresql.org/wiki/PostgreSQL_12_Open_Items#resolved_before_12beta1
--
Michael
sig
Hi,
While reading vacuumdb code, I just noticed that it can return 0 if an
error happen when -j is used, if errors happen on the last batch of
commands.
For instance:
session 1
alter database postgres set lock_timeout = 1;
begin;
lock table pg_extension;
session 2
$ vacuumdb -d postgres -t pg_ex
On Fri, May 03, 2019 at 06:29:35PM -0400, Tom Lane wrote:
> Please send any corrections by Sunday.
I have noticed a typo:
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -982,7 +982,7 @@ Branch: REL9_4_STABLE [81f5b3283] 2019-03-04
09:50:24 +0900
Errors, such
On Thu, May 02, 2019 at 10:06:42AM -0400, Tom Lane wrote:
> In view of the REINDEX-on-pg_class kerfuffle that we're currently
> sorting through, I was very glad to see that the concurrent reindex
> code doesn't even try:
>
> regression=# reindex index concurrently pg_class_oid_index;
> psql: ERROR
On Sat, May 04, 2019 at 10:35:23AM +0200, Julien Rouhaud wrote:
> While reading vacuumdb code, I just noticed that it can return 0 if an
> error happen when -j is used, if errors happen on the last batch of
> commands.
Yes, I agree that this is wrong. GetIdleSlot() is much more careful
about that
On Fri, May 3, 2019 at 2:14 PM Amit Kapila wrote:
>
> On Fri, May 3, 2019 at 11:43 AM John Naylor
> wrote:
>
> Fair enough. I think we have tried to come up with a patch for an
> alternative approach, but it needs time. I will revert this tomorrow.
>
Attached is a revert patch. John, can you
On Sat, May 4, 2019 at 11:15 AM Michael Paquier wrote:
>
> > I'm not sure
> > that a TAP test is required here, so I didn't add one. I'll be happy
> > to do so though if needed.
>
> You could make that reliable by getting a lock on a table using a
> two-phase transaction, and your test case from
On Sat, May 4, 2019 at 2:45 PM Michael Paquier wrote:
>
> On Sat, May 04, 2019 at 10:35:23AM +0200, Julien Rouhaud wrote:
> > While reading vacuumdb code, I just noticed that it can return 0 if an
> > error happen when -j is used, if errors happen on the last batch of
> > commands.
>
> Yes, I agre
I am interesting in working for a PostgreSQL project, If it's not already
taken, my preference is "Write a PostgreSQL technical mumbo-jumbo
dictionary ".
My name is Federico Razzoli. Some facts about me:
* I am a database consultant.
* In the past as a DBA I administered PostgreSQL for several com
On Sat, May 04, 2019 at 04:34:59PM +0530, Amit Kapila wrote:
> The fix looks good to me as well.
We are very close to the next minor release, so it may not be that
wise to commit a fix for that issue now as we should have a couple of
clean buildfarm clean runs. Are there any objections to wait af
On Sat, May 4, 2019 at 2:17 PM Michael Paquier wrote:
>
> On Sat, May 04, 2019 at 04:34:59PM +0530, Amit Kapila wrote:
> > The fix looks good to me as well.
>
> We are very close to the next minor release, so it may not be that
> wise to commit a fix for that issue now as we should have a couple o
On Sat, May 04, 2019 at 02:28:48PM +0200, Julien Rouhaud wrote:
> No objection from me. It's been broken since introduction in 9.5 and
> has never been noticed since, so it can wait until next release.
> Should I register the patch in the next commitfest to keep track of
> it?
No need to. I am m
On Sat, May 4, 2019 at 2:41 PM Michael Paquier wrote:
>
> On Sat, May 04, 2019 at 02:28:48PM +0200, Julien Rouhaud wrote:
> > No objection from me. It's been broken since introduction in 9.5 and
> > has never been noticed since, so it can wait until next release.
> > Should I register the patch i
On Tue, Apr 30, 2019 at 03:07:43PM +0200, Michael Banck wrote:
> This is still an open item for the back branches I guess, i.e. zero page
> header for pg_verify_checksums and additionally random page header for
> pg_basebackup's base backup.
I may be missing something, but could you add an entry i
On Fri, May 03, 2019 at 08:23:21AM -0700, Andres Freund wrote:
> I've not tested the change, but it looks reasonable to me. The change
> of moving the logic the reset of *heapOid to the unlock perhaps is
> debatable, but I think it's OK.
I have not checked the patch in details yet, but it strikes
On Thu, May 02, 2019 at 07:18:19PM -0400, Tom Lane wrote:
> I did manually verify that all branches get through "reindex table
> pg_class" and "reindex index pg_class_oid_index" under
> CLOBBER_CACHE_ALWAYS, as well as a normal-mode check-world. But CCA
> world runs seem like a good idea.
(catchi
In side-note in another thread Tom pointed out the speed improvements of
using an autoconf cache when re-building, which sounded nice to me as
config takes an annoyingly long time and is not parallelized.
But the config.cache files gets deleted by make maintainer-clean. Doesn't
that mostly defeat
On Sat, May 4, 2019 at 3:15 AM Noah Misch wrote:
>
> I pushed Jeff's patch.
>
Thank you. I've re-tested it and I get warning-free compilation now.
Cheers,
Jeff
> "Michael" == Michael Paquier writes:
Michael> I have noticed a typo:
Michael>Errors, such as lack of permissions to read the directory,
were not
Michael>detected or reported correctly; instead the code silently
acted as
Michael> - though the directory were empty.
Michael Paquier writes:
> On Thu, May 02, 2019 at 10:06:42AM -0400, Tom Lane wrote:
>> regression=# reindex index concurrently pg_class_oid_index;
>> psql: ERROR: concurrent reindex is not supported for catalog relations
>> regression=# reindex table concurrently pg_class;
>> psql: ERROR: concu
Michael Paquier writes:
> sidewinder is still pissed of as of HEAD, pointing visibly to f912d7d
> as the root cause:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sidewinder&dt=2019-05-03%2021%3A45%3A00
Right, the deadlocks are expected when some previous session is slow about
cleanin
Andrew Gierth writes:
> "Michael" == Michael Paquier writes:
> Michael> I have noticed a typo:
> Michael>Errors, such as lack of permissions to read the directory,
> were not
> Michael>detected or reported correctly; instead the code silently
> acted as
> Michael> - tho
Jeff Janes writes:
> But the config.cache files gets deleted by make maintainer-clean. Doesn't
> that mostly defeat the purpose of having a cache? Am I doing something
> wrong here, or just thinking about it wrong?
Well, a few things about that:
(1) distclean *must* remove config.cache to be s
Julien Rouhaud writes:
> On Sat, May 4, 2019 at 2:17 PM Michael Paquier wrote:
>> We are very close to the next minor release, so it may not be that
>> wise to commit a fix for that issue now as we should have a couple of
>> clean buildfarm clean runs.
> Agreed.
+1, waiting till after the minor
On Thu, May 2, 2019 at 1:03 AM Arthur Zakirov wrote:
> On Thu, May 2, 2019 at 12:49 AM Alexander Korotkov
> wrote:
> > Actually, FX takes effect on subsequent format patterns. This is not
> > documented, but it copycats Oracle behavior. Sure, normally FX should
> > be specified as the first ite
On Thu, Mar 28, 2019 at 1:30 AM Thomas Munro wrote:
> On Thu, Mar 28, 2019 at 1:48 AM Heikki Linnakangas
> wrote:
> > Once we have the FullTransactionId type and basic macros in place, I'm
> > sure we could tidy up a bunch of code by using them.
Thanks for the reviews! Pushed.
>
I think that
On Sat, May 4, 2019 at 1:34 PM Jeff Janes wrote:
> On Thu, Mar 28, 2019 at 1:30 AM Thomas Munro
> wrote:
>
>> On Thu, Mar 28, 2019 at 1:48 AM Heikki Linnakangas
>> wrote:
>> > Once we have the FullTransactionId type and basic macros in place, I'm
>> > sure we could tidy up a bunch of code by us
Thomas Munro writes:
> On Sat, May 4, 2019 at 1:29 PM Tom Lane wrote:
>> Yeah, I didn't really think it was worth distinguishing. If there
>> is some more general term that covers both calls, maybe we should
>> use that?
> I would just do s/fsync/fsync and sync_file_range/. And I guess also
>
On Wed, May 01, 2019 at 07:01:23PM -0400, Tom Lane wrote:
> > On 2019-05-01 14:44:12 -0400, Tom Lane wrote:
> >> I'm busy looking into the REINDEX-on-pg_class mess, and one thing I found
> >> while testing HEAD is that with CLOBBER_CACHE_ALWAYS on, once you've
> >> gotten a failure, your session is
Noah Misch writes:
> On Wed, May 01, 2019 at 07:01:23PM -0400, Tom Lane wrote:
>> The thing I was worried about in RelationCacheInvalidate does seem
>> to be a red herring, at least fixing it is not necessary to make
>> the broken-session-state problem go away.
> Your earlier proposal would have
>
> One question is how to aggregate ranges that would leave gaps and/or
> overlaps. So in my extension there is a one-param version that forbids
> gaps & overlaps, but I let you permit them by passing extra parameters,
> so the signature is:
>
Perhaps a third way would be to allow and preserve th
On Fri, Mar 1, 2019 at 3:59 PM Peter Geoghegan wrote:
> /*
> * Perform the same check on this internal level that
> * _bt_mark_page_halfdead performed on the leaf level.
> */
> if (_bt_is_page_halfdead(rel, *rightsib))
> I thought tha
On Sat, May 4, 2019 at 5:25 PM Amit Kapila wrote:
> Attached is a revert patch. John, can you please once double-check to
> ensure I have not missed anything?
Looks complete to me.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Trai
On Sat, May 04, 2019 at 02:32:06PM +0900, Ronny Ko wrote:
Hi,
I am trying to efficiently rollback a manually selectedd subset of
comm
On Fri, May 03, 2019 at 09:42:17PM +0200, Tomas Vondra wrote:
On Fri, May 03, 2019 at 12:21:36PM -0400, Tom Lane wrote:
Alvaro Herrera writes:
Error reporting in extended statistics is inconsistent -- many messages
that are ereport() in mvdistinct.c are elog() in the other modules.
...
I think
On 5/3/19 6:29 PM, Tom Lane wrote:
> See
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8b3bce2017b15e05f000c3c5947653a3e2c5a29f
>
> Please send any corrections by Sunday.
Attached is a draft of the press release to go out. Please let me know
if there are any inaccuracies
On Sun, May 5, 2019 at 2:35 PM Jonathan S. Katz wrote:
> On 5/3/19 6:29 PM, Tom Lane wrote:
> > See
> >
> > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8b3bce2017b15e05f000c3c5947653a3e2c5a29f
> >
> > Please send any corrections by Sunday.
>
> Attached is a draft of the pres
On Wed, May 01, 2019 at 09:18:02AM -0700, Andres Freund wrote:
> On 2019-03-23 00:02:36 -0700, Noah Misch wrote:
> > On Sat, Mar 23, 2019 at 10:20:16AM +0900, Michael Paquier wrote:
> > > On Fri, Mar 22, 2019 at 08:20:53PM -0400, Jeff Janes wrote:
> > > > PostgreSQL 12devel on aarch64-unknown-linux
On Tue, Apr 30, 2019 at 10:23:51AM +0900, Michael Paquier wrote:
> In short, as presented, the patch looks acceptable to me. Are there
> any objections to apply it on HEAD?
And committed.
--
Michael
signature.asc
Description: PGP signature
On Sat, May 04, 2019 at 12:15:19AM -0700, Noah Misch wrote:
> I pushed Jeff's patch.
Upon resolution, could you move the related open item on the wiki
page to the list of resolved issues [1]?
[1]:
https://wiki.postgresql.org/wiki/PostgreSQL_12_Open_Items#resolved_before_12beta1
--
Michael
sig
Hi,
While reading vacuumdb code, I just noticed that it can return 0 if an
error happen when -j is used, if errors happen on the last batch of
commands.
For instance:
session 1
alter database postgres set lock_timeout = 1;
begin;
lock table pg_extension;
session 2
$ vacuumdb -d postgres -t pg_ex
On Fri, May 03, 2019 at 06:29:35PM -0400, Tom Lane wrote:
> Please send any corrections by Sunday.
I have noticed a typo:
--- a/doc/src/sgml/release-11.sgml
+++ b/doc/src/sgml/release-11.sgml
@@ -982,7 +982,7 @@ Branch: REL9_4_STABLE [81f5b3283] 2019-03-04
09:50:24 +0900
Errors, such
On Thu, May 02, 2019 at 10:06:42AM -0400, Tom Lane wrote:
> In view of the REINDEX-on-pg_class kerfuffle that we're currently
> sorting through, I was very glad to see that the concurrent reindex
> code doesn't even try:
>
> regression=# reindex index concurrently pg_class_oid_index;
> psql: ERROR
On Sat, May 04, 2019 at 10:35:23AM +0200, Julien Rouhaud wrote:
> While reading vacuumdb code, I just noticed that it can return 0 if an
> error happen when -j is used, if errors happen on the last batch of
> commands.
Yes, I agree that this is wrong. GetIdleSlot() is much more careful
about that
On Fri, May 3, 2019 at 2:14 PM Amit Kapila wrote:
>
> On Fri, May 3, 2019 at 11:43 AM John Naylor
> wrote:
>
> Fair enough. I think we have tried to come up with a patch for an
> alternative approach, but it needs time. I will revert this tomorrow.
>
Attached is a revert patch. John, can you
On Sat, May 4, 2019 at 11:15 AM Michael Paquier wrote:
>
> > I'm not sure
> > that a TAP test is required here, so I didn't add one. I'll be happy
> > to do so though if needed.
>
> You could make that reliable by getting a lock on a table using a
> two-phase transaction, and your test case from
On Sat, May 4, 2019 at 2:45 PM Michael Paquier wrote:
>
> On Sat, May 04, 2019 at 10:35:23AM +0200, Julien Rouhaud wrote:
> > While reading vacuumdb code, I just noticed that it can return 0 if an
> > error happen when -j is used, if errors happen on the last batch of
> > commands.
>
> Yes, I agre
I am interesting in working for a PostgreSQL project, If it's not already
taken, my preference is "Write a PostgreSQL technical mumbo-jumbo
dictionary ".
My name is Federico Razzoli. Some facts about me:
* I am a database consultant.
* In the past as a DBA I administered PostgreSQL for several com
On Sat, May 04, 2019 at 04:34:59PM +0530, Amit Kapila wrote:
> The fix looks good to me as well.
We are very close to the next minor release, so it may not be that
wise to commit a fix for that issue now as we should have a couple of
clean buildfarm clean runs. Are there any objections to wait af
On Sat, May 4, 2019 at 2:17 PM Michael Paquier wrote:
>
> On Sat, May 04, 2019 at 04:34:59PM +0530, Amit Kapila wrote:
> > The fix looks good to me as well.
>
> We are very close to the next minor release, so it may not be that
> wise to commit a fix for that issue now as we should have a couple o
On Sat, May 04, 2019 at 02:28:48PM +0200, Julien Rouhaud wrote:
> No objection from me. It's been broken since introduction in 9.5 and
> has never been noticed since, so it can wait until next release.
> Should I register the patch in the next commitfest to keep track of
> it?
No need to. I am m
On Sat, May 4, 2019 at 2:41 PM Michael Paquier wrote:
>
> On Sat, May 04, 2019 at 02:28:48PM +0200, Julien Rouhaud wrote:
> > No objection from me. It's been broken since introduction in 9.5 and
> > has never been noticed since, so it can wait until next release.
> > Should I register the patch i
On Tue, Apr 30, 2019 at 03:07:43PM +0200, Michael Banck wrote:
> This is still an open item for the back branches I guess, i.e. zero page
> header for pg_verify_checksums and additionally random page header for
> pg_basebackup's base backup.
I may be missing something, but could you add an entry i
On Fri, May 03, 2019 at 08:23:21AM -0700, Andres Freund wrote:
> I've not tested the change, but it looks reasonable to me. The change
> of moving the logic the reset of *heapOid to the unlock perhaps is
> debatable, but I think it's OK.
I have not checked the patch in details yet, but it strikes
On Thu, May 02, 2019 at 07:18:19PM -0400, Tom Lane wrote:
> I did manually verify that all branches get through "reindex table
> pg_class" and "reindex index pg_class_oid_index" under
> CLOBBER_CACHE_ALWAYS, as well as a normal-mode check-world. But CCA
> world runs seem like a good idea.
(catchi
In side-note in another thread Tom pointed out the speed improvements of
using an autoconf cache when re-building, which sounded nice to me as
config takes an annoyingly long time and is not parallelized.
But the config.cache files gets deleted by make maintainer-clean. Doesn't
that mostly defeat
On Sat, May 4, 2019 at 3:15 AM Noah Misch wrote:
>
> I pushed Jeff's patch.
>
Thank you. I've re-tested it and I get warning-free compilation now.
Cheers,
Jeff
> "Michael" == Michael Paquier writes:
Michael> I have noticed a typo:
Michael>Errors, such as lack of permissions to read the directory,
were not
Michael>detected or reported correctly; instead the code silently
acted as
Michael> - though the directory were empty.
Michael Paquier writes:
> On Thu, May 02, 2019 at 10:06:42AM -0400, Tom Lane wrote:
>> regression=# reindex index concurrently pg_class_oid_index;
>> psql: ERROR: concurrent reindex is not supported for catalog relations
>> regression=# reindex table concurrently pg_class;
>> psql: ERROR: concu
Michael Paquier writes:
> sidewinder is still pissed of as of HEAD, pointing visibly to f912d7d
> as the root cause:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sidewinder&dt=2019-05-03%2021%3A45%3A00
Right, the deadlocks are expected when some previous session is slow about
cleanin
Andrew Gierth writes:
> "Michael" == Michael Paquier writes:
> Michael> I have noticed a typo:
> Michael>Errors, such as lack of permissions to read the directory,
> were not
> Michael>detected or reported correctly; instead the code silently
> acted as
> Michael> - tho
Jeff Janes writes:
> But the config.cache files gets deleted by make maintainer-clean. Doesn't
> that mostly defeat the purpose of having a cache? Am I doing something
> wrong here, or just thinking about it wrong?
Well, a few things about that:
(1) distclean *must* remove config.cache to be s
Julien Rouhaud writes:
> On Sat, May 4, 2019 at 2:17 PM Michael Paquier wrote:
>> We are very close to the next minor release, so it may not be that
>> wise to commit a fix for that issue now as we should have a couple of
>> clean buildfarm clean runs.
> Agreed.
+1, waiting till after the minor
On Thu, May 2, 2019 at 1:03 AM Arthur Zakirov wrote:
> On Thu, May 2, 2019 at 12:49 AM Alexander Korotkov
> wrote:
> > Actually, FX takes effect on subsequent format patterns. This is not
> > documented, but it copycats Oracle behavior. Sure, normally FX should
> > be specified as the first ite
On Thu, Mar 28, 2019 at 1:30 AM Thomas Munro wrote:
> On Thu, Mar 28, 2019 at 1:48 AM Heikki Linnakangas
> wrote:
> > Once we have the FullTransactionId type and basic macros in place, I'm
> > sure we could tidy up a bunch of code by using them.
Thanks for the reviews! Pushed.
>
I think that
On Sat, May 4, 2019 at 1:34 PM Jeff Janes wrote:
> On Thu, Mar 28, 2019 at 1:30 AM Thomas Munro
> wrote:
>
>> On Thu, Mar 28, 2019 at 1:48 AM Heikki Linnakangas
>> wrote:
>> > Once we have the FullTransactionId type and basic macros in place, I'm
>> > sure we could tidy up a bunch of code by us
Thomas Munro writes:
> On Sat, May 4, 2019 at 1:29 PM Tom Lane wrote:
>> Yeah, I didn't really think it was worth distinguishing. If there
>> is some more general term that covers both calls, maybe we should
>> use that?
> I would just do s/fsync/fsync and sync_file_range/. And I guess also
>
On Wed, May 01, 2019 at 07:01:23PM -0400, Tom Lane wrote:
> > On 2019-05-01 14:44:12 -0400, Tom Lane wrote:
> >> I'm busy looking into the REINDEX-on-pg_class mess, and one thing I found
> >> while testing HEAD is that with CLOBBER_CACHE_ALWAYS on, once you've
> >> gotten a failure, your session is
Noah Misch writes:
> On Wed, May 01, 2019 at 07:01:23PM -0400, Tom Lane wrote:
>> The thing I was worried about in RelationCacheInvalidate does seem
>> to be a red herring, at least fixing it is not necessary to make
>> the broken-session-state problem go away.
> Your earlier proposal would have
>
> One question is how to aggregate ranges that would leave gaps and/or
> overlaps. So in my extension there is a one-param version that forbids
> gaps & overlaps, but I let you permit them by passing extra parameters,
> so the signature is:
>
Perhaps a third way would be to allow and preserve th
On Fri, Mar 1, 2019 at 3:59 PM Peter Geoghegan wrote:
> /*
> * Perform the same check on this internal level that
> * _bt_mark_page_halfdead performed on the leaf level.
> */
> if (_bt_is_page_halfdead(rel, *rightsib))
> I thought tha
On Sat, May 4, 2019 at 5:25 PM Amit Kapila wrote:
> Attached is a revert patch. John, can you please once double-check to
> ensure I have not missed anything?
Looks complete to me.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Trai
On Sat, May 04, 2019 at 02:32:06PM +0900, Ronny Ko wrote:
Hi,
I am trying to efficiently rollback a manually selectedd subset of
comm
On Fri, May 03, 2019 at 09:42:17PM +0200, Tomas Vondra wrote:
On Fri, May 03, 2019 at 12:21:36PM -0400, Tom Lane wrote:
Alvaro Herrera writes:
Error reporting in extended statistics is inconsistent -- many messages
that are ereport() in mvdistinct.c are elog() in the other modules.
...
I think
On 5/3/19 6:29 PM, Tom Lane wrote:
> See
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8b3bce2017b15e05f000c3c5947653a3e2c5a29f
>
> Please send any corrections by Sunday.
Attached is a draft of the press release to go out. Please let me know
if there are any inaccuracies
On Sun, May 5, 2019 at 2:35 PM Jonathan S. Katz wrote:
> On 5/3/19 6:29 PM, Tom Lane wrote:
> > See
> >
> > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8b3bce2017b15e05f000c3c5947653a3e2c5a29f
> >
> > Please send any corrections by Sunday.
>
> Attached is a draft of the pres
78 matches
Mail list logo
