I just did did a "git pull" to test one of my patches and i get the
following error :
2016-10-23 18:51:47.679 AEDT [31930] FATAL: could not open archive status
directory "pg_xlog/archive_status": No such file or directory
2016-10-23 18:51:47.679 AEDT [31841] LOG: archiver process (PID 31930)
exi
On 10/22/2016 06:00 PM, David Steele wrote:
> On 10/22/16 6:58 PM, Bruce Momjian wrote:
>> On Sat, Oct 22, 2016 at 07:33:56AM +0900, Michael Paquier wrote:
>>> On Sat, Oct 22, 2016 at 4:29 AM, Alvaro Herrera
>>>
Also +1 to renaming pg_subtrans to pg_subxact.
>>>
>>> Nice suggestion, good namin
On Sun, Oct 23, 2016 at 5:05 PM, Venkata B Nagothi wrote:
> I just did did a "git pull" to test one of my patches and i get the
> following error :
>
> 2016-10-23 18:51:47.679 AEDT [31930] FATAL: could not open archive status
> directory "pg_xlog/archive_status": No such file or directory
> 2016-
On Sun, Oct 23, 2016 at 5:18 PM, Vik Fearing wrote:
> On 10/22/2016 06:00 PM, David Steele wrote:
>> On 10/22/16 6:58 PM, Bruce Momjian wrote:
>>> On Sat, Oct 22, 2016 at 07:33:56AM +0900, Michael Paquier wrote:
On Sat, Oct 22, 2016 at 4:29 AM, Alvaro Herrera
> Also +1 to renaming pg
On Fri, Oct 21, 2016 at 2:02 PM, Michael Paquier
wrote:
> On Mon, Oct 17, 2016 at 2:37 PM, Michael Paquier
> wrote:
> > Except that it looks in pretty good to me, so I am switching that as
> > ready for committer.
>
> + /*
> +* Create pg_xlog/archive_status (and thus pg_xlog) so we
On Mon, Oct 17, 2016 at 7:37 AM, Michael Paquier
wrote:
> On Sat, Oct 15, 2016 at 8:51 AM, Magnus Hagander
> wrote:
> > Fixed.
>
> Ok, I had a extra look on the patch:
> + The transactionn log files are written to a separate file
> +called pg_xlog.tar.
> +
> s/tr
On Sun, Oct 23, 2016 at 10:30 PM, Magnus Hagander wrote:
> On Mon, Oct 17, 2016 at 7:37 AM, Michael Paquier
> wrote:
>> > But independent of this patch, actually putting that test in for non-tar
>> > mode would probably not be a bad idea -- if that breaks, it's likely
>> > both
>> > break, after
On 10/22/2016 08:30 PM, Tomas Vondra wrote:
On 10/20/2016 04:43 PM, Robert Haas wrote:
>>
...
The sb_alloc allocator I proposed a couple of years ago would work
well for this case, I think.
Maybe, but it does not follow the Memory Context design at all, if I
understand it correctly. I was w
On 23/10/16 16:26, Tomas Vondra wrote:
> On 10/22/2016 08:30 PM, Tomas Vondra wrote:
>> On 10/20/2016 04:43 PM, Robert Haas wrote:
>>>
>>> ...
>>>
>>> The sb_alloc allocator I proposed a couple of years ago would work
>>> well for this case, I think.
>>>
>>
>> Maybe, but it does not follow the Memo
On Tue, Oct 4, 2016 at 12:12 PM, Thomas Munro
wrote:
> Here's a rebased patch. ConditionVariableSleep now takes
> wait_event_info. Anyone using this in patches for core probably needs
> to add enumerators to the WaitEventXXX enums in pgstat.h to describe
> their wait points.
I think that there
Looking at the issue raised in
https://www.postgresql.org/message-id/flat/57EE93C8.8080504%40postgrespro.ru
prompted me to wonder whether there were any other places in which we
were calling tqual.c routines without holding buffer content lock.
I tried adding
Assert(BufferIsLocal(buffer) ||
On Sunday, 23 October 2016, Michael Paquier
wrote:
> On Sun, Oct 23, 2016 at 5:05 PM, Venkata B Nagothi
> wrote:
> > I just did did a "git pull" to test one of my patches and i get the
> > following error :
> >
> > 2016-10-23 18:51:47.679 AEDT [31930] FATAL: could not open archive
> status
> >
Robert Haas wrote:
> On Wed, Oct 19, 2016 at 6:30 PM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> On Mon, Jan 4, 2016 at 10:30 AM, Tom Lane wrote:
> >> >> This seems like a might subtle thing to backpatch. If we really want to
> >> >> go there, ISTM that the relevant code should stew in a
Peter Geoghegan writes:
> On Sat, Oct 22, 2016 at 9:38 AM, Tom Lane wrote:
>> 1. Why are you replacing ExecOnConflictUpdate's ExecCheckHeapTupleVisible
>> call with ExecCheckTIDVisible? That appears to demand a re-fetch of the
>> tuple ExecOnConflictUpdate already has its hands on. Wouldn't it
On Sun, Oct 23, 2016 at 1:42 PM, Tom Lane wrote:
> "Rarely" is not "never". A bigger problem though is that heap_fetch
> does more than just lock the buffer: there are also PredicateLockTuple
> and CheckForSerializableConflictOut calls in there. It's possible that
> those are no-ops in this usag
Peter Geoghegan writes:
> On Sun, Oct 23, 2016 at 1:42 PM, Tom Lane wrote:
>> "Rarely" is not "never". A bigger problem though is that heap_fetch
>> does more than just lock the buffer: there are also PredicateLockTuple
>> and CheckForSerializableConflictOut calls in there. It's possible that
>
On Sun, Oct 23, 2016 at 2:46 PM, Tom Lane wrote:
> What's bothering me is (a) it's less than 24 hours to release wrap and
> (b) this patch changes SSI-relevant behavior and hasn't been approved
> by Kevin. I'm not familiar enough with that logic to commit a change
> in it on my own authority, esp
On Thu, Oct 20, 2016 at 06:14:28PM +0100, Greg Stark wrote:
> On Oct 20, 2016 5:27 PM, "Noah Misch" wrote:
> > On Wed, Oct 19, 2016 at 11:08:39AM +0100, Greg Stark wrote:
> > > The MEMPOOL_FREE doesn't take any size argument and mcxt.c doesn't
> > > have convenient access to a size argument. It co
Hi,
The last argument of create_foreignscan_path called by
postgresGetForeignJoinPaths is
set to NULL, but it would be suitable to set it to NIL because the argument
type is List.
Please find attached a patch.
Tatsuro Yamada
NTT Open Source Software Center
diff --git a/contrib/postgres_fdw/pos
Hello everyone,
I’d like to submit the attached patch for feedback from the PostgreSQL
community and potential future inclusion in the codebase. The patch adds a new
parameter to the RADIUS authentication method named “radiustimeout”, allowing
the database administrator to configure the timeout
Thank you for looking and retelling this.
At Fri, 21 Oct 2016 13:02:21 -0400, Robert Haas wrote
in
> On Sun, Oct 2, 2016 at 8:52 AM, Michael Paquier
> wrote:
> >> So, if I understand correctly, then we can mark the version posted by
> >> you upthread [1] which includes a test along with Kyotar
On Sat, Oct 22, 2016 at 7:31 AM, Michael Paquier
wrote:
> On Sat, Oct 22, 2016 at 5:17 AM, Jim Nasby wrote:
>> On 10/20/16 10:15 PM, Michael Paquier wrote:
>>>
>>> 2) If anything is found, stop the server and delete the files manually.
>>> 3) Re-start the server.
>>> OK, that's troublesome and co
On Fri, Oct 21, 2016 at 10:32 PM, Robert Haas wrote:
> On Sun, Oct 2, 2016 at 8:52 AM, Michael Paquier
> wrote:
>>> So, if I understand correctly, then we can mark the version posted by
>>> you upthread [1] which includes a test along with Kyotaro's fix can be
>>> marked as Ready for committer.
On Sun, Oct 23, 2016 at 10:52 PM, Michael Paquier
wrote:
> On Sun, Oct 23, 2016 at 10:30 PM, Magnus Hagander wrote:
>> I think both of those would be worthwhile. Just for the testability in
>> itself, but such a flag to pg_xlogdump would probably be useful in other
>> cases as well, beyond just t
On 2016-10-17 14:37:05 +0900, Michael Paquier wrote:
> 2) Add an option to pg_xlogdump to be able to output its output to a
> file. That would be awkward to rely on grabbing the output data from a
> pipe... On Windows particularly. Thinking about it, would that
> actually be useful to others? That'
On Mon, Oct 24, 2016 at 9:18 AM, Kyotaro HORIGUCHI
wrote:
> Thank you for looking and retelling this.
>
> At Fri, 21 Oct 2016 13:02:21 -0400, Robert Haas wrote
> in
>> On Sun, Oct 2, 2016 at 8:52 AM, Michael Paquier
>> wrote:
>> >> So, if I understand correctly, then we can mark the version po
On Mon, Oct 24, 2016 at 1:38 PM, Andres Freund wrote:
> On 2016-10-17 14:37:05 +0900, Michael Paquier wrote:
>> 2) Add an option to pg_xlogdump to be able to output its output to a
>> file. That would be awkward to rely on grabbing the output data from a
>> pipe... On Windows particularly. Thinkin
(Moved to -hackers)
On Sun, Oct 23, 2016 at 10:57 PM, Magnus Hagander wrote:
> Remove extra comma at end of enum list
>
> C99-specific feature, and wasn't intentional in the first place.
>
> Per buildfarm member mylodon
This is the second time I see that in the last couple of weeks. Would
it be
On 22 October 2016 at 19:51, Julien Rouhaud wrote:
> I just noticed that if track_commit_timestamp is enabled, the
> oldestCommitTsXid and newestCommitTsXid don't persist after a server
> restart, so you can't ask for the commit ts of a transaction that
> committed before the last server start, al
(thread hijacking)
On Mon, Oct 24, 2016 at 1:58 PM, Craig Ringer wrote:
> To save time running the recovery suite, just
>
>rm src/test/recovery/00[0-8]*.pl
>
> (It'd be nice to have a prove_check target to run just one test file).
Agreed! Or multiple chosen files. I usually remove those file
On 24 October 2016 at 12:58, Craig Ringer wrote:
> The attached patch adds a TAP test to src/test/recovery to show this.
Added to CF.
https://commitfest.postgresql.org/11/834/
... but IMO this should go in the next bugfix release.
I've also applied nearly the same fix for the same bug in the
On Sun, Oct 23, 2016 at 10:28 PM, Magnus Hagander wrote:
> It also broke the tests and invalidated some documentation. But it was easy
> enough to fix.
>
> I've now applied this, so next time you get to do the merging :P Joking
> aside, please review and let me know if you can spot something I mes
On Thu, Oct 20, 2016 at 1:12 PM, Amit Kapila
wrote:
> On Tue, Oct 18, 2016 at 5:29 PM, Rushabh Lathia
> wrote:
> > On Mon, Oct 17, 2016 at 2:26 PM, Amit Kapila
> > wrote:
> >>
> >> There is lot of common code between ExecGatherMerge and ExecGather.
> >> Do you think it makes sense to have a com
C99-specific feature, and wasn't intentional in the first place.
Per buildfarm member mylodon
This is the second time I see that in the last couple of weeks. Would
it be better to use some custom CFLAGS to detect that earlier in the
review process? I have never much used gcc's std or clang ex
On Mon, Oct 24, 2016 at 7:56 AM, Tatsuro Yamada
wrote:
> Hi,
>
> The last argument of create_foreignscan_path called by
> postgresGetForeignJoinPaths is
> set to NULL, but it would be suitable to set it to NIL because the argument
> type is List.
>
> Please find attached a patch.
>
You are right
On Mon, Oct 24, 2016 at 1:39 PM, Amit Kapila wrote:
> On Mon, Oct 24, 2016 at 9:18 AM, Kyotaro HORIGUCHI
> wrote:
>> Thank you for looking and retelling this.
+1.
>> At Fri, 21 Oct 2016 13:02:21 -0400, Robert Haas
>> wrote in
>>> I can think of two solutions that would be "tighter":
>>>
>>>
36 matches
Mail list logo