From: Heikki Linnakangas [mailto:heikki.linnakan...@enterprisedb.com]
Sent: Saturday, August 04, 2012 1:33 AM
On 03.08.2012 14:46, Amit kapila wrote:
>> Currently the change is done only for fixed length columns for simple
tables and the tuple should not contain NULLS.
>
>> This is a Proof of conc
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Saturday, August 04, 2012 1:48 AM
Amit Kapila writes:
> select (interval '56:48' minute to second);
> result$B!'(B00:56:48
> select (interval '-56:48' minute to second);
> result$B!'(B-56:48:00
> select (interval '+56:48' minute to second);
On 08/04/2012 04:12 AM, Kevin Grittner wrote:
I haven't reviewed it in detail but noticed an apparent editing error:
"which are used the counters" should probably have an "as" thrown in
there. Or something.
Thanks. Editing fail. I revised that spot repeatedly to try to keep it
short and simp
Amit Kapila writes:
> select (interval '56:48' minute to second);
> result$B!'(B00:56:48
> select (interval '-56:48' minute to second);
> result$B!'(B-56:48:00
> select (interval '+56:48' minute to second);
> result$B!'(B56:48:00
> I have checked the code and found that in function Decod
Craig Ringer wrote:
> I'm seeing enough questions on pgsql-general and stack overflow
> to suggest that the docs for how sequences interact with
> transaction rollback.
Yeah, I've noticed a surprising number of people who are being
surprised by the non-transactional nature of sequences (and se
On 03.08.2012 14:46, Amit kapila wrote:
Currently the change is done only for fixed length columns for simple tables
and the tuple should not contain NULLS.
This is a Proof of concept, the design and implementation needs to be changed
based on final design required for handling other scenario'
On Fri, Aug 3, 2012 at 04:01:18PM -0400, Robert Haas wrote:
> On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian wrote:
> >> I don't disagree with pg_upgrade being operationally complex, but I
> >> don't see how this relates to contrib vs. non-contrib at all. Are we
> >> supposed to only have "simple
On Fri, Aug 3, 2012 at 3:22 PM, Bruce Momjian wrote:
>> I don't disagree with pg_upgrade being operationally complex, but I
>> don't see how this relates to contrib vs. non-contrib at all. Are we
>> supposed to only have "simple" programs in src/bin? That seems a
>> strange policy.
>
> Well, per
Excerpts from Bruce Momjian's message of vie ago 03 13:32:21 -0400 2012:
> On Fri, Aug 3, 2012 at 12:53:22PM -0400, Álvaro Herrera wrote:
> > How ready are we to move it to src/bin/? Is it sensible to do so in
> > 9.3?
>
> We have talked about that. Several people felt the instructions for
> u
On Fri, Aug 3, 2012 at 03:10:24PM -0400, Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of vie ago 03 13:32:21 -0400 2012:
> > On Fri, Aug 3, 2012 at 12:53:22PM -0400, Álvaro Herrera wrote:
>
> > > How ready are we to move it to src/bin/? Is it sensible to do so in
> > > 9.3?
> >
On Tue, Jul 19, 2011 at 10:29:45AM +1200, Mark Kirkwood wrote:
> On 19/07/11 02:36, Tom Lane wrote:
> >Bruce Momjian writes:
> >>Tom Lane wrote:
> >>>Huh? Seems like a waste of text to me. What else would happen?
> >>Well, if we exceed work_mem, we spill to temp disk. If we exceed temp
> >>disk
On Fri, Aug 3, 2012 at 02:08:34PM -0400, Andrew Dunstan wrote:
> >$ find . -type f -exec file {} \;|
> > egrep -i 'perl.*(script|module)'|grep -v '\.p[lm]:'
> >
> >and got:
> >
> >./src/pl/plperl/ppport.h: awk script text
> >./src/tools/pginclude/pgcheckdefines: a /usr/bin/perl -w script text
Dear Tom,
thanks for your answer,
Fabien COELHO writes:
I was looking into using hardlinks to reduce the storage of keeping and
syncing periodic database dumps when they are identical. This works fine
with the textual format, but not for the custom format because the file
header includes a t
On 08/03/2012 01:23 PM, Bruce Momjian wrote:
On Fri, Aug 3, 2012 at 12:51:03PM -0400, Andrew Dunstan wrote:
On 08/03/2012 10:51 AM, Bruce Momjian wrote:
OK, sure, we can keep the pgindent name --- I was just trying to be
consistent. One problem with the lack of an extension is that there i
I wrote:
> Noah Misch writes:
>> We achieve that division of labor for XLOG_BTREE_DELETE by examining the old
>> contents before RestoreBkpBlocks(). This is safe, I think, because we only
>> examine the page when the system has running hot standby backends, and we
>> only
>> allow hot standby co
On Fri, Aug 03, 2012 at 11:59:00AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > I think we should instead implement postmaster mutual exclusion by way of
> > fcntl(F_SETLK) on Unix and CreateFile(..., FILE_SHARE_READ, ...) on Windows.
>
> I'm a bit worried about what new problems this solution
On Fri, Aug 3, 2012 at 12:53:22PM -0400, Álvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of vie ago 03 12:44:35 -0400 2012:
>
> > I changed a prep_status() call to pg_log() as you suggested, and
> > backpatched to 9.2. Patch attached.
>
> I dunno about this particular patch, but i
On Fri, Aug 3, 2012 at 12:55:30PM -0400, Álvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of vie ago 03 09:59:36 -0400 2012:
> > On Fri, Aug 3, 2012 at 12:26:56AM -0400, Bruce Momjian wrote:
> > > The concurrent index documentation under discussion above was never
> > > updated, so I
On Fri, Aug 3, 2012 at 12:51:03PM -0400, Andrew Dunstan wrote:
>
> On 08/03/2012 10:51 AM, Bruce Momjian wrote:
>
>
> >OK, sure, we can keep the pgindent name --- I was just trying to be
> >consistent. One problem with the lack of an extension is that there is
> >no easy way for the Perl clean
Noah Misch writes:
> On Thu, Aug 02, 2012 at 02:49:45PM -0400, Tom Lane wrote:
>> * In spgRedoVacuumRedirect, call ResolveRecoveryConflictWithSnapshot
>> with the newest-redirect XID.
> There's an obsolete comment in spg_redo().
[ squint ... ] Comparing that to btree_redo, I realize that there'
Excerpts from Bruce Momjian's message of vie ago 03 09:59:36 -0400 2012:
> On Fri, Aug 3, 2012 at 12:26:56AM -0400, Bruce Momjian wrote:
> > The concurrent index documentation under discussion above was never
> > updated, so I took a stab at it, attached.
> >
> > Greg, I looked at adding a mentio
Excerpts from Bruce Momjian's message of vie ago 03 12:44:35 -0400 2012:
> I changed a prep_status() call to pg_log() as you suggested, and
> backpatched to 9.2. Patch attached.
I dunno about this particular patch, but if we ever want to move
pg_upgrade out of contrib we will have to stare hard
On 08/03/2012 10:51 AM, Bruce Momjian wrote:
OK, sure, we can keep the pgindent name --- I was just trying to be
consistent. One problem with the lack of an extension is that there is
no easy way for the Perl cleanup instructions to find all the Perl
executables --- right now it looks for an
On Thu, Jul 7, 2011 at 06:09:54PM -0400, Tom Lane wrote:
> I wrote:
> > Peter Eisentraut writes:
> >> I was adding gcc printf attributes to more functions in obscure places,
> >> and now I'm seeing this in pg_upgrade:
>
> >> relfilenode.c:72:2: warning: zero-length gnu_printf format string
> >>
On Fri, Aug 3, 2012 at 11:59 AM, Tom Lane wrote:
>> I think we should instead implement postmaster mutual exclusion by way of
>> fcntl(F_SETLK) on Unix and CreateFile(..., FILE_SHARE_READ, ...) on Windows.
>
> I'm a bit worried about what new problems this solution is going to open
> up. It seems
Noah Misch writes:
> The problem here is a race between concluding the assessment of a PID file as
> defunct and unlinking it; during that period, another postmaster may have
> replaced the PID file and proceeded. As far as I've been able to figure, this
> flaw is fundamental to any PID file inva
Despite its efforts, CreateLockFile() does not reliably prevent multiple
closely-timed postmasters from completing startup on the same data directory.
This test procedure evades its defenses:
1. kill -9 the running postmaster for $PGDATA
2. "mkdir /tmp/sock1 /tmp/sock2"
3. "gdb postgres", "b unlin
On Fri, Aug 3, 2012 at 10:33:21AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Aug 3, 2012 at 08:26:50AM -0400, Andrew Dunstan wrote:
> >> I think we generally don't put file type extensions on commands, so
> >> this should probably just be renamed pgindent. If someone wants to
> >
On Fri, Aug 3, 2012 at 10:33 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> On Fri, Aug 3, 2012 at 08:26:50AM -0400, Andrew Dunstan wrote:
>>> I think we generally don't put file type extensions on commands, so
>>> this should probably just be renamed pgindent. If someone wants to
>>> go back to
Bruce Momjian writes:
> On Fri, Aug 3, 2012 at 08:26:50AM -0400, Andrew Dunstan wrote:
>> I think we generally don't put file type extensions on commands, so
>> this should probably just be renamed pgindent. If someone wants to
>> go back to the old shell script they can still get it from git.
>
Fabien COELHO writes:
> I was looking into using hardlinks to reduce the storage of keeping and
> syncing periodic database dumps when they are identical. This works fine
> with the textual format, but not for the custom format because the file
> header includes a timestamp set by function Writ
On Fri, Aug 3, 2012 at 08:26:50AM -0400, Andrew Dunstan wrote:
>
> On 08/02/2012 11:09 PM, Bruce Momjian wrote:
>
> >Thirteen months after Andrew posted this WIP, I have restructured and
> >tested this code, and it is now ready to replace the pgindent shell
> >script as pgindent.pl, attached.
>
On Fri, Aug 3, 2012 at 12:26:56AM -0400, Bruce Momjian wrote:
> The concurrent index documentation under discussion above was never
> updated, so I took a stab at it, attached.
>
> Greg, I looked at adding a mention of the virtual transaction wait to
> the "explicit-locking" section as you sugges
Hi all
I'm seeing enough questions on pgsql-general and stack overflow to
suggest that the docs for how sequences interact with transaction
rollback. Take the most recent post on -general, where the person read
at least the tutorial, but had no idea about the exemption.
The attached patch:
On Thu, Aug 2, 2012 at 7:01 AM, Etsuro Fujita
wrote:
> The following is a comment at fileGetForeignPaths() in contrib/file_fdw.c:
>
> /*
> * If data file was sorted, and we knew it somehow, we could insert
> * appropriate pathkeys into the ForeignPath node to tell the planner
>
On Thu, Aug 02, 2012 at 02:49:45PM -0400, Tom Lane wrote:
> I believe that the SPGiST issue should be fixed as follows:
>
> * It's okay for transactions inserting redirection tuples to use their
> own XID as the marker.
>
> * In spgvacuum.c, the test in vacuumRedirectAndPlaceholder to decide if
>
On 08/02/2012 11:09 PM, Bruce Momjian wrote:
Thirteen months after Andrew posted this WIP, I have restructured and
tested this code, and it is now ready to replace the pgindent shell
script as pgindent.pl, attached.
I have tested this version by re-running the 9.1 and 9.2 pgindent runs
and com
One thing I forgot to mention that for tests I have used pg_prewarm utility
to load all the data in shared buffers before start of test.
With Regards,
Amit Kapila.
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit kapila
Sent: Friday, Au
Thanks for your suggestion, Robert.I just found this page
(http://wiki.postgresql.org/wiki/Working_with_Git#Context_diffs_with_Git),
quite useful and powerful.
Best RegardsHuang Qi VictorComputer Science of National University of Singapore
> Date: Fri, 3 Aug 2012 04:28:42 -0400
> Subject: Re: [
Here is a new submission with the expected "context diff format".
Dear PostgreSQL developers,
Plese find attached a patch so that:
Make "psql -1 < file.sql" work as with "-f"
Make psql --single-transaction option work on a non-interactive
standard input as well, so that "psql -1 < i
Hello,
I was looking into using hardlinks to reduce the storage of keeping and
syncing periodic database dumps when they are identical. This works fine
with the textual format, but not for the custom format because the file
header includes a timestamp set by function WriteHead in file
"src/b
On Fri, Aug 3, 2012 at 2:56 AM, Qi Huang wrote:
> Hi, hackers
> I was exporting my project to a patch file. As the patch review
> requires, the patch needs to be in context diff format
> (http://wiki.postgresql.org/wiki/Reviewing_a_Patch). But the git diff
> exports in a format similar to unif
42 matches
Mail list logo