On Sun, Jun 14, 2015 at 10:30 AM, Tomas Vondra wrote:
>
>> Are you looking to avoid all hardware-based limits, or would using a 64
>> bit row pointer be possible? That would give you 2^64 or 1.8 E19 unique
>> rows over whatever granularity/uniqueness you use (per table, per
>> database, etc.)
On Thu, Jun 11, 2015 at 7:03 PM, Alvaro Herrera
wrote:
> We hope to have a chance to discuss this during the upcoming developer
> unconference in Ottawa. Here are some preliminary ideas to shed some
> light on what we're trying to do.
>
>
> I've been trying to figure out a plan to enable native
Why not take a simpler approach and create a zero length file in
directories that should not be fiddled with by non-experts using a file
name something like "DO.NOT.DELETE.THESE.FILES"?
No, it won't prevent the incredibly stupid from doing incredibly stupid
things, nothing will.
--
Mike Nolan
This is 9.3 RC1 on a Fedora 7 system. Why does \l report the encoding
as SQL_ASCII
and \set report it as UTF8?
psql (9.3rc1)
Type "help" for help.
postgres=# \l
List of databases
Name Owner Encoding Collate Ctype Access privileges
- - --
On 10/12/12, Josh Berkus wrote:
> I realize you weren't around when we removed row OIDs, but I was *still*
> getting flack from that in 2008. And we lost entire OSS projects to
> other databases because of removing row OIDs. And those were marked
> deprecated for 3 years before we removed them.
On Mon, Jun 11, 2012 at 4:47 PM, Peter Eisentraut wrote:
> On sön, 2012-06-10 at 17:24 -0400, Robert Haas wrote:
> > >> and also affects the naming of any UNIX sockets created.
> > >
> > > Why would that matter? If you configure M ports and N Unix socket
> > > locations, you get M*N actual socke
On 6/2/12, Tom Lane wrote:
> Robert Haas writes:
>> On the other hand, if we simply say "PostgreSQL computes the
>> replication delay by subtracting the time at which the WAL was
>> generated, as recorded on the master, from the time at which it is
>> replayed by the slave" then, hey, we still ha
On Fri, May 11, 2012 at 10:03 PM, Tom Lane wrote:
>
> Well, the question to me is exactly how much good it will do to stop
> deletion of the pg_tablespace entry, if the underlying files are gone.
> I'm having a hard time getting excited about expending cycles on that.
>
There could be multiple r
On 5/11/12, Michael Nolan wrote:
> On 5/11/12, Albe Laurenz wrote:
>> Michael Nolan wrote:
>>> I see one potential difference between your results and mine.
>>>
>>> When I rebuild the tablespace, I wind up with the same filename/OID as
>>> before, I&#
On 5/11/12, Albe Laurenz wrote:
> Michael Nolan wrote:
>> I see one potential difference between your results and mine.
>>
>> When I rebuild the tablespace, I wind up with the same filename/OID as
>> before, I'm not sure you do.
>
> Right. That's stra
I see one potential difference between your results and mine.
When I rebuild the tablespace, I wind up with the same filename/OID as
before, I'm not sure you do.
--
Mike Nolan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
On 5/9/12, Albe Laurenz wrote:
> I cannot reproduce this on 9.1.3:
Odd, I've tried it another two times, with similar results to my initial post.
Here's what I get starting with the point where I deleted the files in
the tablespace:
mytest=# select * from mytable;
select * from mytable;
ERROR:
The last portion of my original post got edited out by mistake.
The tests I ran were on version 9.1.3, running Fedora 14, kernel
2.6.35.14-106.fc14-i686.
It seems to me that DROP TABLESPACE should check to see if there are
references in the system catalog to the tablespace before dropping it, not
While researching a problem reported on the -general list by a user who
lost a disk containing his index tablespace, I ran into something, but I'm
not sure is a serious bug or just an inconsistency in how \d shows tables.
Here are the steps I took.
1. Create a new database 'MYDB' and connect to
What is the use case for temporary tables on a hot standby server?
Perhaps this is a noobie question, but it seems to me that a hot standby
server's use by* applications* or *users* should be limited to transactions
that don't alter the database in any form.
However, I can see where temporary tab
On Mon, Apr 16, 2012 at 6:27 PM, Thom Brown wrote:
> Hi,
>
> I've noticed that when using synchronous replication (on 9.2devel at
> least), temporary tables become really slow:
>
> Since temporary tables are only present until the session ends (or
possibly only until a commit), why are they repli
On 4/11/12, Fujii Masao wrote:
> On Wed, Apr 11, 2012 at 3:31 PM, 乔志强 wrote:
>> So in sync streaming replication, if master delete WAL before sent to the
>> only standby, all transaction will fail forever,
>> "the master tries to avoid a PANIC error rather than termination of
>> replication." but
On 4/11/12, Kevin Grittner wrote:
> Michael Nolan wrote:
>> On 4/11/12, 乔志强 wrote:
>
>>> But when a transaction larger than 1GB...
>>
>> Then you may need WAL space larger than 1GB as well. For
>> replication to work, it seems likely that you may need to
On 4/11/12, 乔志强 wrote:
>
>> Yes, increase wal_keep_segments. Even if you set wal_keep_segments to 64,
>> the amount of disk space for WAL files is only 1GB, so there is no need to
>> worry so much, I think. No?
>
> But when a transaction larger than 1GB...
Then you may need WAL space larger than
On Tue, Sep 13, 2011 at 2:55 PM, Joshua D. Drake wrote:
>
> On 09/13/2011 11:51 AM, Michael Nolan wrote:
>
>
>>The ability to restore a table from a backup file to a different
>>table
>>name in the same database and schema.
>>
>>
&
On Tue, Sep 13, 2011 at 12:26 PM, Joshua D. Drake wrote:
>
> On 09/13/2011 10:13 AM, Michael Nolan wrote:
>
>> The lists all seem to be focusing on the things that the developers
>> would like to add to PostgreSQL, what about some things that users or
>> ISPs might lik
The lists all seem to be focusing on the things that the developers would
like to add to PostgreSQL, what about some things that users or ISPs might
like to have, and thus perhaps something that companies might actually see
as worth funding?
For example:
A fully integrated ability to query across
On Fri, Jul 8, 2011 at 10:27 PM, Robert Haas wrote:
>
> But if that's what you want, just don't put your data in different
> databases in the first place. That's what schemas are for.
>
Sadly, DBAs don't always have the ability to put all their data in one
database, even if that is what schemas
On Mon, Jun 27, 2011 at 1:38 PM, David E. Wheeler wrote:
>
> Yeah, which is why I said it was subject to interpretation. Of course
> there's no way to tell generate_series() which to use, which is what I
> figured.
>
generate_series() is doing exactly what it was designed to do, the
imprecision r
On Wed, May 25, 2011 at 11:18 AM, Robert Haas wrote:
>
> I basically agree. There have been several recent discussions of this
> topic on both -hackers and -performance; it is likely that the TODO
> needs to be updated with some more recent links.
>
Anything to help the NKOTB to get up to speed
In the TODO list is this item:
*Modify the planner to better estimate caching effects
*
Tom mentioned this in his presentation at PGCON, and I also chatted with Tom
about it briefly afterwards.
Based on last year's discussion of this TODO item, it seems thoughts have
been focused on estimating ho
26 matches
Mail list logo
