(2010/06/15 2:25), Robert Haas wrote:
> Per previous discussion:
>
> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01195.php
> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01577.php
>
> Changes in this patch:
>
> - Rename TSParserGetPrsid to get_tsparser_oid, TSDictionaryGet
On Mon, 5 Jul 2010, Robert Haas wrote:
Cool. So, should we have Bruce go ahead and pgindent now?
Yup, as that will give 3 days before wrap / branch to deal with any fall
out from mit :)
Marc G. FournierHub.Org Hosting Solutions S.A.
scra...@hub.org
Tom Lane wrote:
> Truncating seems like an ugly kluge that's not fixing the real problem.
> Why are there open descriptors for a dropped relation? They should all
> get closed as a consequence of relcache flush.
Relcache will be flushed at the next command, but there could be some
*idle backend
On Mon, Jul 5, 2010 at 3:14 PM, Andrew Dunstan wrote:
> Andrew Dunstan wrote:
>> Marc G. Fournier wrote:
- Someone (presumably Bruce) needs to run pgindent. Any reason to
wait any longer on that?
>>
>> The typedefs list on the buildfarm needs to be refreshed. That will take
>> me some t
On Mon, Jul 5, 2010 at 8:17 PM, Tom Lane wrote:
> Greg Smith writes:
>> The main tricky part was figuring how to convert the \setshell
>> implementation. That uses strtol to parse the number that should have
>> been returned by the shell call. It turns out there are a stack of ways
>> to do som
Greg Smith writes:
> The main tricky part was figuring how to convert the \setshell
> implementation. That uses strtol to parse the number that should have
> been returned by the shell call. It turns out there are a stack of ways
> to do something similar but return 64 bits instead:
Please c
Attached is an updated second rev of the patch I sent a few months ago,
to expand pgbench to support database scales larger than around
4,294--where the 32-bit integer for the account number overflows in the
current version. The current limit makes for about a 60GB database.
Last week I ran t
On Sun, Jul 4, 2010 at 9:48 AM, Tom Lane wrote:
> Sure. What you'd need is for HeapTupleSatisfiesVacuum to observe that
> (a) the tuple's xmin and xmax are equal,
> (b) they're equal to my own transaction's XID,
> (c) none of the live snapshots in my backend can see cmin but not cmax,
> (d) cmax
Robert Haas writes:
> On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane wrote:
>> At one time I was hoping to get rid of explicit entries in pg_attribute
>> for system columns, which would negate this concern. I think we're
>> stuck with them now, though, because of per-column permissions.
> Because som
On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Is there a reason we don't have t_self as one of the system columns that
>> you can examine from SQL? I'd propose its addition otherwise.
>
> pg_attribute bloat? I'm a bit hesitant to add a row per table for
> something
Andrew Dunstan wrote:
Marc G. Fournier wrote:
- Someone (presumably Bruce) needs to run pgindent. Any reason to
wait any longer on that?
The typedefs list on the buildfarm needs to be refreshed. That will
take me some time, since I wasn't aware we were about to do a
pg_indent run.
Alvaro Herrera wrote:
Excerpts from Chris Browne's message of lun jul 05 12:33:49 -0400 2010:
3. Some problems checking status.
i) Status Line: 491 bad ts parameter - [timestamp omitted] is in the future
I know my clock's reasonable - ntp is reporting I'm within 0.25s of
some stratum 2
Alvaro Herrera writes:
> Is there a reason we don't have t_self as one of the system columns that
> you can examine from SQL? I'd propose its addition otherwise.
pg_attribute bloat? I'm a bit hesitant to add a row per table for
something we've gotten along without for so long, especially someth
Is there a reason we don't have t_self as one of the system columns that
you can examine from SQL? I'd propose its addition otherwise.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Excerpts from Chris Browne's message of lun jul 05 12:33:49 -0400 2010:
> 3. Some problems checking status.
>
> i) Status Line: 491 bad ts parameter - [timestamp omitted] is in the future
>
> I know my clock's reasonable - ntp is reporting I'm within 0.25s of
> some stratum 2 nodes. Is it poss
I'm trying to start preparing buildfarm nodes for the upcoming Git
migration, and have run into a few issues. I speculate that -hackers
is one of the better places for this to get discussed; if it should be
elsewhere, I'm sure Andrew Dunstan won't be shy to redirect this :-).
What I was hoping to
Robert Haas writes:
> On Mon, Jul 5, 2010 at 11:01 AM, Tom Lane wrote:
>> Yeah, I hope to get that committed today. Any later than today will not
>> leave enough time for buildfarm testing before the wrap.
> Hmm. So does that mean we need to get log_temp_files fixed today also?
No, I'm just c
Marc G. Fournier wrote:
- Someone (presumably Bruce) needs to run pgindent. Any reason to
wait any longer on that?
The typedefs list on the buildfarm needs to be refreshed. That will take
me some time, since I wasn't aware we were about to do a pg_indent run.
Starting now ...
cheers
On Mon, Jul 5, 2010 at 11:18 AM, Marc G. Fournier wrote:
> Me, after I wrap
Cool, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On Mon, 5 Jul 2010, Robert Haas wrote:
On Mon, Jun 28, 2010 at 2:40 PM, Tom Lane wrote:
Josh Berkus writes:
Therefore, I propose that we set a beta3 release date for July 8th.
That should give it enough space from the American Holiday.
You mean wrap on Thursday the 8th for release on Monda
On Mon, Jul 5, 2010 at 11:01 AM, Tom Lane wrote:
>> * normalize use of LDFLAGS - I believe Tom is dealing with this.
>
> Yeah, I hope to get that committed today. Any later than today will not
> leave enough time for buildfarm testing before the wrap.
Hmm. So does that mean we need to get log_t
Robert Haas writes:
> - Someone will need to branch the tree after the wrap and stamp it
> 9.1devel. Who is doing that?
Marc generally takes care of making branches.
> * bump catalog version for plpython3u change? Use RTLD_GLOBAL? -- I
> don't immediately know what the bit about RTLD_GLOBAL is
On Mon, Jun 28, 2010 at 2:40 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Therefore, I propose that we set a beta3 release date for July 8th.
>> That should give it enough space from the American Holiday.
>
> You mean wrap on Thursday the 8th for release on Monday the 12th?
> That'd be fine with
Takahiro Itagaki writes:
> In mdunlink(), we truncate the first main fork to zero length
> and actually unlink at the next checkpoint, but other segments
> are not truncated and only unlinked. Then, if another backend
> open the segments, disk spaces occupied by them are not reclaimed
> until all
Igor Kryltsov wrote:
I am not asking any firm dates but when (and if) do you think roughly
it will be any enhancements on automating partitioning in Postgres?
The earliest possible date for that is the summer of 2011 when
PostgreSQL 9.1 might be released:
http://wiki.postgresql.org/wiki/P
On Monday 05 July 2010 12:11:38 Pierre C wrote:
> > The problem can generally be written as "tuples seeing multiple
> > updates in the same transaction"?
> >
> > I think that every time PostgreSQL is used with an ORM, there is
> > a certain amount of multiple updates taking place. I have actually
On 2010-07-05 12:11, Pierre C wrote:
> The problem can generally be written as "tuples seeing multiple
> updates in the same transaction"?
>
> I think that every time PostgreSQL is used with an ORM, there is a
> certain amount of multiple updates taking place. I have actually
> been reworking cl
The problem can generally be written as "tuples seeing multiple
updates in the same transaction"?
I think that every time PostgreSQL is used with an ORM, there is
a certain amount of multiple updates taking place. I have actually
been reworking clientside to get around multiple updates, since t
Martin Pihlak wrote:
> Attached is a patch that adds a GUC "log_file_mode" which allows to specify
> the creation mode for the log files. Presently it lacks documentation, which
> I'll add if the idea is generally acceptable.
>
Updated patch attached.
regards,
Martin
*** a/doc/src/sgml/config.s
On 2010-07-04 06:11, Tom Lane wrote:
Robert Haas writes:
CREATE OR REPLACE FUNCTION update_tab() RETURNS void AS $$
BEGIN
INSERT INTO tab VALUES (0);
FOR i IN 1..10 LOOP
UPDATE tab SET x = x + 1;
END LOOP;
END
$$ LANGUAGE plpgsql;
I believe
Bruce Momjian writes:
> Turn out 'REM' acts like /bin/true on Windows. I have documented that
> fact in the attached, applied patch.
I guess that kills it for the "pg_archive_bypass" internal command, but
in a good way. Thanks!
Regards,
--
Dimitri Fontaine
PostgreSQL DBA, Architecte
Damn, I s
31 matches
Mail list logo
