Shay> your analogy breaks down. Of course L2 was invented to improve
performance,
Shay> but that doesn't mean that all caches are the same. More precisely, what I
Shay> find objectionable about your approach is not any caching - it's the
Shay> implicit or automatic preparation of statements. This p
Greetings,
* Venkata B Nagothi (nag1...@gmail.com) wrote:
> The above said parameters can be configured to pause, shutdown or prevent
> promotion only after reaching the recovery target point.
> To clarify, I am referring to a scenario where recovery target point is not
> reached at all ( i mean,
On Tue, Aug 16, 2016 at 2:30 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
>
>
>> I think it makes sense to keep calling it a table because it has all the
>> logical properties of a table even though it will differ from a regular
>> table on the basis of physical implementation
On 16 August 2016 at 20:58, Greg Stark wrote:
> On Tue, Aug 16, 2016 at 10:15 AM, Craig Ringer
> wrote:
> > I'm surprised the 32-bit xid was ever exposed to the user, rather than a
> > 64-bit epoch-extended xid.
>
> Once upon a time we didn't have epoch counting at all.
>
Makes sense. I didn't
Robert Haas writes:
> On Tue, Aug 16, 2016 at 5:53 AM, Magnus Hagander wrote:
>> What's our take on backpatching such changes? Should this be 9.6 only, or
>> back further?
> I would have thought this was a master-only change, although
> back-patching it to 9.6 would be OK if it gets done RSN. I
On Tue, Aug 16, 2016 at 10:15 AM, Craig Ringer wrote:
> I'm surprised the 32-bit xid was ever exposed to the user, rather than a
> 64-bit epoch-extended xid.
Once upon a time we didn't have epoch counting at all.
I don't think it would be a bad idea to clean up everything to do with
xids so that
On Tue, Aug 16, 2016 at 12:41 AM, Josh Berkus wrote:
> Presumably people just need to add the system account tag to the unit
> file, no?
That's a system level change though. How would a normal user manage this?
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Mon, Aug 15, 2016 at 11:45 PM, Peter Eisentraut
wrote:
> If we instead installed
>
> libpq.so.5 (actual file)
> libpq.so -> libpq.so.5
>
> nothing would effectively change.
It would make it impossible to have multiple versions installed. One
doesn't normally have multiple versions with the sam
On Tue, Aug 16, 2016 at 5:53 AM, Magnus Hagander wrote:
> What's our take on backpatching such changes? Should this be 9.6 only, or
> back further?
I would have thought this was a master-only change, although
back-patching it to 9.6 would be OK if it gets done RSN. I don't
think changing GUC def
On 8/16/16 1:08 AM, Venkata B Nagothi wrote:
> The issue here is, if by any chance, the required WALs are not available
> or if there is any WAL missing or corrupted at the restore_command
> location, then PostgreSQL recovers until the end of the last available
> WAL and starts-u
On Fri, Aug 5, 2016 at 12:25 PM, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> > From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> > Yeah, I think I agree. It would be bad to disable it by default on Unix,
> > because ps(1) is a very standard tool there, but the same argument
> doesn'
On Tue, Aug 16, 2016 at 11:15 AM, Michael Paquier wrote:
> On Tue, Aug 16, 2016 at 9:14 AM, Michael Paquier
> wrote:
> > On Tue, Aug 16, 2016 at 4:19 AM, Tom Lane wrote:
> >> We have certainly not been doing that on a regular basis (as best I can
> >> tell, no such changes have been made since
On Tue, Aug 16, 2016 at 9:14 AM, Michael Paquier
wrote:
> On Tue, Aug 16, 2016 at 4:19 AM, Tom Lane wrote:
>> We have certainly not been doing that on a regular basis (as best I can
>> tell, no such changes have been made since 2010). Does anybody who uses
>> Windows want to deal with it? Or at
Hi all
While implementing support for traceable transactions (finding out after
the fact whether an xact committed or aborted), I've found that Pg is very
inconsistent with what it considers a transaction ID from a user facing
point of view, to the point where I think it's hard for users to write
On 15.08.2016 19:28, Robert Haas wrote:
Well, what's the Oracle behavior in any of these cases? I don't think
we can decide to change any of this behavior without knowing that. If
a proposed behavior change is incompatible with our previous releases,
I think it'd better at least be more compat
On 16 August 2016 at 08:33, Tom Lane wrote:
> Josh Berkus writes:
> > On 08/15/2016 05:18 PM, Tom Lane wrote:
> >> Well, yeah, it's easy to fix once you know you need to do so. The
> >> complaint is basically that out-of-the-box, it's broken, and it's
> >> not very clear what was gained by brea
On Fri, Aug 5, 2016 at 9:46 AM, Jim Nasby wrote:
> On 8/1/16 1:08 AM, Haribabu Kommi wrote:
>>
>> There are some utilities and functions that are available to calculate the
>> current system load, based on the available resources and system load,
>> the module can allow the number of parallel work
> The only place where we'd have a problem is the ecpg preprocessor
> itself, which is scheduled to be at version 4.13 this year. However,
> that version number is purely cosmetic since AFAICS the only thing
> that gets done with it is to print it in response to -v and suchlike.
> I don't really s
101 - 118 of 118 matches
Mail list logo
